Do we really need another packaging system?
Recently I've been quoted by Steven J. Vaughan-Nichols for questioning the need for the LSB Package API. The kind of conversation going on over the LSB Package API has been a recurring theme ever since I started using Linux, and it contains quite a few fallacies I would like to put down. Most importantly, the most common theme I've heard is that this fancy new system could usher in a new era of easy package installation for users. Let's go over some of these myths.MYTH: PackageKit is just one level of abstraction on top of package management that serves no purpose other than to make things more complex.
REALITY: As stated in said article, Linspire has also created such a layer. There is a huge difference between PK and CNR though. CNR is really more of a user based shopping center for packages that traditionally wrapped on top of Apt. I haven't looked at it at all in the past year, so I am not fully qualified to comment, but it seem to maintain that overall approach from what I've seen.
PackageKit integrates tightly with the Gnome and KDE desktops using some cross platform tools to make managing a system easier. Namely, PackageKit integrates with ConsoleKit and PolicyKit to let administrators fine tune the users control over packages installation. It is a far better solution than giving users access to sudo.
Neither of these layers are redundant. They provide a level of service well beyond what a basic package manager can provide. Furthermore, they provide it in a clear cross desktop and cross distribution fashion. The need for these two tools is clear.
MYTH: There are too many package managers, and the landscape is threatening, and unhealthy for the Linux future.
REALITY: Package managers are developed all the time, because every user needs something different. For the desktop user, package management all looks the same, but this is not true. For the enterprise user, package management is a crucial feature. For the enterprise desktop, being able to mix both these use cases is an optimal solution. Let's examine each one. In this case, we're concerned only with dependency resolution, because the rest is mainly a usability layer on top.
The first reality is that not all package managers do dependency resolution the same, because that's the key point of a package manager. For example, there are a number of dependency cases that only a handful of package managers can solve correctly, such as the libBCD use case. The last time I checked, both apt and yum fail to solve it, but zypper has no problem with it. Even if the user doesn't care, having bad dependency resolution on the desktop can make life difficult for new users as well as advanced power users. openSuSE had the drive to innovate package management a little bit, and it's paid off by having a quality dependency resolution.
Other distributions, such as Gentoo and Crux take two totally different approaches. Admittedly neither of them are intended for the average desktop user, the idea of dependency resolution on both those distros is entirely unique.
In the enterprise, a package manager is not just a tool for delivering software once to a system, but a tool for creating bits of a system out of a variety of components. Deploying server applications, such as java applications can require an incredibly complicated and thorny dependency resolution process. It can include a number of criteria, such as prefered way of deploying java packages (there's about 15 different ways to do it), deploying custom kernels based on hardware, intended work load, configuration of the day, or one-shot actions such as updating the bios or other firmware. It could include other external matters, such as deploying language files for a certain region, because a laptop has been transfered from one department to another as part of an enterprise reorganization. This is overkill for the desktop user, and it is critical that there be more than one package manager in the Linux landscape for this reason alone.
(One of the values of yum is its plugin system. An enterprise administrator can develop all these plugins using the same package manager that normally fits on the desktop.)
Having PackageKit subject to this complex dependency resolution process is good for the enterprise desktop. Certain 'power users' in a company can be given permission to install extra packages from trusted company sources as is needed. Even updates can be handled by the user. To an administrator, this situation is ideal, because he receives two guarantees. 1) the user is getting the right packages, and that the system will likely not break down. 2) the user is empowered to do their job and is a satisfied coworker.
Thus, the conclusion so far is that PackageKit and multiple package managers are a clear necessity to the Linux Community.
MYTH: There are too many packaging formats, some are too archaic. Why can't we just settle on one format for writing packages?
REALITY: The LSB Packaging API uses XML. For that reason alone, there will be at least two packaging formats. Not all of us like XML. Nor is XML the ideal format for delivering package information to every system. For the reasons I stated above, different formats are needed for all the different use cases. A Crux pkgbuild or a Gentoo ebuild is a packaging format fine tuned to the systems they run on. Forcing them to use some other method to package their programs wouldn't make any sense at all.
In the article, the author writes:
Hell, if you really think scripting is the best way to install
software in 2008, why not go back to installing everything by
compiling all software from source code? That works even better
and it will work on any Linux distribution. It’s tedious and
requires every Linux user to also be at least enough of a
developer to be able to deal with gcc, make, and library
compatibility issues, but hey it would work.
This seems to imply that there is something old fashioned in using shell scripts. This couldn't be further from the truth. In creating nearly all packages, there is always some amount of shell scripting that needs to be done. Many packages require some form of post-install and pre-uninstall scripting to be done. The most universal method for doing this on any distribution is a script. The best part of this though, is that it works entirely behind the scenes. I never have to interact with RPM running any script, as the process is completely hidden from the end user. Putting a layer in C on top if this only makes the life of a package maintainer harder.
MYTH: We should have some system of universal packages. The user should be able to get a package from just about anywhere, and it should run automatically on their Linux system.
REALITY: I am not going to go into the MSI installer debate that has been argued to death. Let's address some of the real issues that face the Linux desktop.
Every distribution uses slightly different compiler settings. There are a million and one reasons for doing so, but in effect, no package, neither RPM nor DEB, nor anything else is guaranteed to run on every Linux system. Having some universal package API will not solve that problem, and will only draw users away from the real target they should be focusing on.
Third party software that hasn't been developed with your distro in mind presents a strong problem for everyone. Chances are, it will break your system. Having a common API will not make the problem easier, because there are always a number of other layers to worry about. For example, if the program doesn't ship with an SELinux policy, it will break for all confined users. Using something like the SuSE build service to get the latest Amarok for Fedora would be pointless. Your distro may use an alternate file naming scheme, such as GoboLinux. RPMs would have a hard time working in such a system, let alone some random API.
The reality of the situation is that the differences between distros gives people a chance to innovate more with how a Linux system works. Trying to funnel everything down through some common layer at the bottom really reduces the chances for big innovation to happen. Steven comments that layers like PackageKit and CNR are bandaids on top of a failed process. This is not how I would describe it. They are tools to make the confusing landscape easier for the end user, while letting distributions maintain their competitive advantage. I highly doubt that such a common API will be effective, let alone accepted easily by the community.
But please, prove me wrong.
