8. The package management

Along with the response time in providing with security fixes and the supported lifetime, this is often a factor neglected by the "distros for the enthusiasts". As Linux is generally insensitive to the worms and viruses that threaten the Windows systems, most home users only care about a newer version of a package if it's about an application of interest to him. Errata and patches are not his concern. This also allows him to switch distros just because a given release of a certain distro has a better hardware support.

Responsible use of a Linux system should consider that (again, along with the errata response time), the reliability of the package management system is of the utmost importance, as the integrity and the availability of the system depends on it. The quality of the provided packages is also important, otherwise automated system updates might break the system (this happens more than once in a while with Ubuntu, which questions its suitability for the enterprise).

The good news is that most of the system use either the Debian APT system (apt-get & friends, Synaptic, aptitude), or RPM-based utilities like yum, Yumex, YaST. The over-hyped SMART package manager is able to deal with sevral types of packages and repositories, yet I have difficulties to understand the high level of praise it gets. Because, let's face it: the alleged "RPM hell" is a myth. There is also a "DEB hell" (I was in there myself), and the real problem with the unsolved dependencies is the lack of quality of the repositories. This "repository confusion" is even easier to attain by users who follow the friendly advices from the countless Ubuntu-related forums and blogs and add dozens and dozens of unreliable third-party repositories.

The bad news is that some distributions seem to have a masochistic pleasure in regularly break the package management tools.

This happened in the most unpleasant manner with openSUSE: defocusing from the traditional YaST-based package management, Novell brought the alternate libzypp-based generation of Zen tools. When first released with openSUSE 10.1, they achieved the rare performance to have both package management systems rather broken than functional. Things were mostly fixed later, but some disappointed customers leaved SUSE (that was before the Novell-Microsoft agreement), as it's hard to provide a worse message than "we don't know what package manager we want to offer you, and we don't know how to make them work either". The simplicity was also affected by the increasing number of package management tools: rug, zypper, zen-updater, zen-remover, zen-installer...

Fedora Core started the new generation of GUI tools Pup (updater) and Pirut with FC5. They were both very buggy, and while things have improved in the meantime, their design is horrendous. To me, Pirut is more like a joke than like a package manager. The GUI for yum that I liked, namely the version of Yumex that came with CentOS4 (yumex-1.0.2), was replaced in newer Red Hat distros by either the much slower yumex-1.2.2, or by the unfinished, buggy yumex-1.9.5. Definitely, some steps backwards.

Mandriva has the misfortune to ship its 2007 release with a broken RPMdrake The command-line interface tools worked fine, but RPMdrake 2007 was systematically breaking the list of the available, not installed packages. RPMdrake was fixed for several times, and broken for about the same number of times. The last time I checked it, it was working fine though.

Apparently, the APT tools are still one of the best choices. Newbies can enjoy the extremely friendly Synaptic, while more advanced users can use the CLI. Well, it's known that the intelligence of Synaptic is limited: no matter how pleasant its interface might be (with a lot of information for the advanced users too!), the only tool that can fix all the problems is the ncurses-based aptitude. Which is horrendous from the usability POW.

And you guessed right: instead of extending Synaptic with the intelligence bits from aptitude, the Debian guys have decided to declare aptitude as the default package manager. Isn't this a charming decision?

Some will declare the Smart Package Manager as the savior. I don't think so: it is marginal, and the study cases that claim to prove its superiority are unconvincing.

Hopefully, Linux Standard Base will eventually be of some help. As Ian Murdoch recently said in an interview, «In terms of packaging, yes, there is clearly need for a packaging standard. Because you just go look at a downloads page of any Linux application – MySQL is a good example – and they've got 15 different packages. Here's the RHEL 4 version, the RHEL 5 version, the Debian version, the whatever version, and in part the LSB is designed to solve the problem.»