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.

I have rewritten the PKGBUILD such that it now only supports the most recent version of MATLAB. I have also created version specific packages back to r2010b (https://aur.archlinux.org/packages/?O=0&SeB=n&K=matlab&outdated=&SB=n&SO=a&PP=50&do_Search=Go). If you want to install an older version, use one of the version specific packages. This change makes the PKGBUILD must easier to maintain and understand.

@daniel_shub When I run the command you gave it outputs 'false'. And I have Matlab 2015a installed using a modified version of this PKGBUILD: https://gist.github.com/anonymous/af28f52e890444dd643f Not sure how this helps though?

@daniel_shub That's a great idea. I'd suggest using split packages and meta packages for this. For example, we can have the base package in the split package named "matlab" be a meta package for the latest version, and have it be a split package that generates all the matlab-r$versions ones... Shoot me an email and we can figure out if it's easier to do this via github PRs or comaintainership?

I have been unable to get hardware based opengl working since r2014b and the switch to HG2. This has slowed me down from updated the PKGBUILD. I have tried it on different hardware, so I think it is either a missing package or a configuration issue. Can anyone get $ matlab -nodesktop -nosplash -r "opengl info; exit" | grep Software to output false with r2014b or newer?

@ido I am happy to help out again. I never really intended to let it slip as bad as I did. I have never really been happy with the PKGBUILD and it is not the one I use. I think I tried to make it do too much in an attempt to avoid making multiple packages. I propose we simplify the PKGBUILD to only handle the current release and then create packages like matlab-r2015b, matlab-r2015a, ... matlab-r2010b for people who want older versions. This is in fact how I actually manage my installations of MATLAB so it would be simpler for me.

@SibrenVasse I can build an uncompressed package with only a base MATLAB installation in about 10 minutes on my laptop. Adding toolboxes adds time. It takes me a couple of hours to build and compress the package with all the MATLAB toolboxes. The final package can be upwards of 5 GB.

@flying-sheep the PKGBUILD explains that you will need both the software (an iso file) and a file installation key (a fik file) to build the package. To run MATLAB you will also need a license file (a lic file). Some people have reported that the license file is also required to create the package for network licenses. Do you have a copy of the software, a file installation key and the license?

As mentioned in the previous comment, this package should depend on ncurses5-compat-libs.

There is a discussion on the bbs: https://bbs.archlinux.org/viewtopic.php?pid=1562934 It is possible, that even the old Matlab versions will not run anymore, because of a soname bump in ncurses.

I tested the pkgbuild against R2015b and it installs fine. (git patch - http://pastebin.com/8JtF3Z9y) However, while building the package it takes a very, very long time 'Removing static library files'. Am I doing something wrong? (http://pastebin.com/iwD8GZgt)