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.

@Rubo I'm using the most recent PKGBUILD. Yes, the error occurs right after "Packaging Python API". FYI I'm trying to do a partial install with only MATLAB, don't know if that makes any difference. I've edited the PKGBUILD to say partialinstall=true and products=( "MATLAB" ).

@Ketchup901 it's the directory which contains the necessary files to build the Python engine. Please make sure that python-matlabengine comes before matlab in the PKGBUILD pkgname variable, as the package_matlab function moves files needed by package_python-matlabengine, so if that's not the case, that's likely why there is no such directory and it probably means you are using an old PKGBUILD. The current one should work, or at least it works for me. Did you get the error right after -> Packaging Python API...?

What is "${srcdir}/build/extern/engines/python" supposed to be? I followed the instructions for creating matlab.tar but there is no such directory.

@MoetaYuko https://github.com/Rubo3/matlab-aur/blob/Rubo3-patch-1/PKGBUILD Before pushing an update, can you please tell me if this works for you? It seems to work for me.

Edit: I see you have forked and updated VictriD's PKGBUILD here. I have integrated your changes, thank you.

1. MatLab won't start after overriding LD_LIBRARY_PATH with gcc9 lib, the hack should be dropped.
2. libfreetype.so should be removed in package_matlab() as well, in case the tar is not prepared by install.sh

@mys_721tx Thanks, fixed it.

@Rubo Step 4 should be MATLABROOT/install instead.

Hello, I just pushed an update to the 2022a release. Some things have changed:

• The PKGBUILD is based on the one VictriD kindly provided here, with some minor adjustments to make it work against the 2022a release. For more information on how it works and what has changed, read that comment. I put the files on a GitHub repo here: https://github.com/Rubo3/matlab-aur.
• I rewrote most of the README, in order to cover some installation issues, like the correct unzip flags so that the installer doesn't complain of files being shorted than expected; the new libxcrypt-compat dependency and the FreeType shared object renaming.
• I removed matlab.script, let me know if you want it back.
• I added an install script, which covers basic installation needs (i.e. the exact procedure listed in the README), so that you only have to interact with the on-line installer. Please remember to edit the PKGBUILD products variable beforehand if you want a partial install. The points listed by bbaserdem here still hold.

It runs, but there are many errors, most likely because the dependencies on the PKGBUILD do not reflect the current ones. If you'd like to help out, here are the MATLAB dependencies for the Docker container. In the Source Repository box you can find the link to the base-dependencies.txt mentioned in the Dockerfile. If you find something interesting, please leave a message!

After the system update (ArchLinux), the following error occurred while trying to open LiveScript: "The Live Editor is unable to run in the current system configuration." I have found the advice in one discussion (https://bbs.archlinux.org/viewtopic.php?pid=2028209#p2028209) - to rename file MATLABROOT/bin/glnxa64/libfreetype.so.6.

Anyone wants to take over the package? I don't use Arch anymore. Please email me so we can discuss; as I want to hand over this package to someone who knows what they are doing.