Vendor binary package format selections appear to be determined by a form of Murphy's Law: all the distros you don't use have packages. (Corralary: there exists no distribution that satisfies your software stack's distribution dependencies).

Is this a matter of politics, or something deeper, that we haven't seen the emergence of a "build once, run anywhere" package format?

  • 3
    you seem to have only a superficial understanding of what differentiates distributions from each other. unifying the package system would still not mean that packages are interchangeable between distributions. your question is thus meaningless.
    – user1686
    May 25, 2009 at 12:48
  • 3
    hop, why don't you write up an answer that gives a less superficial description of the differences between distributions? The question is stated naively, but there's a deep technical answer waiting to be given.
    – jldugger
    May 29, 2009 at 14:44
  • You're really looking for the "Linux Standard Base"
    – Bill Weiss
    Aug 18, 2009 at 20:48
  • Why can't Windows developers create a universal packaging format either? Not bagging Windows here, but they have just as many methods of installing software, and no single repository like Linux has either... (this is a rhetorical question, btw) Aug 27, 2009 at 22:14

10 Answers 10


It seems appropriate to quote Joel Spolsky on this one:

(By the way, for those of you who follow the arcane but politically-charged world of blog syndication feed formats, you can see the same thing happening over there. RSS became fragmented with several different versions, inaccurate specs and lots of political fighting, and the attempt to clean everything up by creating yet another format called Atom has resulted in several different versions of RSS plus one version of Atom, inaccurate specs and lots of political fighting. When you try to unify two opposing forces by creating a third alternative, you just end up with three opposing forces. You haven't unified anything and you haven't really fixed anything.)

(emphasis added)

You have (at least) two packaging systems for Linux. That's actually a good thing. A single system will simply create a third system.

  • 2
    Re: When you try to unify two opposing forces by creating a third alternative, you just end up with three opposing forces. see also: xkcd.com/927 Feb 25, 2013 at 19:42

There are many reasons for this, and a bit of history is in order to put things into perspective.

Remember that when we talk about "Linux" what we are generally referring to is one of many different Linux distributions. "Linux" is actually just an operating system kernel.

The original goal of Linux was to create a Unix-based system that would run on PCs (initially the 386). The first step was to create the kernel itself. While Linus Torvalds was working on the kernel Richard Stallman was working on his own Free Unix system, under the GNU (GNU's Not Unix) project. To cut a long story short, the two somewhat converged because GNU had the associated utilities (C compiler / library / build tools, shell, text editors etc.) but no core to run it on, and Linux had the core but no utilities to run on top of it to make it useful for the masses.

This convergence came to be known somewhat officially as GNU/Linux. You will see that a lot of distros still refer to themselves as GNU/Linux distributions.

Because of the Free and open nature of GNU/Linux anyone could pick it up and create a bundled system to their specific tastes. The result was that many different streams of varying configuration methods were used to create these systems, which had the side-effect of creating almost as many different package management systems to fit in with each one.

Each different complete system had its own strong followers who stuck with them over the years, resulting in what we have today: a handful of widely used, deeply-rooted and stable package management systems like RPM, APT / dpkg and Gentoo's Portage.

There are projects, such as Autopackage, which are attempting to solve the problem, but the continuous evolution of the various supported package management system means there are many moving targets to follow.

What some software vendors end up doing is bundling the specific binaries and copies of dependencies they require into one large package which will work on specific systems.

  • 8
    There's more to it than this. Even if the whole world unified on say rpm, you still wouldn't have the package once, run anywhere world that the OP envisages. Packages are specific for the most part to their distro, since they rely on all the other packages. The only way to have a "package once, run anywhere" world would be to have not only a single packageing system, but also only a single distro.
    – Cian
    Jul 16, 2009 at 13:12

Having the same package format wouldn't help anyway. You just can't use the same package in other distributions. You can't often even use it in the different version of the same distribution. And even building the package can have the same problems.

To install a package you need to meet the dependencies that are formed during the building of the package. To build a package you need to meet the build dependencies. And these things change. To be able to implement the changes, it is easier to support only packages you can modify to work after the changes.

If all the dependencies would be the same, it wouldn't be a different distribution or different version of the same distribution.

  • 4
    Wouldn't it be possible to version libraries and use version dependencies to solve the problem you mention?
    – jldugger
    May 24, 2009 at 19:24
  • You mention that you can't use debs from one version on another. That isn't entirely true, there are exceptions to that rule. If the package is mostly python, or if all the bits where statically compiled then you can. There are even a couple vendors that simply include all the dependencies as part of the package, this wastes disk space, but makes a cross-platform package.
    – Zoredache
    May 24, 2009 at 20:55
  • Even if a packages is arch:all, or scripting languages, theres significant differences between python2.4 and python2.6 that will cause a package that works in the platform it was built for, and fail on others.
    – jldugger
    May 25, 2009 at 16:15
  • Yes, it is not just about library dependencies.
    – iny
    May 26, 2009 at 4:00
  • Some of the debian updates have changed where files were supposed to be put, or provided standardised systems for updating config files that were previously managed manually .. this sort of thing is very version/distro specific.
    – pjc50
    Sep 10, 2009 at 13:04

There's a bit of "Not Invented Here Syndrome", I think. Debian's packaging system predates RedHat, and yet it's superior in many ways, but you'll never see RedHat switching. Instead, you see a lot of people using "apt-rpm" that attempts to give you some of the advantages of apt with rpm files.

  • 4
    apt-rpm has dead for quite a while (last release over 1½ years ago) now and most people have moved to use yum. Yum itself provides quite a lot of nice features that outshine apt's offerings..
    – rasjani
    Jun 23, 2009 at 20:58
  • 1
    I don't believe Debian's packaging is better than today's Redhat's. It used to be that Debian had a better update system, but that doesn't seem to be true anymore, by far. Yum has gotten very good. Still slow compared to Smart, but very manageable.
    – niXar
    Aug 6, 2009 at 19:26
  • 1
    All I know is that last time I was working on CentOS, we were far more likely to get into dependency hell, and switching to apt-rpm fixed most of those problems. Aug 6, 2009 at 20:24
  • 1
    Redhat's RPM packaging suffers from EDS (extreme dependency syndrome.) This is not a commentary on RPM but rather Redhat. Yum is a nice copy of apt-get plus apt-search, and brings usability to the previously arcane world of RPM command line invocation.
    – kmarsh
    Aug 27, 2009 at 21:09
  • 3
    actually, .deb and .rpm package formats are about even technically (but, IMO .deb has better dependancy handling, esp. versioned dependancies, provides, conflicts, and virtual packages). apt-get is what shines on the tech level, but what really makes debian's packages stand out is the well-defined set of developer policies that set the standards that packages must comply with. ubuntu packages inherit that to a large extent, and ubuntu also inherit also inherits the developer culture that goes with it.
    – cas
    Aug 27, 2009 at 21:56

Just go for .deb :-)


There were several tentative formats, like zero-install and autopackage. Unfortunately none gained any traction.


I think cletus, Wayne, and iny answered this pretty well. I'd like to add that really, it's not a huge deal. I work in a mixed environment where we have Gentoo (portage), SUSE (rpm/zypper), and OpenBSD (packages and ports). Installing packages on any one of them is not difficult, and I don't really care what format they are using.

From the perspective of packaging software, it's not overtly difficult either. Be it Gentoo, an RPM-based distro, or a deb-based distro, it really just boils down to having recipes for building the software and adding some metadata. Provided the build system of what you are trying to package is not totally insane, usually it takes little more than writing a glorified shell script to create a package.


Well there are always statically compiled binaries in tar balls.... ;-)

  • 2
    AKA "Slackware". Jun 23, 2009 at 21:35
  • Unfortunately there are issues with statically compiled binaries that need to load system libraries at runtime (especially nsswitch).
    – pjc50
    Sep 10, 2009 at 13:07

