Practical Technology

for practical people.

Can Linux find one good way to install software?


I’m not sure when the fights over how to install programs started in Linux, but it was probably not longer after there were three Linux users on the planet. Things haven’t gotten any better.

In part that’s because people never recall their history. For example, when Denis Washington, a Fedora developer suggested on the Linux Foundation mailing list that it was high-time for developers get on the stick and start working on an API (application programming interface) that would enable ISVs (independent software vendors) to “install software packages which integrate into the package manager – the ‘Berlin Packaging API,'” he ran into resistance.

Berlin stalled out so “to reignite the initiative, [Washington] decided to design and develop a prototype implementation of the Berlin API, most creatively named the ‘LSB Package API.’ ‘It is designed as a simple DBus interface accompanied with an XML-based package description format.”

Washington wrote on, “The implementation currently supports integration into RPM and dpkg; due to its modular nature, support for more package managers could be added later on.” He doesn’t see this as the ‘Answer’ for Linux software installation, but rather hopes that “this implementation will act as a starting point for resurrecting the Berlin API process. Let us overcome the “Third-party software installation on Linux sucks” problem and strive to a brave new world of easily distributable Linux software!”

I’ll give this idea a big thumb’s up. Others, though, took a walk into the past with their arguments against it.

Yaakov Nemoy, a new Fedora developer, asked “How is this different than PackageKit?

PackageKit, for those who don’t it, goes down a well-trodden, I’d even say mired and muddied road, of adding yet another level of script complication on top of the multiple packaging systems we’re already stuck with. PackageKit is what I call a band-aid solution. It doesn’t solve the fundamental problem of too many, incompatible package managers. Instead it puts a band-aid of a common set of abstractions over the existing package managers such as yum, apt, and conary.

This approach can work. Linspire has already made this approach about as user-friendly as it’s going to get with its Linux distribution neutral meta-package manager CNR (Click N Run) Since Ubuntu and Mint, two of the more popular desktop Linux distributions, have already embraced CNR, I suspect PackageKit is too little, too late.

Technically, since PackageKit is DBus-based it should be easier to develop and maintain than CNR. As Nemoy wrote, “PackageKit seems to cover the use case of presenting a comprehensive API and userspace tools to manage packages consistently across distros.” Where I feel Nemoy misses is that what the Berlin API can do and neither PackageKit nor CNR ever do, is potentially rid of us of the more than half-a-dozen different package managers that all try to do provide exactly the same services for ISVs and users.

Of course this wouldn’t be a Linux discussion without someone, in this case, Michel Briand, a Debian developer, harking back to the ‘good-old days’ of doing things the manual hard way. Briand suggested that “KISS (keep it simple stupid); why use DBUS!!! When all Debian packaging tools use either Bash either Perl ????? Why complexify things? That’s the root of all evil :)))))))).”


Modern Linux desktop development is all about avoiding going back to the stone-knives and bear-skins method of packaging and to use higher-level abstractions such as DBUS, Xdg-utils, and LSB Package API to make life easier for ISVs and anyone else who has better things to do with their time than to tinker with Bash or Perl scripts.

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.

I could also walk across the U.S. to visit my Linux Foundation friends near Portland but that doesn’t mean jogging is the best way to get there. I really hope Washington is successful in getting some support for implementing Berlin. It’s this kind of LSB (Linux Standard Base) work, not useful band-aids like PackageKit or CNR, or the idea that the Linux desktop is only for Linux experts or developers, that will go a long way to making the Linux desktop the desktop of choice for all users.