rPath, Foresight, Conary

I first started speaking about rPath Linux and their Conary package management tool a little over a year ago.  But, I just want to get it down in writing that I think this is the future of linux packaging and indeed distribution management in general.  They took traditional package management (think rpm w/ yum or dpkg w/ apt) and made it look antiquated.  That’s right, apt-get is not the end of the line for package managers.

Conary really takes the problem of managing the software that is installed on your system and fully maps it out.  I feel like they broke the problem down in to small chunks and solved each one of the problems well.  rPath’s main goal is to create tools and a distribution that can be customized and modified by down-stream distributors to create software appliances.  There are a lot of features designed for this task in Conary, but they can benefit other users who may not feel like they have their own customized distribution.  For example, do you have a farm of machines that are running the same software with your own customized configuration files?  Why not create a package that shadows the upstream apache package for example, but includes your own configuration files in the apache:conf component?

One of the other wonderful features of Conary is that the repository is kept in version control and branches are supported by all of the supporting tools.  Imagine if Debian was using a tool like Conary to track and manage their entire distribution.  All of the Debian derivative distributions would be able to have their own branches of the distribution.  This would make it a lot easier for derivative distributions to use Debian’s existing packages and for them to make contributions back to Debian.

There is one problem with the Conary story.  All of the server-side distribution management tools are closed-source.  I do see this as a show-stopper.  Well, a lot of things are using rPath and Conary, and rPath as a company seems to be doing alright, so maybe ‘show-stopper’ is a bit harsh.  But, this will absolutely keep other major distributions and large chunks of the open-source community from getting on the bandwagon.  All I can say is that I hope this will eventually be remedied by the open-sourcing of the server-side components.  The technology feels like such a good thing for the community and for distributions in general, but it’s the kind of thing that can not be entrusted to one company.  Hopefully someday rPath will be willing/able to release the server-side stuff.

Regardless, the feature-set exposed by Conary is, to me, the clear future of package management.  Whether it ends up being Conary that makes it big or some other (possibly completly open source) implementation is yet to be seen.  But I wanted to get this article out there with a date on it so that when it happens I can say, “I called it!”  If you want to play around with Conary on your desktop I would highly recommend Foresight Linux.  It’s pretty bad ass.

OpenID Delegate Plugin for WordPress

I just upgraded my wordpress installation to 2.5.1 from 2.3.3 or something like that.  2.5 is very nice.  The upgrade was really simple and the new administrative interface is pretty slick.  I decided it was time for me to manage my wordpress installation with subversion so that later upgrades are a simple ‘svn switch’ away.  The process of switching was pretty easy because I had scripts in place for backing up and restoring all of the custom parts of the site.

As part of the upgrade I had to make sure that all of the plugins I was using were moved over properly.  The one plugin that I really use is the openid delegation plugin.  This plugin lets you use your wordpress URL when logging in to a site using openid.  All it does is put extra <link> tags in the <head> of your home page that redirect the open id request to your real open id server.  I use claimid.com for this purpose.

I had made a change to the plugin at one point because it would not put the tags on my home page because my home page is a ‘page’ and not a ‘post’ in wordpress terms.  When I originally made the change I sent a patch over to the original author hoping that he would incorporate the change and put the improved version on his page.  He never did.  While moving the plugin today I almost over-wrote my changed file with his original.  Now, my changes amount to 6 or 7 lines of code, but I really didn’t want to have to go finding out which wordpress objects and hooks I had to use to recreate my change.  To avoid this problem in the future I decided to throw it in to my repository.  So, if you use wordpress and you’re looking in to open id, check out the slightly improved openid delegation plugin for wordpress.