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.

@petronny emm, you could update the PKGBUILD file. 1. I don't quite understand your point, user just need to provide matlab.lic in the same dir with PKGBUILD, and run makepkg.

2, 3. As for mex, should I remove the unused library files, and set mex opt? According to wiki page, matlab doesn't seem to respect the ${MATLAB}/bin/mexopts.sh customization. Instead it uses ${MATLAB}/bin/glnxa64/mexopts/LANG_glnxa64.xml file.

@hottea

1

You didn't answer me directly. Why matlab.lic is added as source for non-network installations? How could these users even get this file to run makepkg?

2

-  ## See $MATLABROOT/sys/os/glnxa64/README.libstdc++
-  msg2 'Removing unused library files'
-  rm ${pkgdir}/opt/tmw/${pkgname}/sys/os/glnxa64/{libstdc++.so.6.0.20,libstdc++.so.6,libgcc_s.so.1,libgfortran.so.3.0.0,libgfortran.so.3,libquadmath.so.0.0.0,libquadmath.so.0}

See $MATLABROOT/sys/os/glnxa64/README.libstdc++ and you will know why they are removed by @greyltc and me.

3

About mex. See @daniel_shub 's comment.
You should set the recommended compilers since you have listed gcc6 as an optional dependency for mex in PKGBUILD.

4

I guess it's not clear enough for @a36233

@daniel_shub

1

-  msg2 'Creating links for executables'
-  install -d -m755 "${pkgdir}/usr/bin/"
-  for _executable in deploytool matlab mbuild mcc mex; do
-    ln -s "/opt/tmw/${pkgname}/bin/${_executable}" "${pkgdir}/usr/bin/${_executable}"
-  done

He removed the binaries.

2

Some of use are packaging and then distributing via a local (or non-local) repository (MATLAB restrictive EULA be damned)

I agree that including PKGEXT in the PKGBUILD is bad style. But it is acceptable for matlab since it cannot be re-distributed.

@petronny I think including PKGEXT in the PKGBUILD is bad style. It should be left to the user to decide and set via makepkg.conf.

Not all of use package and then install. Some of use are packaging and then distributing via a local (or non-local) repository (MATLAB restrictive EULA be damned). In these cases, the carezy long compression time is worth it to reduce the download bandwidth.

Really wish I had a license for a new version. Trying to get some of the older versions to work is a dependency hell. I would much rather figure out the new dependencies and be done with it.

@hottea in version 9.3.0.713579 release 2 symbolic links were created in /usr/bin which caused the conflict. It looks like Darcy Hu made a modification that fixed the issue.

As for the mex compiler issues. I have been told by TMW that higher versions are not supported. That said, I could never find a test case that failed with a higher version. That said, since it is closed source, when I created the PKGBUILD, I went with the required version and I recommend sticking with that approach.

As for the dependencies, it is a real nightmare. I spent a lot of time starting with a clean chroot and only the base group installed and slowly added dependencies until I could get MATLAB to start. Then I tested things like plotting, sound, the doc viewer, opengl, cuda, etc.

My tests before releasing were 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

@petronny 1. You still need a license file from you administrator if you use network installation. For non-network installation, we could automate activate after installation. 2. For mex support with libs issue, you could use higher version of compilers, though it's not officially supported. 3. I think it's clear enough, user need to prepare a tarball matlab.tar from the MATLAB iso image. 4. I don't see such problem. MATLAB is installed in /opt/matlab, so it wouldn't conflict with texlive-bin.

As for deps, since MATLAB is not open source, and there is no deps list provided by MathWorks, I'm not quite sure to keep or remove which deps.

@bbaserdem

Also, is there a specific reason for having non pkg.xz extension?

Because it will take a lot of time to compress the package and then you will extract it just after the compression.

ncurses5-compat-libs is necessary only for >=2016a, which I believe can be phased out. That would leave only a single aur dependency. There is a matlab-2015b package seperately in aur.

Also, is there a specific reason for having non pkg.xz extension?

Also getting a ==> WARNING: Package contains reference to $srcdir.

@a36233 your tar has to have a folder matlab in it, not directly the contents of the matlab installation. Either untar into a directory named matlab then tar -cvf matlab.tar matlab the directory. Or remove the ${pkgname} from the lines that refer to the source files.

I vote for petronny's comment.

I'm having the following problem:

-> Modifying the installer settings

sed: can't read

<path>AUR/matlab/matlab/src/matlab/installer_input.txt: No such file or directory</path>

==> ERROR: A failure occurred in prepare().

Aborting...

"installer_input.txt" it at root of the tar file in r2018a