Arch Linux User Repository

TODO:

1. Figure out the users and permissions. Currently, /opt/MATLAB/${_release} has 777 permissions, which is obviously undesired. It might be better to create a user group and require users to manually add themselves to it for security reasons.

2. Improve the installer. For example, the current inotify watcher spams stdout and does not account for the end of the download/installation or the width of the terminal, which results in flaky output.

3. Figure out the dependencies. The list of Debian/RHEL dependencies is public, but it includes some seemingly unneeded packages. This might be because they are required by dependent products/add-ons. Additionally, the current logic for removing bundled dependencies should probably be rewritten. Maintaining an exhaustive list for a single release is very difficult, and these components change without notice. Moreover, the current approach may go against the Arch KISS philosophy. Ideally, we should remove only the problematic components like Qt, XCB, libtiff, gcc-libs, fontconfig, etc.

4. Add auto-discovery for packages written for MATLAB. My plan was to use /usr/lib/MATLAB/${_release} for release-specific modules and /usr/lib/MATLAB/common for shared (mostly architecture-independent) packages. However, load order matters, and "common" modules need to specify which releases they are compatible with. This means we need to implement our own logic for discovering and loading these, likely via hooks, shell scripts, and configuration files (perhaps TOML could work?).

5. Fix the Python components. python-matlabengine does install the Python components built against the version of Python shipped by Arch. However, some proprietary CPython components are not included and are built against ancient Python versions. This likely requires version spoofing or some alternative approach.

6. Write and upload packages for previous MATLAB releases. It is entirely possible to have multiple releases installed simultaneously. I have a few of these packages myself, but they are drafts and not suitable for upload to the AUR.

7. Write and upload packages for MATLAB-dependent add-ons and products. When installing MATLAB required user intervention for source access, it was acceptable to break reproducibility and manually specify required products for installation. Now that we use MPM, it would be better to separate products into individual packages. These packages would install themselves and their dependencies into a specific location, then use appdata to install only the component's files. The problem is that MATLAB often includes conflicting files that need to be combined or overwritten. Obviously, we can't allow that, so a hook must be implemented to, for example, combine *.combine@matlab-simulink and replace *.replace@matlab-documentation files with backups. Needless to say, this is challenging to implement, so the previous approach (having users specify the product list) might still be preferred.

8. Write and upload the matlab-runtime package. I have a draft, but the problem with this package is that it installs the runtime for every available product. Ideally, for source-built packages, we would want to makedepend on matlab-$product and depend on matlab-$product-runtime. However, this is not possible without splitting the runtime packages, which poses the challenges described above. I’ll try my best to revisit this sometime later.

@aoneko, @Reexys, please read the post-installation instructions. If you've lost them, you can find the same information here.

@xcabal what version of MATLAB are you installing? Is there anything in /mnt/f078739e-820f-40da-bf0d-838723a49f50/software/mat/pkg/matlab/opt/tmw/ You could try removing &> /dev/null from line 66 and you might get a more helpful error message.

I'm getting the following message trying to install matlab 2016b ==> Starting package()... -> Starting MATLAB installer -> Installing license install: cannot stat '/mnt/f078739e-820f-40da-bf0d-838723a49f50/software/mat/pkg/matlab/opt/tmw/matlab/license_agreement.txt': No such file or directory ==> ERROR: A failure occurred in package(). Aborting... im am not sure what it whats let alone how to fix it anyone have any idea how to resolve this? thanks

With R2016b, if you get error like "Unable to start MATLABWindow process" with Add-on Explorer, Simulink gallery, Simulation Data Inspector etc, make sure to install this package: https://aur.archlinux.org/packages/libselinux/ MATLABWindow executable is linked with libselinux.so, so you need this.

