Package updated to R2025b.
Apologies for not being able to help here for a while. The bad news is that R2025b still targets ubuntu24.04 / ubi9, which means it inherits all the same problems as R2025a. The good news is that all the issues I'm aware of are now covered by the package.
@Fitti, @britin, I was able to reproduce the issue by not activating MATLAB before launching it. Please read the post-installation instructions more carefully next time, you only ran one of the two required commands.
@bbaovanc, the "APPS / Get More Apps" menu (among others) requires java-matlab to be installed to function properly.
@vicious, you have an extra f at the end of the file name.
@daniel_shub, thanks for the information. Packaging (and honestly, even just using) MATLAB is a huge pain, and unless someone specifically requests an older release, I won’t be spending weeks of effort to support it.
Regarding the toolboxes: the days of matlab.fic and matlab.lic are long gone. The last release to support that method was R2023a. Everything since then can only be installed non-interactively using MPM, or via an .iso for a selected license (which I don't have access to).
That said, this isn’t really the core issue. I was able to write a script to split a product based on the files stored in appdata/. It took quite a bit of effort, there’s no public documentation, and some files overlapped between products. This forced me to create helper scripts and hooks to back up and merge shared files. While MATLAB did recognize the products as installed, it didn’t provide any menu options to launch them. I suspect some kind of service registration is required, but I wasn’t able to reverse-engineer that part. And even if I had, most products have shared components that overlap, which makes this style of packaging even more complex.
Pinned Comments
vitaliikuzhdin commented on 2025-07-16 13:12 (UTC) (edited on 2025-08-05 20:05 (UTC) by vitaliikuzhdin)
TODO:
Figure out the users and permissions. Currently,
/opt/MATLAB/${_release}has777permissions, 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.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.
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.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/commonfor 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?).Fix the Python components.
python-matlabenginedoes 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.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.
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
appdatato 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-simulinkand replace*.replace@matlab-documentationfiles with backups. Needless to say, this is challenging to implement, so the previous approach (having users specify the product list) might still be preferred.Write and upload the
matlab-runtimepackage. 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 tomakedependonmatlab-$productanddependonmatlab-$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.vitaliikuzhdin commented on 2025-07-16 12:55 (UTC)
@aoneko, @Reexys, please read the post-installation instructions. If you've lost them, you can find the same information here.