How I would deal with app installers on Linux

Episode 1x64

Hi guys, I’ve been listening to the show for about a month now, but I’m just now creating an account on the forum. I wanted to post in response to your discussion on distribution package management versus app image installers.

So clearly there is a tradeoff between each method. Debian’s package management makes the best use of resources, since it only installs one version of each library, and ensures the installation of any package that requires said library. The downside is that if an update to a library breaks compatibility, older software can become unusable.

On the other hand, app image installers package all required libraries, meaning that you would have huge duplication of libraries between applications, taking up more space. (ex: Bundling Gtk with every single Gtk application).

I’ve been a Linux user since Ubuntu 7.04, and am currently an Xfce user who likes applications to work out of the box, and wants a simple and reliable desktop solution. Suffice to say, I’m not quite happy with the current status of application installation on any modern Linux distribution. (Though I am not unhappy enough with it to dare switching back to Windows).

– On to the meat of the post –

When downloading an application, it should come as a single file that, when opened will give me an option to run or install. This file should be a tar.gz (with a different file extension of course) containing all necessary libraries, binaries, as well as dependency information in a text file.

If I choose to run the application, it should simply execute the binary using the enclosed libraries.

If I choose to install the application, it should do the following:
For each dependency, check first the user directory and then the root directory for that dependency. If the same version exists, perform an md5sum check on the bundled and installed library to ensure there are no differences. If they are the same, use the one that is already installed. Otherwise install the bundled library.

If they are a different version, install the bundled version alongside the installed version. For example:

If they are the same version, but the md5sum finds a difference between the two, there may be some modifications, install the bundled version alongside the already existing version with a ‘-n’ at the end like so:

Of course the package manager should make a note of which version the installed application is to use.

And of course, if the application is installed as a user, install the binaries and libraries to the home directory. If it is installed as root, then install to the root directories.

Perhaps this is how some of the app image package managers are already doing things. I have very little knowledge in the matter. But based on your talk on the show, it sounds as though each application will install its own libraries regardless of whether the exact same library already exists on the computer. Which I feel is completely inefficient. This method merges the efficiency of the Debian methodology with the reliability of the app image methodology.

I am writing this after work, going on 30 hours without sleep. So if clarification is necessary, please let me know, as I may not be in a state of mind to coherently write my thoughts at the moment.

Great show so far, looking forward to being a long-time listener. For the record, I found out about the show because I used to watch Bryan on the Linux Action Show, and occasionally check in to see what he’s up to these days. Still as sarcastic as ever of course.

Hrm. What this approach solves is duplication of files on disc taking up too much disc space. I feel that that’s solveable by the filesystem itself, but more importantly I don’t think that’s the biggest complaint people have about the bundle-all-the-libraries approach. The biggest complaint (or at least the biggest stick used to reactionarily beat the idea with) is around security: let’s say that libjpeg that contains a buffer overflow bug allowing a carefully crafted malicious jpeg to execute native code. Then the libjpeg team fix that bug; in the Debian everyone-uses-the-system-libraries approach, Debian fix the bug once in their libjpeg package and now every app on your machine is protected. In the everyone-bundles-libjpeg-themselves approach, you have to go get new versions of all your apps from the original sources (and those original sources have to bother to package and release a new version with the new libjpeg at all). The proposal above doesn’t, as far as I can tell, fix that problem at all, right?

I’m also not sure what happens if my OS has SomeLib v1, I install a package which contains SomeLib v1, the installer says “aha, we already have that! use the system version!” and then I upgrade the system version to SomeLib v2 – our installed package now doesn’t have SomeLib v1 around (because the system copy has been upgraded, and our installed package’s bundled copy is gone because we didn’t install it.)

I think I’m in broad agreement with @sil here. Lack of disk space is not much of a concern here and I’m sure we can easily come up with a scheme to have multiple versions of a particular library installed and have them associated with the programs that use them without having exact duplicates stored more than once if we wanted too.

The main argument for having only one copy of a library and making every program use that particular version is security. Programmers do occasionally make mistakes and having only a single copy of a library means that when a bug or security flaw is found in that library it only has to be fixed once.

For this reason I like the idea of repositories with every program being maintained to use the latest version. For the most part this should be a simple matter since one would hope that most library updates are either improvements in performance, bug fixes or added functionality and that any calls to the old library will continue to work with the update. This is not always the case however and changes to the library necessitate changes in the way a particular function needs to be called. This is what breaks programs.

The solution to this is more developers with the time and motivation to maintain the code, but given while some packages have the backing of big companies behind them other projects have only a small team of volunteers and it would be unreasonable to expect everyone to have an in depth knowledge of every distribution.

Please respect our code of conduct which is simple: don't be a dick.