Repackaging proprietary software

Question

I was thinking about trying to package Matlab (a proprietary piece of software) for Arch Linux by creating a PKGBUILD to handle installation, dependencies, and conflicts. With the standard Matlab Linux installer it places everything in a local directory and does not require many external packages.

That said, it provides a number of standard library files (e.g., libgcc_s.so and libstdc++.so) as well as a complete JRE. Can these types of files be removed (possibly replaced by links) and supplied by additional package dependencies?

Answer 1

I don't see why the removal would be an issue and the replacement with links, assuming they're identical to the versions that were included with the Matlab installation. But somehow this feels like you're making a lot of work for yourself.

When I used to support a group where we maintained many versions of proprietary packages such as Matlab, our group would install them into self contained directories and use a tool similar to modules to maintain the management of the user's environment when they would want to switch it so they could use these packages.

See this U&L Q&A titled: Add multiple subdirectories under the same parent directory to PATH where I discuss various tactics for managing a system's $PATH environment variable. These same tactics can also be applied to pretty much any environment variable. These are often what controls the functionality of proprietary applications.

Answer 2

I try to maintain the PHP App Engine package on AUR and I'm installing it in /opt which was where you should put a self-contained Matlab package (in something like /opt/matlab) and sym-link the executable back to /usr/bin and other stuff back to /usr/share/applications and what not.

I would take a look at a few other packages that re-package binaries for arch. Like the Dropbox or Google Chrome packages. The Chrome package in particular depends on the Debian binary so they drop the Debian specifics when installing on arch.

On the other hand, if you drop everything into /opt/matlab as-is rather than strip common libraries and the JRE you're much more likely to have a working Matlab that doesn't break or have to be re-tested and re-packaged every time a dependency changes.

You could offer two flavours: a Matlab-complete package and a Matlab-minimal package.

Answer 3

There are two reasons why large applications come with bundled libraries. One reason is that it saves users from having to trace all of the libraries, find which package contains them in their distribution, ensure that they have the right versions, etc. Maintaining binary packages that work on all distributions is tricky because at a given point in time, distributions often ship different library versions. If your package is for a given release of a given distribution, then relying on the distribution's version isn't a problem. But with Arch Linux, due to the lack of stable releases, you're going to have to update your package very often if you don't bundle at least the rapidly-changing libraries.

The other reason to bundle libraries is that sometimes programs have dependencies on specific library versions. In principle, libraries have two-part version numbers: a major version number that changes whenever the ABI¹ changes in an incompatible way, and a minor version number that changes whenever anything changes (e.g. a bug fix, or a new feature that doesn't break backward compatibility). (Many libraries have a version number of the form MAJOR.MINOR but this isn't universal.) Library binaries with different major versions have different sonames, so that they can be installed together, whereas library binaries that only differ by their minor version have the same soname, so that only one is found by dynamic linking. If the program was built and tested for version 1.2, but you have version 1.3, the program should still work. However sometimes programs use undocumented interfaces which are not part of the ABI and which may be broken in 1.3. Since testing with all possible library version combinations would be a support nightmare, distributors of binaries prefer that all users use the same library versions (with an exception for a few system libraries, especially libc).

¹ _{Application Binary Interface: the specification of the interface between the compiled library and the compiled program.}