RPM 5: a Fork in The Linux Packaging
Page 1 of 1
The newest version of the popular RPM package manager is now out with improved performance and functionality. But there's a bit of a catch with RPM version 5.0.
Linux vendor Red Hat officially considers RPM 5.0 a project fork.
"RPM5 is a fork of RPM, and is not related to RPM.org," Daniel Riek, Product Manager Red Hat Enterprise Linux told InternetNews.com. "Neither Red Hat or Fedora are involved in RPM5, and have no current plans to use it. Red Hat remains committed to the main RPM.org releases and development."
RPM is considered one of the great open source innovations from Linux vendor Red Hat.The RPM package manager is known for simplifying the way applications and code can be packaged, managed and installed. RPM, which was co-created a decade ago by former Red Hat engineer Erik Troan, originally stood for Red Hat Package Manager but now RPM is a recursive acronym.
RPM has also become the standard package manager for other Linux distros, including Novell's SUSE Linux and Mandriva Linux.
The RPM5 effort is run by former Red Hat employee Jeff Johnson, who had led the RPM.org development effort for a few years. Johnson noted that RPM5 effort is currently a pure volunteer effort community effort. No one gets paid for their work. The RPM5.org effort, while separate from RPM.org, actually uses the same core code base, which is open source licensed. Johnson himself isn't keen on the split.
"It's pointless to waste the effort and the bottom line is all these people are welcome at rpm5.org anytime they want," Johnson told InternetNews.com. "It's not going to happen because it's really important for Red Hat to re-establish and send a message to its customers that it is the Red Hat Package Manager. So I'm not going to hold my breath, a lot of this is just smoke and mirrors on the surface."
For its part, Red Hat's Riek argued that Red Hat continues to be a very active participant in the RPM.org community, along with the other major RPM-based distributions.
"RPM is the base of Red Hat's product build and packaging process, so encouraging its growth and stability are of the highest priority," Riek said.
But is it really a fork then? RPM5's Johnson noted that he makes a daily pass of all the code check ins that are made at RPM.org and, in his view, there are none that are not carried into RPM 5. That is aside from what he referred to as cosmetic differences, though he stressed that, in his view, there is no major feature that is implemented in the rpm.org codebase that isn't in RPM 5.
Erik Troan, CTO at rPath and the co-creator of RPM a decade ago, isn't keen on the split in RPM either.
"I hope it doesn't lead to incompatible versions of RPM," Troan told InternetNews.com. "It seems inevitable that the branches will diverge from each other."
Johnson said he isn't looking for incompatibilities. "It's pointless to introduce incompatibles as this is a mature product and it does its job well," Johnson said.
That said, Johnson and his cohorts at rpm5.org have done their best to try and make RPM do its job better.
"This is a once in a decade opportunity to actually change a package format," Johnson declared. "I spent a lot of time rewriting at the actual format level and abstracting it differently. This code hasn't been seriously touched since originally being written in 1997."
As part of the rewrite the rpm5.org developers took aim at what Johnson referred to as 'ugly performance flaws'. As a result of their efforts, Johnson claimed that RPM 5 is ten times faster than its RPM 4.x predecessors when it comes to querying packages.
RPM 5 is also about more than just Linux. RPM 5 contributor Ralf Engelschall helped with an automated build platform for RPM 5 so that the RPM 5 code base is now available for BSD, Solaris and Mac OS X.
While the RPM package format is widely used thanks to Red Hat, SUSE and Mandriva, it isn't the only open source package format. Erik Troan and his team at rPath have built the Conary package format, though in his view RPM and Conary were built with very different goals.
"RPM is focused on allowing a small group of developers to produce a single Linux distribution," Troan told InternetNews.com. "From the beginning Conary's goal was to allow widely disperse developers to collaborate on developing Linux-based solutions. It allows Linux distributions to derive from one another while preserving the relationships between them."
Johnson argued that while the Conary approach has strong merits, the potential issue is that with Conary users are tied into a version control system. In Johnson's view if that version control system goes down, than the users will have trouble. That said, Johnson also noted that there may well be some ideas from Conary that he may want to include in a future version of the RPM 5 effort.
RPM also faces competition from Debian Linux and distributions that are based on it like Ubuntu that use the .deb package format. Fundamentally though in Johnson's opinion there really shouldn't be a contest between packaging systems.
"In the future we will be trying to read Debian packages with RPM as there is no reason to prefer Debian or RPM but there is a need to stop arguing about it," Johnson said. "The only way I know how to do that is do read both. It's way past time to eliminate the barriers. "