I’ve been growing ever dissatisfied with managing RHEL with up2date of late. It doesn’t understand the XML Metadata repository format without actually having Yum installed and its feature set is horribly far behind any other updating program. But I think these limitations are already well known.

I’ve been working on some Yum plugins for kernel modules and seriously considering taking a look at what it would take to make Yum understand the RHN repository format. For those of you that might have heard similar rumors in the past, yes I am the person that randomly talks about Yum and RHN. This is not my first time trying to make this happen.

However, Yum was never designed to handle multiple repository formats. Much of Yum works directly with the XML metadata objects rather than abstract APIs. Its a difficult problem to tackle with the current state of Yum. If anyone has a bright idea I’d love to hear it.

There are sevral ways to go about integrating RHN support. What has been discussed in the past is creating an abstract MetaSack to contain many PackageSacks so you could have one per repository type. The PackageSack object serves as an interface to your caching layer and a single interface to query the entire package set from all repositories. This requires some major changes to Yum and I feel is not something I am capable of doing without active work from folks that are more involved with the project.

Another way I’ve looked at integrating RHN support is to be able to transmute information from the RHN protocol into the XML metadata. This idea fails because the RHN protocol doesn’t provide enough information to generate the XML metadata. A lot of the information needed to resolve dependencies must be gathered after downloading the RPM header from RHN or using the up2date.solveDependencies() RPC call. This method ends up requiring that all the headers be downloaded before any dependency resolving can happen.

I have looked at directly inserting the additional available packages from RHN directly into the PackageSack. This method requires you to hand the SQLitePackageSack an SQLite database object. I can’t abstract that. There is much SQL in the PackageSack code. Which goes back to being able to generate the metadata format from the RHN protocol.

I have also looked at creating a Yum Plugin and trying to go around the metadata. In this case it looks like I would be inserting packages into the TransactionData (tsInfo) object. This method would require that I re-implement much of the code in Yum as I need to add the packages as Available, Install, or Update. So I’ve got to figure out what packages are to be upgraded with that particular invocation of Yum.

Alas, it looks like no RHN support for Yum for a while. Hopefully the MetaSack implementation wont be too far in coming.