After I wrote about real user needs this article of my series about the software installation on Linux deals with the possible ways to solve the problem.
As I showed there is a strong need for solving the current problem of installing software on Linux. The first, maybe for a Linux newbie most obvious solution is the one which is most unlikely to happen: that all major distributions suddenly turn to one package manager. Also, I doubt that most of all users suddenly turn to a specific distribution, which would also effectively solve the problem.
Other attempts like alternative binary packages (like Autopackage) run into problems as soon as the native package manager comes into play: the native package manager does not know anything about the software of the Alternative package, and these conflicts can quickly lead to problems.
Last but not least there are attempts like Linspire’s CNR or the OpenSuse build server. Both are quite similar in the regard that they both try to build several different distribution packages for each program. The OpenSuse build server even creates native repositories for each piece of software. However, both have the same problem: they are central server based.
Another problem they also share with the Checkinstall attempt is even worse: they can only support a basic set of distributions and therefore exclude all other distributions (and therefore all innovative but small distributions as well). Every additional distribution especially with a new package format would add another level of complexity.
Even if you would follow that way of providing binaries you would face the problem that a small group of people would have to decide which distribution is “important” and which not – such a single position of power inside the entire Linux community could run into trouble.
The theory of the perfect solution
Therefore the only solution is a system which can interact with the native package format somehow. When there is a way to register files within the native package manager, conflicts are detectable. The LSB has the same position: Ian wrote an article about that topic, Software installation on Linux Part 2. Although his focus is on proprietary software developers and mine is on FLOSS developers the arguments are equal for both groups. Actually the situation described by me is even worse because I have my focus on groups who have not enough money to provide several different packages for different distributions, like Skype for example has.
As you can see from this post there is a new initiative to implement an API into the native package managements. The idea is that this API is the same on each distribution and could be accessed by an installer to register files, scripts and in future versions maybe even dependencies. The advantage is that the installer would not need to know which distribution is underneath the API since the API can be implemented by each distribution and would be the same everywhere.
However, nothing has happened yet an the e-mail list is already silent again. I tried to get more information from some of the RPM developers about that, but still wait for answers. I also logged into the rpm-irc channel, and asked around – the only answers I got there were very, very negative.
Still, Ian is very positive about that topic and just asks for a bit more patience:
Paul Nasrat (Red Hat), Michael Schroeder (SUSE), and Seth Vidal (Fedora/yum) were all at the Packaging Summit, and they were all willing. Give it some time. These things don’t happen overnight.
I am not as hopefull as Ian is at the moment, but I will address that problem in a later article. For this time I will just follow the argument that we need to interact with the local package managers: there is currently only one tool available following this path more or less: InstallJammer.
InstallJammer is the “newcomer” of the alternative package generators. I write newcomer because I haven’t heard of the program until I read the linux.com article although the program was started 5 years ago… Anyhow, I asked the developer Damon Courtney some questions and he kindly responded. Therefore this section is a bit more detailed since I have a better in-depth view.
InstallJammer was created out of the need to have a possibility to provide users an easy way to install a specific software.
That was one of the biggest reasons I wrote InstallJammer. I was
actually in the process of writing a game when I started thinking about
how I was going to distribute it. The common idiom would have been an
installer on Windows and a .tar.gz on various UNIX platforms. I really
HATE distributing software with a tar or zip file. It’s ugly, and it
doesn’t do anything to help the user. So, I started work on a little
installer to do the work for me. As time went on, I spent more time
working on the installer than the game, and here we are. That was over
5 years ago.
Currently InstallJammer provides a self executing binary which can create dummy packages for the native package manager dpkg and rpm. These even go so far that removing the rpm or deb dummy the remove process of the InstallJammer package is called. However, the dummy packages do not contain any file names. Also, they do require the native package manager build tools on the users machine.
However, Damon told me that he would love to add the ability to register files with the native package manager:
I would absolutely LOVE to be able to support the adding of files to
the package manager databases, and I would definitely like to extend the
support for other native package managers.
Adding files in dpkg is actually a pretty easy leap because the dpkg
file list is just stored in a text file. I don’t have to muck around
with a specific format or anything tricky. RPM is a lot harder because
the files are stored in a database, and the structure of that database
is not documented or supported for future releases.
Damon also mentioned that the LSB solution of a API provided by the original package manager developers would be the optimal solution – he would like to avoid trying to implement something by his own. Due to the fact that an rpm interaction is quite difficult it is unlikely that the next InstallJammer version will integrate such a thing, however we might see a dpkg integration. Of course, if the rpm initiative takes of we even might see much more integration.
As you see InstallJammer is yet very promising, but doesn’t realize the perfect solution yet. In this regard it strongly depends on the decisions of other people/projects, so we have to wait for future versions atm.
Some final words
You can clearly see now what I see as the only possible solution: a unified binary installer. And that is hot stuff – there are quite some people around who do not like something like that for several reasons. If you also have objections please hold them until I posted my “arguments” post. It will be dedicated to the different pro and contra arguments.