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.


  1. Pingback: » The Berlin Packaging API: the Solution?

  2. Pingback: solution found to problem: problem yet to be found « Iwbcman’s Weblog

  3. As a developer of a FOSS project, I can speak firsthand to the issues involved in packaging. First and foremost, it is hard. An application of any complexity has requirements that probably require human intervention at some point between the project team and the end user.

    I used to support the Linux Standard Base (LSB) initiative, but have come up against far too many of its limitations. The LSB basically addresses compiled programs with no interfaces to other applications. Here are some of the issues that it cannot resolve:

    – Libraries: My biggest complaint with the LSB is that it is a ‘thou shalt not’ specification. The allowed base libraries provide support for only the most trivial of programs. The “solution” is to compile excluded libraries into programs statically. This requires the developers to research the libraries and insure that all of their excluded dependencies are statically linked. I will leave it as an exercise for the reader to come up with at least 5 ways that this approach drives developers away from porting applications to Linux.

    – Interpreted languages such as Perl, PHP, Python, or Java: There has been no definition for these at all, and although the most recent version added Perl and Python, the definition takes the same ‘thou shalt not’ approach as with libraries.

    – Databases: Again there is no definition for which one or the minimum version required.

    – Startup: The definition defines what an init script must provide but does not explain how it gets installed to be available at system boot.

    – Application documentation: No mention.

    – Security/bug fix updates: No mention. In fact, the underlying philosophy of the LSB would create an environment where each vendor is responsible for providing an update method, leaving administrators with the responsibility of hunting down announcements (like that of the Microsoft platforms), and ruining one of the best features of Linux distros.

    Compare this with the most prevalent package management systems, DEBs and RPMs. These take a ‘Yes you can’ approach, and even a ‘Perhaps you would also like’ attitude. They allow the packager to define everything that is needed for the application, including minimum versions, without having to worry at all about the details of installation. They provide automated update facilities. And when creating a Debian package, the ‘lintian’ utility is run to verify its correctness and will call out programs that do not have man pages among other things (I haven’t built an RPM so I can’t speak to its requirements).

    For over a year now, I have been advocating that a utility for developers to easily create packages for specific distros (such as the ESP Package Manager at and repositories for developer maintained packages be supported by the distros. This would allow project teams or vendors to include their applications in the ecosystem of the distro package managers, which I believe is the best, if not only realistic, method of handling installation issues in Linux distros.

    Later . . . Jim

    The Realeyes IDS, check it out at:

  4. Thanks for the great post, I hope more Linux users read it.

    One thing that I don’t like mentioning but you have to be careful of is that the companies behind Linux distros may not always have truly modularizing Linux software in their best interest. If they wanted to be mean, they would try to prevent any software on their systems from being modular so that users would be forced to install their OS to have access to certain programs. Of course, that’s ridiculous, and things shouldn’t be that way. Not to mention, by embracing things like that, if any of them are, they are shooting themselves in the foot since Linux needs all the mutual help and working together it can get, and there’s just so many ways that making software installation easy will solve. Linux adoption will take off so much faster after this is solved for too many reasons to list here. All we need is some point of standardization, SOMEwhere, like most all the package managers being able to use all the different package file formats, or being compatible with a new format or better yet, a container format for packages. The Berlin API sounds like it will be the best solution by far, though.

    To JJS: I’m not suer I follow the problem, the LSB sounds really good to me as long as they make it easy to see which non-common libraries aren’t included in it, so you can include those with your program. They definitely need to make this process easier for you, it sounds like. Any libraries which get really heavily used can be added in later LSB revisions of course. When downloading packages from websites, they could contain a URL for automatic updates, and check to see if any of the libraries were already installed to reduce wasteful downloading.

    A good goal would be to have there be no need for a distro to have a repository. Instead, there could be one repository if you wanted there to be, the Linux software repository. But of course that wouldn’t happen and there’d be multiple ones still or at the very least multiple mirrors. The Sourceforge repository, Freshmeat,, etc etc.

    Any way, I definitely don’t think your method of continuing to do things the way they’ve always been done is at all realistic. We don’t want to compile packages for specific distros, vendors can’t and won’t do that nor is it at all fair to users running distros that are lesser-known. We want programs compiled once, and have them run on all Linux distros. All it takes is a small commonality in all package managers or on all distros to give users the ability to install any kind of package. That’s what this post is about, and it’s what we want and need.

    No problems are impossible to solve, and this one in essence is very simple, it just needs a modular, flexible, expandable solution so that it can adapt to new software and new libraries and the future while allowing previous software to continue to function. It CAN be solved, and it will be, and without any detriment to anyone. Even talking about performance issues, I don’t believe deep integration is the key to performance and definitely not helpful for software modularity. I believe programs can be very modular while still very fast, it just depends on how well they are programmed.

    Any way, go standard API to release us from this locked-up limited software prison! 🙂

Leave a Reply