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.

The installer for matla-engine-for-python doesnt currently support python 3.9, as this error in build() illustrates

Traceback (most recent call last): File "/home/<username>/MATLAB/matlab/src/build/extern/engines/python/setup.py", line 15, in <module> raise EnvironmentError('MATLAB Engine for Python supports Python version' OSError: MATLAB Engine for Python supports Python version 2.7, 3.6, 3.7, and 3.8, but your version of Python is 3.9

I tried installing python38 from AUR but no dice. Same Error.

@tornado99 it gets installed in /opt/tmw because that is where the FHS says it should go: /opt is reserved for the installation of add-on application software packages. (https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html). Now you might be thinking, but TMW defaults to /usr/local and that is where all the online tutorials say it goes. And that is right, and consistent with the FHS: The /usr/local hierarchy is for use by the system administrator when installing software locally. (https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html). The difference is that this package essentially removes the system administrator from the process and in general, a package manager should never install anything in /usr/local.

Any clues where this is installed? Followed the Readme and installation finished without errors. However /usr/local/MATLAB is empty apart from an older version I installed manually.

Edit: found it at /opt/tmw. Why this location?

Please update for python 3.9

From the supported compiler page, it seems that GCC 8.X is better supported and the supported gfortran version seems to be only 8.3?

Can I use license.dat file instead of license.lic?

@daniel_shub you can request a trial version of MATLAB here: https://www.mathworks.com/campaigns/products/trials.html

@bbaserdem as you say, running my example check function from within the PKGBUILD is difficult because of potential differences in the hardware on the build machine and the target machine and it probably would not tell you much about how MATLAB will behave on the target machine. Running the check on the build machine also would require activating MATLAB on the build machine which introduces other problems. That is why I did not include the check function originally when I created the package.

I think having an additional script that tests the MATLAB installation on the target machine is probably the way to go. This way a system administrator who is asked to install MATLAB on the target machine can be reasonably confident that the software works on the target hardware even if they do not understand MATLAB. Of course this is extra work but it would resolve questions like the one by @rellieberman. I wish I had a newer version of MATLAB so that I would not have been forced to neglect the package for all those years and could help out with writing a test function, because as I think everybody realizes, getting MATLAB to work in Arch is tricky.

The activation and licensing completely is disengaged from the PKGBUILD. You have to do that manually yourself; which I documented in the README.md. If you install the created package on a machine that is different than the licensed one, you won't be able to run the package. And as long as you don't redistribute (and that is fully on you; not the AUR) the built package; you are compliant with the EULA. Just to be 100% sure; you need to remove the matlab tar.zst from the pacman cache; but you won't go to jail if you don't do that.

There are absolutely no files distributed through the AUR; this is just an installation script. This PKGBUILD is not a matlab installation hack; it's a matlab-pacman integration at best; and fixes some behavioral issues for you. This is not meant to be portable due to how the EULA works; you are not supposed to port it anywhere. However; what you can do is you can run this package on some computer B; but prepare the outlying package to be installed on computer A. As long as you keep your copies to yourself; you are fully within the EULA. Robustness wise; this is the recommended installation procedure from the MATLAB website regarding installing without an active internet connection so that I don't agree with; it's the proper way to do so.

The check function is a good suggestion for things like compatible python version and whatnot, I'll see what I can come up with based on your suggestion. Hardware tests would not be good practice; as there is no guarantee that the computer that will run the built package is the same as the one doing the packaging; not to mention the makepkg user usually does not have access to hardware interfaces. Not to mention not all hardware will support every feature (can't run gpu array on one of my PC's, hardware acceleration and audio is disabled on my server, not everyone wants all the features, etc.

Maintenance wise; I have seen this package neglected over the past few years. While i'm working at the lab I'm in (for another year) and while I actively use Arch as my desktop distribution; I am planning on maintaining this package and won't share maintenance with someone else unless I can trust them. But I will most likely maintain it for another year, a year and a half at most, and then pass it on to someone with motivation to provide.

I think the package would benefit from a check function or an extra script that checks the installation. When I originally created the PKGBUILD, I toyed with including the following

checkdepends=(xorg-fonts-100dpi cuda)
check () {
  _matlab_cmd="/bin/matlab -nodesktop -nosplash -r"
  LC_ALL=C $matlab_cmd "version -java, exit" | grep Java
  LC_ALL=C $matlab_cmd "opengl info; exit" | grep Software
  LC_ALL=C $matlab_cmd "x=rand(10, 'single'); g=gpuArray(x); Success=isequal(gather(g), x), exit"  | sed -ne '/Success =/,$p'
  LC_ALL=C $matlab_cmd "doc doc; pause; exit"
  LC_ALL=C $matlab_cmd "xlabel('BIG FONT', 'FontSize', 42); ylabel('small font', 'FontSize', 12); pause; exit" > /dev/null
  LC_ALL=C $matlab_cmd "bench, pause; exit" > /dev/null
  LC_ALL=C $matlab_cmd "load handel; sound(y, Fs); pause(length(y)/Fs); exit" > /dev/null
}

but dealing with the licensing and activation in makepkg did not seem robust or portable, and probably violates the MATLAB ELUA. That said, I did manually run those tests (along with namcap) on my machine before updating the PKGBUILD to make sure it worked. I would incrementally add dependencies until the package would pass those tests.

Most of the above script is documented in the MATLAB Arch wiki and covers most of my MATLAB use cases. I just looked at the wiki now and it seems like a more complete check/test function would include tests for the compiler(s), serial port, static TLS issues, addon manager (this is apparently where the libselinux package is needed), live script, and webcam support. I do not have a license for newer versions of MATLAB, so can no longer maintain the package or really help with the tests.