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.

Thanks for the update, partial install works now.

@sukanka thank you, I left a comment on your pull request and I have enabled the Issues tab. I don't know why it was disabled.

@Rubo, I ran namcap for the built package to check dependencies, and here is the output. https://fars.ee/53NB

Dependencies should be updated according to the output. Some are in depends and some should go into optdepends (for example java-runtime) and some should be removed(libselinux)

BTW, I cannot open an issue in that github repo.

@sukanka I'm glad to hear you built it successfully. As mentioned in this comment, there is a repo here. I guess the choice of links being grey near black text is a little unfortunate...

@Rubo, thanks for your reply, I now use the latest PKGBUILD, still, the problem is

==> Starting pkgver()...
==> Removing existing $pkgdir/ directory...
==> Starting build()...
  -> Running original installer...
  -> Building Python API...
/home/sukanka/Downloads/matlab/PKGBUILD: line 160: cd: /tmp/makepkg/matlab/src/build/extern/engines/python: No such file or directory
==> ERROR: A failure occurred in build().
    Aborting...

But I notice another thing that may help. My matlab version is different from yours.

<version>9.12.0.1884302</version>
<release>R2022a</release>

I'm now redownloading 9.12.0.1927505 Update: I build this version successfully.

BTW, maybe you can setup a github repo for discussing this problem.

@sukanka sure, I re-package it every time I edit the PKGBUILD, to see if it works, and the current one works following the standard procedure, with or without the install.sh script. Maybe you meant /tmp/makepkg/matlab/src/build/extern/, since the problematic directory is ${srcdir}/build/extern/engines/python?

I bumped the release of the PKGBUILD to 4. Nothing has changed since the previous one, just pkgrel, please update it so that we are all on the same track.

With the Python MATLAB engine, it seems to me two problems can occur:

1. Right after -> Building Python API.... If you are doing a partial installation, when the MATLAB off-line installer is ran at line 156, ${srcdir}/build is empty, so surely ${srcdir}/build/extern/engines/python can't be there! I'm thinking of splitting the building and the packaging of the Python engine from MATLAB itself. Please, let me know what do you think.
2. Right after -> Packaging Python API.... If you are using an old PKGBUILD, where you have pkgname=('python-matlabengine' 'matlab') instead of pkgname=('matlab' 'python-matlabengine'), the package_python-matlabengine function is ran after package_matlab. As you can see at line 274 of the current PKGBUILD, package_matlab moves ${srcdir}/build into ${pkgdir}/${instdir}. Then, at line 192, package_python-matlabengine changes the current directory to ${srcdir}/build/extern/engines/python, and an error is thrown, because ${srcdir}/build isn't there anymore, now it's in ${pkgdir}/${instdir}! That was a problem in one of the previous PKGBUILDs, which I fixed, and that's why I added the comment at lines 5-6.

I hope those are the only two problems, but please let me know if that's not the case.

@Rubo, did you build the package yourself? Could you please have a look at the downloaded files? I notice in /tmp/makepkg/matlab/src/matlab/extern/, there is only include/, no engines/python. I used the latest PKGBUILD, and matlab R2022a downloaded from matlab installer.

@tornado99 are you using the latest PKGBUILD? Are you doing a partial installation? Please check the comments below.

-> Building Python API... /var/tmp/pamac-build-[user]/matlab/PKGBUILD: line 162: cd: /var/tmp/pamac-build-[user]/matlab/src/build/extern/engines/python: No such file or directory ==> ERROR: A failure occurred in build().

@Ketchup901 @sukanka when makepkg extracts the contents of matlab.tar, it's normal that $srcdir contains only the matlab directory and a link to matlab.tar. Then, while the original installer is running, $srcdir/build is created with all the files which can be happily consumed by package_python-matlabengine and moved around by package_matlab. But I tried with a partial install, and I confirm $srcdir/build is empty. Maybe the Python engine creation needs be done after MATLAB is packaged.