Computers, Science, Technology, Xen Virtualization, Hosting, Photography, The Internet, Geekdom And More

And the package manager debate rages on

Posted on | August 8, 2009 | 2 Comments

If you ask any *NIX engineer what they love or hate the most about their operating system of choice, many will indicate the package manager. For those of you who don’t use a UNIX like operating system, the package manager is the program that lets you install other programs.

A small group of developers (me inclued) have been hasing out the blue prints for a new kind of server operating system on IRC the past few weeks. Since the package manager is crucial for every phase in the life cycle of an operating system (from installation, to updates all the way to upgrading to the latest release) … it tends to get the most attention in our discussions. 

A lot of my co-developers think that I am anti-RPM, this is not the case. I like RPM, I just think that yum is slow and brain dead. My natural solution was going to something like apt-rpm, to get the power of apt’s dependency resolution and speed while enjoying the convenience and simplicity of building RPMs. Many of you may note, it is very easy to upgrade from a previous Ubuntu long term support distribution to the latest long term support distribution, with zero dependency conflicts.

I can not help but consider how our target audience (developers and system integrators) are going to use our software. How many times have you had to build a library from source because your distro packages a version that is too old to satisfy the needs of an application that you want to install? We’re building an OS that is built for people who run on the bleeding edge of virtualization and cloud computing. We need a package manager that lets people go out of the scope of our repositories safely.

We want to be able to let people decide on a per package basis if they want stable, beta or alpha code. Lets say that you start using the foo program .. and learn that some killer features that you need are in the foo-unstable branch. A good package manager should let you do something like this:

pkgman set foo as unstable pkgman upgrade foo

Then, you decide that you really liked the stable version better:

pkgman set foo as stable pkgman upgrade foo

A big focus of this distribution is to help bring beta projects into broader testing pools. It comes from the realization that emerging companies use emerging technology, its an enterprize class OS for people who simply can’t stay a few steps behind.

Right now, I am looking into apt-rpm to see if I can modify it (without causing regressions) to do what we need. A lot of the other developers are itching to just write something from scratch.

I don’t want to write a package manager, I want to make a distribution and release it before our sun goes supernova. Taking on such a broad task in a hurried fashion is asking for people to stop using our software .. the package manager is critical to the user’s experience.

There are a few other options to explore. Since we are a strictly server OS, we have no headaches with a desktop or the users who use desktops. We’re all about kernels, libraries, protocols and command line utilities.

One option is binary service packs (icky, but feasable) coupled with a system registry. I know that sounds like 10 steps twoard the dark side of the force, however it is practically and quickly implemented.

The other option is to do everything via source build, which I am not yet ruling out.

What I can say is, I’m not going to sign off on anything that proposes using what exists, as it exists. I’m not knocking either yum or apt, I just have certain goals that I really want to meet which neither does.

We’re not just forking some other distro, we’re starting with gcc, libc, linux and the basic GNU core utilities and working our way up from there. Sure, we’ll use things like upstart / udev .. but the end result will be distinctive. Surely, we can pull this off without (ahem) writing a package manager from scratch :)


2 Responses to “And the package manager debate rages on”

  1. Dusty Wilson
    August 9th, 2009 @ 7:23 am

    I’m all for a server operating system, especially one optimized for virtualized environments. I’ve been teetering toward making a heavily customized Debian for my purposes (I’m anti-RPM and very pro-APT). I guess I more-or-less do customize my Debian pretty deeply, I just don’t release it outside of my own servers (as an OpenVZ template).

    “How many times have you had to build a library from source because your distro packages a version that is too old to satisfy the needs of an application that you want to install?”

    Why not just make a new repository with newer stuff in it? I do this when it makes sense. I also do it for a ton of perl modules that aren’t in Debian’s stable.

  2. tinkertim
    August 9th, 2009 @ 10:02 am


    For some things, we can set up a -next, or -edge repository (stuff we know we’re going to backport anyway). This can be done with libraries that are well known to not break their interface from revision to revision.

    When dealing with stuff like Xen (which has now half a dozen shared libs packaged with it) .. you have no such guarantee. Its then typical for people hammering out offerings, control panels and applications to work with Xen to run sometimes 3 – 4 concurrent versions.

    Its not just system libraries, there are emerging control panels, configuration managers, VHD implementations, all sorts of stuff that people tend to run from a project’s trunk simply because its not yet packaged and documented. These things depend on stuff like apahce, python, php, perl, etc.

    In summary, we’re determined to find a way to let people easily test emerging projects, without borking their package db and next dist-upgrade in the process. I prefer apt as well, which is why I’m taking a hard look at apt-rpm. It gives me the dependency resolution we need .. and gives the other developers their wish of using rpmbuilds.

    Its also easier for the maintainers, debian pooled repositories are not the easiest thing to maintain. Since most people working on it currently use CentOS / Fedora .. the idea of debhelper did not go over so well for builds :) But, well, I guess any project is about compromise.

Leave a Reply

  • Monkey Plus Typewriter
  • Stack Overflow

  • Me According To Ohloh

  • Meta