btw, `/usr/bin/mcc` is in conflict with mathematica, as well. I'm going to try linking just /usr/bin/matlab and nothing else. As it stands, either declare the conflict on texlive/mathematica, or change the links - the worst thing to do is to get the error message only once pacman has spent a full hour decompressing the package, whereas one could have dealt with the issue up-front if they new about the conflict. My vote goes towards *not* linking any binaries, and then documenting this in the wiki AND displaying a post-installation message telling the user where the binaries can be found. I suppose one could also create another package (e.g. `matlab-links`) which packages only the links, but depends on `matlab` (which has no /usr/bin links) and then users now have the option to install matlab with or without symlinks, but I'm pretty sure that's unidiomatic in at least one way.

@greyltc Depending on what you are doing, running hardware based opengl can be much faster ... The texlive-bin conflict is a pain. Having MATLAB conflict with TeX Live seems silly. This means either renaming the MATLAB executables or simply not creating links in /usr/bin. I don't have a good set of tests of mex functionality, so I do not know if changing the name is viable. That said, it is just a link, so I think it should be fine. I am leaning towards not linking anything to /usr/bin. The problem with that is then people need to add /opt/tmw/matlab/bin/ to their path to start MATLAB from the CLI (the PKGBUILD can take care of the desktop launcher). We could then add a link on the Arch MATLAB wiki page to how to change the path. Any thoughts? In the meantime, you can comment out lines 74-78 (or modify them to choose a different name).

@Tallix the MATLAB installer makes use of /tmp during the installation process. On Arch, /tmp is a tmpfs that usually defaults to using up to half of your available RAM. This means the space in your home partition does not matter. When I build from either the PKGBUILD or directly from the MATLAB installer, I get exactly the same files written to /tmp. The only reason I can think of that it works for you with the MATLAB installer and not the PKGBUILD is that maybe you are only installing a subset of the toolboxes with the MATLAB installer. If you install less stuff, you need less space in /tmp. Since the tmpfs filesystem uses RAM it is much faster than filesystems located on a physical hard drive. That said, the Arch way may be to keep everything in ${srcdir}. Let me check. In the mean time you can either mount /tmp as a regular filesystem (https://wiki.archlinux.org/index.php/Tmpfs#Disable_automatic_mount) or edit the PKGBUILD to pass the MATLAB installer '-tmpdir "${srcdir}"'. Basically, you want to change line 66 from "${srcdir}/install" -t -inputFile "${srcdir}/installer_input.txt" -mode silent &> /dev/null to "${srcdir}/install" -t -inputFile "${srcdir}/installer_input.txt" -mode silent -tmpdir "${srcdir}" &> /dev/null

@0tie @daniel_shub @ido I'm having the same problem, even when running makepkg -s while in my home partition, which has 662.7GB of free space. The origin of the issue appears to be the Matlab installer. I modified the PKGBUILD so that the output of the Matlab installer is not redirected to /dev/null and now I'm seeing errors from cp saying that it has no space left on the device when trying to write to /tmp/mathworks_23253/whatever and a final error that says "Error: No classpath definition jar found." I find this strange, because I was able to run the installer by itself just fine earlier... I just wanted to use the AUR package because it integrates everything into Arch nicely.

In case it helps anyone else... MATLAB on my machine was segfaulting a few seconds after I started it and it mostly finished drawing the UI: Segmentation violation detected at Sun Aug 21 16:50:31 2016 ... I've found two solutions. 1. Running matlab -r "opengl('save','software')" solves it (on next startup) 2. Run it with LIBGL_DRI3_DISABLE=1 matlab

@daniel_shub Do you think it would break anything if you renamed the /usr/bin/mex link you have here to something else (/usr/bin/mex-ml perhaps)? That file name conflicts with a file provided in https://www.archlinux.org/packages/extra/x86_64/texlive-bin/ which is a shame. At the very least, you should add texlive-bin to `conflicts`

@0tie: do you get the same issues when you do this somewhere outside of /tmp (for example, in your home directory): yaourt -G matlab cd matlab makepkg -s ... /tmp is a tmpfs that usually defaults to using up to half of your available RAM.