In my article series regarding software installation on Linux the last article outlined what my position and also point of view is. This article deals tries to give a general overview about the current techniques available on Linux. This is done mainly by linking to different articles and posts.
There are quite some ways to install software on Linux. They can be divided into two areas: the systems provided by the distributions, and the alternative approaches by 3rd parties. Also, there are some information and standards provided by the Linux Foundation. Since Linux.com is featuring a series on the different techniques I will link to many of their articles, but will include official pages and some times other posts as well.
A last word: sometimes you can differentiate between a package manager (like rpm or dpkg) and a software manager (like apt or yum). When this is possible, I will concentrate on the base level, the package manager, because before that isn’t addressed there is no need to start thinking about the software management (like updates, and so on).
Main distribution tools
Here are the best known and widespread distribution tools to manage software packages:
- rpm – Used in some major distributions like Mandriva, Fedora and Opensuse. Unmaintained for quite some time, but now revived. Can be used together with software management tools like apt, yum, rug, yast, and so on.
- dpkg – Used in Debian and its derivatives like Ubuntu. Normally used together with apt. At the moment there are thoughts on the devel list to include a trigger function.
- tar.gz – Slackware’s package format, uses (more or less) pkgtools to deal with them. No dependency handling included in the native manager, though.
Other solutions like Gentoo’s ebuilds/emerge couple or the Gobolinux attempt deal with compiling source automatically on the user machine. But this article series is dedicated to users with normal needs and normal machines, which are not able to compile a decent piece of software in any convenient time.
Main alternative tools
Next, here are the main alternative attempts to simplify the software installation on Linux:
- autopackage – GUI based self installers. Ignores local package system. Has acceptance difficulties.
- klik – Uses server side provided
binaries, derivedfrom existing debs (or sometimes rpm or others). Works on most debian based and Suse. Easy management, but only usable with GUI apps. Ignore local package system.
- Zero Install – A user based software system which relies on online storages of the application. Ignores local package system. Linux.com-article
- InstallJammer – Current newcomer, using self installers. Can create meta rpm/deb packages also. Can also be used to create installers for Windows.
- checkinstall – Creates native packages automatically from sources. Addresses mainly software developers to be able to easily provide different packages.
Except checkinstall all these alternative attempts address the user somehow – therefore they all require a first, additional action by the user. Since none of these applications provide really large software databases and also because all of them are not tight integrated with the underlying package management, none of them has gathered enough steam (yet) to be *the* alternative.
Checkinstall on the other hand provides developers the possibility to create native packages, however the quality of these packages is debatable and not comparable to the quality of native packages provided by the repository maintainers. Still, sometimes I wonder why checkinstall isn’t used by more developers…
Linux Foundation attempts and information
The Linux foundation also identified the problem already quite some time ago. This lead to the creation of the LSB package standard which is mainly a rpm package. These can be installed with “alien” on Debian based machines as well. However, LSB-rpm packages never really became mainstream.
This problem was identified by the chair of the Linux Standard Base work group, Ian Murdock. I agree with him on almost all of his points mentioned in that blog post, although I do not care about proprietary software – its totally sufficing to look at FLOSS only, the chaos is big enough there.
If you want to comment on some of Ian’s arguments: hold it. As I said, there will be an article dedicated to the question if we need or want such a unified installer. Keep your arguments until you’ve read that one.
Yoho pointed me to the EDOS project (thanks for that!). It is a scientific analysis of the problem and provides papers, software and related stuff at their project page. It is supported by the EU with over two millions, I will try to get more information on that while I’m writing.