Home / server / Questions / 11712
In Process
jldugger
Asked: 2009-05-24 16:54:19 +0800 CST

Why can't Linux developers create a universal packaging format?

  • 772

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?

linux packaging

10 Answers

  1. 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.

    • 24

  2. 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.

    • 20

  3. 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.

    • 9

  4. 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.

    • 7

  5. Just go for .deb :-)

    • 4

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

    • 2

  7. 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.

    • 2

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

    • 1

  9. 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.

    • 1

  10. 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"/>
  </runner>
</command>

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

    [ Note: I am a 0install developer ]

    • 1