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.

@kahlos - thanks for the script. I haven't touched this package in a long time. daniel_shub is in charge as far as I know, have a look at his matlab-<YYYY[a|b]> packages, e.g. matlab-2015b.

With the latest versions of MATLAB this AUR package isn't working very well and I'm not sure all the dependencies are actually required any more. I'm running a fairly minimal system, where I installed MATLAB manually and it seems to be working fine. I created a script to silently install MATLAB packages, which might be useful to others: https://gist.github.com/kahlos/97c9371f7a5476678ef11c836c97a14f

The PKGBUILD is outdated for R2017a, you got to change the line 91 to remove libstdc++.so.6.0.17 to libstdc++.so.6.0.20 since this version uses the new library.

Please note that MATLAB does not run under GCC7 because of the ABI changes in libgfortran (major version number bumped from 3 to 4). Please install libgfortran6 in the AUR if you upgrade to GCC7.

I needed to install gsreamer0.10 from the aur to get image aquisition adapters working and so that matlab could see my webcam and video device on matlab2016b.

If someone else has trouble installing R2016b using the provided PKGBUILD, then they might find this modified PKGBUILD <https://gist.github.com/anonymous/dc16ef3218404a5e31dc69cfd5390898> useful. I had to provide the network licence file to get the build to proceed and update the list of libraries to be deleted at the end, as R2016b has been linked with gcc4.9. I have also changed optdepends to reflect that. I have further prefixed all matlab binaries other than matlab with matlab- in /usr/lib/. I won't be uploading my PKGBUILD as matlab-r2016b as I cannot be bothered to clean it up and maintain it. If you find it useful and can be bothered to make sure the dependencies are all declared, please go ahead and upload it to AUR once cleaned up.

gstreamer0.10-base is gone. can matlab work with an up-to-date gstreamer?

There's a pgp error, not sure how to solve it. guessing it's not a mitm on my side but just a different author. ==> Verifying source file signatures with gpg... ncurses-6.0-20161224.tgz ... FAILED (unknown public key 702353E0F7E48EDB) ==> ERROR: One or more PGP signatures could not be verified! The build failed. Dependencies for `matlab' are not met, not building...

I had to install the libselinux package in order to use the Add-On Explorer in Matlab R2016b. https://se.mathworks.com/matlabcentral/answers/309629-cannot-open-add-on-window-on-linux Maybe this package should be added to depends or optdepends?