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, derivedrecipes which derive binaries from 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.
Update
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.
/home/liquidat 
Two comments :
1) You might be very interested by what is doing the EDOS project : http://www.edos-project.org/xwiki/ . It’s a european research group working specifically on this problematic.
2) I personaly don’t believe EDOS or any other attempt to unify repositories or simplify installation will succeed. As another user said in your previous post, people will tend to use their distribution’s repository in most of the case and that’s just perfect because those packages have been tested, Q&Aed for his distribution. Developers don’t care about packaging (and they’re right : it’s not their job). Shortly said : yes it’s not a microsoft way of working, but it’s way better. Which OS gives you the possibility to open your software installer and install thousands of software which have been tested for your very own system and which integrates nicely ?
I will look into EDOS, thanks.
About the need for unified binaries: I will have a look at the question were I see needs and were I don’t see them.
And, btw.: Mac OS X provides both: an installer like you are used from Linux distributions (MacPorts) and binaries. And it is just a question of time until we see the first tool like that for Windows.
Your description of klik is not correct.
The klik server does not distribute binaries. It distributes “recipes”. As a rule, the klik client *itself* transforms the $input packages into klik images according to the recipe.
And $input does not *need* to be .debs. In fact, quite a few current recipes do use RPMs, and even .tgzs and .package files.
In the future, it may happen that most klik recipes point to the openSUSE build service instead of the Debian repositories.
However, right now APT provides a way superior automatic dependency resolution. That’s why the klik webserver currently uses “server-side APT” for its automatic recipe creation.
In the future, it may happen that klik uses “server-side smart” or “server-site yum” if these work better.
Read the User’s FAQ. It is to be found easily in the klik wiki.
It was inaccurate, you’re right, I corrected that part.
However, keep in mind that it is a summary. And when I wrote that article the largest part of the $input packages where debs. Of course there were other formats, but these were only few.
Anyway, I don’t get your point about apt. I know about the server side apt, I never said anything else. And I didn’t ask to use something else than apt.