Where would we be without science fiction? Probably in the dark ages. So much of our day to day technology that we take for granted was originally thought of in some form of science fiction like Star Trek. Do you talk into your flip phone like Captain Kirk? I thought so.

Unfortunately, I’ve yet to read a good book with an imaginative and futuristic approach to package management. I just don’t understand why this couldn’t be on the best seller list. Well, maybe I could. So, what’s with RPM, dpkg, tar packages, portage? Its all ancient technology. I mean, this is so 80’s man!

They are all slow. Have you installed an RPM lately. Wow it takes for ever.

We’ve been patching source code with the ‘patch’ command for how many years? Yet when a new OpenOffice.org security fix comes out we get to down load how many megabytes to fix a one-liner?

Conflicts, Obsoletes, Requires…oh my! RPM has gotten amazingly complex over the years. Every time there’s been a new packaging problem RPM has had a whole slew of functionality patched in. Have you ever dealt with multilib packages with RPM? Quick! Somebody claw my eyes out! Now we have versioned obsoletes, implied obsoletes. When folks joke about running “rpm –emacs” I really am surprised that doesn’t work yet. If you’ve had a good run at package management and a good tool like Yum or Up2date you know that solving dependencies is no simple task. That’s hard code.

One of my very favorite problems with packages is what happens if you want to make a change or need to for some reason. You have to roll a new package with your changes and push it out to your clients. You have to deal with what happens when the Red Hat Network pushes out a higher version that your package which effectively undoes your changes. In fact, you have to maintain your very own, completely independent branch for this package. Now what if its one of those Fedora Core packages from hell? Try the perl package, or sendmail.

Fortunately, there’s light at the end of the tunnel. Well, maybe somebody with a match and a magnifying glass. Put on your graph theory cap. Think, from a high level, what are we doing with package management? Hint: we do with all the time with our source code. Answer: Change Management. Definitely a different problem subset than what CVS, Subversion, or any other SCM I know of, but it is in the same superset. Think of a tree or graph of package objects. The graph contains each file. Like any SCM you can retrieve any version of a file or package object. Now think about having a set of these package objects installed on your machine. You can control what versions you have installed. A local change in an object becomes a node in your local graph. Think about updating an object and your machine dealing with a change set of exactly the one line that changed upstream.

Makes your brain hurt doesn’t it? Is it worth something? You bet. Is it complex? Yeah, that too. Is it the future of package management? I honestly don’t know. But its designed from the ground up to deal with today’s package management problems in a sane way. Its designed to be extensible into the future. Its designed to help folks make changes and modifications to Linux distributions and not be forced to completely branch off from your vendor. Its called Conary. You should learn about it.