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