There is no definition of a standard binary interface for "Linux" since that is just a kernel. Odds have it your software stack will need to interface with more than just your kernel, presenting a particular challenge of maintaining a standard ABI between hundreds of disparate source trees.

On the topic of good packaging tools, I prefer Debian GNU/Linux for it's excellent binary packaging format. It has served 90% of my needs for standard tools and applications. The remaining 10% is built from source due to inclusion of non-free components or buggy shared library dependencies. When those applications need to be deployed, I build custom binaries for the production clusters.


To get a build-once, run anywhere package format without forcing everyone to use the same distribution you need a couple of important features:

  • Globally-unique package naming, so that two people/distributions can't independently create different packages with the same name.

  • The ability to parallel install different versions of libraries when packages have conflicting requirements. A distribution can decide which version of each library to use, and force all packages to use that version. A system that works across distributions must be more flexible.

Zero Install provides both of these features:

  • Names are URIs (e.g. http://rox.sourceforge.net/2005/interfaces/ROX-Filer). Only the owner of a domain can create packages within that namespace by default.

  • Each version of each package goes in its own directory. Each application sees just those libraries it needs, with the versions it is compatible with.

For example, the Edit application depends on Python < 3 like this:

<command name="run" path="Edit/AppRun">
  <runner interface="http://repo.roscidus.com/python/python">
    <version before="3"/>

See also: http://www.osnews.com/story/16956/Decentralised-Installation-Systems

[ Note: I am a 0install developer ]

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.