RPM “relaunched” at rpm5.org

The RPM Package Manager (RPM), fundamental to an array of Linux distributions and the Linux Standard Base specification, has been on uncertain ground as a project in recent years. The versions of the utility shipped by the various RPM-based distros have slowly branched off in different directions, leading in some cases to stagnation. Longtime RPM maintainer Jeff Johnson took a big step this month toward revitalizing the application by relaunching rpm5.org, a site dedicated to reassembling the divergent RPM developer community and putting together a unified plan for future development.

Johnson has maintained his RPM development tree at wraptastic.org since late 2005. While most Linux distributions ship RPM 4.4.2, Johnson continued to fix bugs and add features. His tree, now at version 4.4.9, is the basis for the rpm5.org work. In addition to bug fixes, it supports some notable improvements over 4.4.2. You can download source tarballs and .rpm packages for RPM itself and several language bindings through the Files section of rpm5.org

End users will notice the newer utility’s ability to automatically detect and remove stale locks in the RPM database. Stale locks occur when the database becomes stuck midway through a package installation or other task, and the RPM process freezes up or crashes — meaning no new changes can be made until the lock state (and possibly the database) has been repaired.

More of the advances in 4.4.9 are useful to developers and package maintainers. Johnson lists erasure ordering (through which RPM can specify the order in which packages are removed, and thus increase the safety of deinstallation) and simple multi-lib packaging (for systems that mix 32-bit and 64-bit binaries) as the most significant.

Support is in place for more complex dependency checks, such as negated dependencies (in which a package is dependent on the absence of another), run-time probe dependencies, and doubly-linked upgrade chains (to keep track of upgrades). RPM is also, he notes, one of the first projects to use the Native POSIX Thread Library in Linux.

Reestablishing community

Johnson already has technical goals in mind for future releases of RPM, but describes the establishment of rpm5.org as an effort to unify the RPM community base — which he describes as fragmented and forked. As vendors grew in size, he says, the risk factors associated with changing a core utility like RPM grew in kind, and development stagnated and diverged out of necessity.

Thus, before RPM can move forward, the existing branches need to be pulled together and all the patches integrated. The result of that unification work, Johnson says, will be RPM 5.0, the “everywhere compatible” release.

Though he predicts that settling on a definition of “everywhere compatible” will be harder than integrating the patches, he thinks that establishing a vendor-neutral outlet for development is the right way to do it, and is optimistic. He has already recruited developers.

“Assembling the team was easy. I’ve known almost all the RPM developers through years of email and IRC and bug reports.” The team’s roster is publicly available at rpm5.org, and it has published a preliminary roadmap.

Distribution and standards support

But Johnson’s is not the only contemporary effort to revitalize RPM development. As we reported in February, Red Hat has assembled its own team to clean up the RPM package used in its Linux distribution and cultivate development. Like many distros, Red Hat has continued to ship RPM 4.4.2 rather than Johnson’s updates, and bases its cleanup and modernization work on that release, through rpm.org.

Two concurrently developed forks present RPM-based distros with a dilemma. Should they diverge to the point of incompatibility, distros would be forced to support one or the other.

Even in the meantime, they must choose where to concentrate their time and personnel resources. Novell has joined Red Hat in the rpm.org project, while Mandriva, cAos, and PLD have decided to work with Johnson’s rpm5.org effort.

The RPM package format is also a key component of the Linux Foundation‘s Linux Standard Base (LSB) specification. Unlike other LSB components (such as the Filesystem Hierarchy Standard), RPM is not under the Linux Foundation’s governance.

Linux Foundation Marketing Director Amanda McPherson acknowledges that forking of the format is a potential problem, but one to which there are solutions.

The addition of new features to the file format is unlikely to break compatibility, since the LSB mandates only a subset of RPM’s current capabilities. “The biggest reason for this is to maintain compatibility with alien,” McPherson says. Similarly, if one of the forks decided to change the format and break compatibility, an alien-like conversion utility would solve the problem.

In the long term, she says, the LSB is likely to follow prevailing practice. “If there’s a split, we’d have a difficult decision to make. But if most distros use one or the other, we’d gladly follow that. Generally you find broad convergence by the distros. The LSB process itself helps to drive this consensus.”

Johnson, however, thinks that the likelihood of such a divergence is slim. “For what it’s worth, I will readily integrate any and all of rpm.org’s patches into rpm5.org.” To reject patches because of where they came from, he says, would be repeating the not-invented-here mentality that contributed to the vendor-specific divergence in the first place.

Johnson hopes to release the first RPM 5.0 packages resulting from the patch integration effort before year’s end.