[ Saturday, 17 February 2007, kocio ]
GNU/Linux is known for its diversity and freedom of choice. There are multiple window managers and desktop environments, many competing systems for handling sound, graphics and hardware autodetection. This diversity is the power and weakness of free software. Exactly the same problem concerns installing software in GNU/Linux. There are currently at least 5 popular ways of doing it:
- Installing directly from source code,
- Ports-based installation (where the source packages are held in a repository and can be automatically downloaded, compiled and installed), like BSDs ports of Gentoo’s portage,
- Installing from distribution-specific packages like different versions of RPM, DEB, TGZ, and other packaging formats,
- Installing from distribution-independent binaries (most proprietary software is delivered this way),
- Using another distribution-independent system like autopackage, zero-install or klik — none of them gained a significant market share so far.
This situation is not a problem for experienced users — they can make decisions about choosing the best way of installing software themselves. However, for a newcomer in the GNU/Linux world, this situation is pretty confusing. In this article I am going to sum up some of the recent efforts to fix this problem and examine the possible future of packaging software in GNU/Linux.
Package formats wars
The war of packaging formats in the GNU/Linux world is reaching its peak. The developers of competing formats are doing their best to convert as many distributions as possible to their products. Here is a short summary of the latest activities in this area.
Red Hat Magazine has published an article called The Story of RPM about the history of RPM package manager. It used to be a very strange product. Its ancestors: RPP, PMS and PM were separate projects with similar goals. When RPM arrived, replacing the former standards, it was first being developed under the same name by many GNU/Linux distributors independently, causing a lot of confusion and interoperability problems. Recently, this situation has changed and the major distros (those basing on Red Hat and using RPM) decided to unite and work together on the development of RPM. It’s great news for the distributions like Fedora, PCLinuxOS, Mandriva or openSUSE. Still, a lot of other systems like Ubuntu, Debian, Slackware, Gentoo or Linspire do not use the RPM format and do not plan to incorporate it.
Autopackage slowly vanishes
Autopackage, one of the recent efforts of developers to standardize packaging in GNU/Linux has not been very successful. Despite a promising debut and even providing a stable 1.0 release (the most recent version is 1.2.1, Autopackage is dying. The programmers (actually only one is actively working on the project) believe that the lack of success of the project is caused by the reluctance of Linux vendors who are well accustomed to the current status of distro-dependent package systems and don’t want any change.
It may also be that Mike Hearn — the project founder, now a Google employee — is right. He claims that the project did not gain enough popularity (and none of the distribution-independent packaging efforts did, actually) because of the dominating doctrine which states that it’s the distributor who should be responsible for the whole operating system. It is kind of similar to another popular opinion: that the administrator (root) should be responsible for the whole machine, and all the administrative operations should be preformed from a separate root account. These kinds of centralized management systems fit to the server market, but they don’t really reflect the desktop reality that well. On desktops, the administration is only one of the roles the user plays and waiting for half a year for a new version of an application is often unacceptable. It is often a decade in the free software world!
“I eventually concluded that Linux was never going to make the big improvements to desktop computing that I wanted to see, and, therefore, that it’d never get non-trivial market share. That’s one reason why these days I work on servers for Google instead of client-side stuff for a Linux company.” — Hearn concluded.
Another interesting approach to packaging is presented by the Conary team. Conary is a mixture of a package manager and a version control system. This tool has gained the acceptance of a few vendors and it is feasible that it will be adopted in those systems in one form or another. It is however no revolution since it does not resolve the biggest problem — the incompatibility of the current solutions.
Where does the future of packaging lie?
As far as freeing the packaging from the distributor is concerned, there are at least two directions possible. The first is the wide acceptance of the refreshed CNR (Click-And-Run) system, which is going to support all the major GNU/Linux distributions in the near future (and in time, even more platforms). The plans to make the development of CNR more open creates a chance to gain the community and finally — the vendors. Currently only Linspire and Ubuntu (from version 7.04) support the system, but if few other major distros accept it, it may be enough to spread the new de-facto standard in the Linux world, since most of the distributions are Debian, Fedora, Ubuntu, Mandriva or SUSE-based anyway.
Another option is the fast evolution of LSB’s Linux Standard Desktop Project. Linux Standard Base may help to standardize at least the versions of the core libraries used in the major distros making it much easier to produce general packages in the future. It seems to be a serious option since LSB is already widely adopted in most distributions and the fact that the LSB guys chose to cooperate with the vendors instead of creating the new standard on their own works for the benefit of the standard.
Whatever the future if packaging will be, it is good to see that the Linux vendors (seem to) have finally agreed that the current situation is not satisfactory and the future of GNU/Linux acceptance depends on standards, also the packaging ones. Hopefully, one will be formed in one way or another, soon.
- The home of RPM
- The home of Autopackage
- Autopackage in action [Flash demo]
- Conary on rPath wiki
- Click and Run for all — the new home of CNR
This text is based on a translation of article by Daniel Koć published on linuxnews.pl. I (michuk) added some personal thoughts to it (accepted by the original author).