Learn about Linux
Download Linux
Get Linux helpSpecial Offers
Feature
RPM development on the road to revival
Share
Print
CommentsJeff Johnson was the chief maintainer of RPM (originally known as the Red Hat Package Manager) while at Red Hat, for much of the program's life. Johnson left the company in mid-2005, when RPM was at version 4.4.2. He then continued development of the program on his own, distributing his own version at wraptastic.org.
As of January 2007, Johnson's RPM has been updated to 4.4.6 -- introducing a number of bug fixes and significant enhancements such as "recommended" and "suggested" dependencies.
The distros, however, have continued to ship with the older RPM 4.4.2. In part, this seems to stem from residual bad blood between Red Hat and Johnson, and in part from the absence of practical steps on the distros' part to take on active maintenance of the RPM package on which they depend. After Johnson's departure, Red Hat's Paul Nasrat picked up patch maintenance duties, but only on the 4.4.2 branch.
As time went by, it became increasingly clear that Johnson's newer RPM releases, and the now aging 4.2.2 still in use by the distros, constituted two distinct forks. But formally conceding this split would force the commercial distros to formulate a plan to actively develop their RPM fork -- with support contracts to consider, letting such a fundamental piece of infrastructure languish would be out of the question.
The Fedora Advisory Board took up the issue in a mailing list discussion in August of 2006, eventually deciding to solicit input from the other RPM-based distros. In December, they announced the result of their debate: a new community-driven development effort for RPM, to be centered around a revamped rpm.org Web site. The new rpm.org will host a source code repository, wiki, and mailing list.
Red Hat's Max Spevack noted in the announcement that Red Hat will be once again be dedicating a full-time developer position to working on RPM -- but emphasized also that the project wants to draw in programmers, bug hunters, and documentation writers from all of the RPM-using distros and outside parties as well.
First on the agenda at the relaunched rpm.org is a technical review and cleanup of the RPM 4.4.2 code, with the goal of establishing a new branch that will be shared by all of the RPM-based distros. Following that, establishing a better bug fixing routine and improving the RPM Python bindings are the only concrete goals on the roadmap.
When the new initiative will bear fruit remains to be seen. As Spevack pointed out, traffic on the new rpm.org mailing lists was high in December, dropped off in January, and has resurged in February. The grunt-work of fixing bugs and merging patches from the various distros seems to have begun in earnest, and with it more brainstorming about the future of the packaging utility.
If you look at the February list traffic, you will find an increasing number of contributions from outside Red Hat. SUSE, PLD, and even Wind River are represented in discussions on the RPM-maint list. Considering how long the distros maintained their own RPM forks without collaborating, this is an encouraging sign. But, even if it takes a long time for the new rpm.org branch to take off, the move is evidence that Red Hat has recognized the need to make a concerted effort at developing their package management system, and that is good news for Red Hat's customers and a host of third-party users as well.
Comments
on RPM development on the road to revivalNote: Comments are owned by the poster. We are not responsible for their content.
rpmorphan and urpmi --clean curently in cooker
--auto-update
Like --auto-select, but also updates all relevant media before
selection of upgradeable packages is made. This avoids a previous
call to "urpmi.update".
--clean
Remove all packages from the cache in directory<nobr> <wbr></nobr>/var/cache/urpmi/rpms.
The unified packaging system would most likely become the defacto packaging system for almost all free/open systems.
They'd better keep trying to rediscover the wheel.
It's possible that apt might be a tad better
than yum, no one with more than two brain cells
would say that neither deb nor rpm are superior
to the other.
<a href="http://ftp-1.gwdg.de/pub/opensuse/repositories/home:/rbos/openSUSE_10.2/i586/" title="ftp-1.gwdg.de">apt for suse</a ftp-1.gwdg.de>
Unfortunately this really doesn't do much to address any needs. For the most part, RPM and DEB are equivalent formats (they provide largely similar features), and it's pretty straightforward to convert from one to another. Joey Hess's package format comparison shows the gruesome details: <a href="http://www.kitenet.net/~joey/pkg-comp/" title="kitenet.net">http://www.kitenet.net/~joey/pkg-comp/</a kitenet.net> . Joey's also written "alien" which does translations between major packaging formats (to a first approximation at least), including DEB, RPM, and Slack tarballs.
The other problem is that the underlying problem, particularly for proprietary third-party apps, in supporting different distros, isn't the packaging format (though many ISVs will stress and sweat over that), but simply getting compatibility right: files in the right places (FSB), library support, and (in Debian) adhering properly to policy. This is immensely more difficult for proprietary projects than Free Software ones, due as much to the poor architecture of proprietary apps as anything else.
While there's conceivably some benefit to having a unified packaging front, it's only a small part of a larger problem (one solution of course being: well, don't run proprietary SW then<nobr> <wbr></nobr>;-). On the Free Software side, Debian, with its 23,4892 packages (testing/unstable + debian-multimedia.org) doesn't seem to be hurting in a world where many businesses still thinks Red Hat and RPM are all there is to Linux.
The result of a unified package standard together with a standard file system structure defined trough LSB and the possibility of including depended libraries in the package for systems where the distro does not provide the required dependencies would simplify installation of software on Linux-systems to the degree that it would be on par with MacOSX and thus far beyond Windows.
Both OSS-projects and ISVs would benefit as well since they would only need to roll and maintain one single package, leaving more time for develpment.
I would really love to see these great projects put any egos and own plans for domination aside and collaborate for the sake of (almost) all desktop Linux users.
the move is evidence that Red Hat has recognized the need to make a concerted effort at developing their package management system, and that is good news for Red Hat's customers and a host of third-party users
It would have been even better if Red Hat et al had just ditched the old RPM code, and switched to dpkg/apt-get. I guess the "not invented here" syndrome is at work - it's so much easier to re-invent the wheel than to persuade people to use an existing wheel....
It would have been even better if Red Hat et al had just ditched the old RPM code, and switched to dpkg/apt-get.
Well, considering that RPM is part of LSB while dpkg is not, Debian should switch to RPM. But alas, it was not invented there, so they won't switch.
And before any of you starts bitching about apt-get, I'll fire a preventive strike: RPM and apt are two different things, RPM and dpkg are the tools that are used for the same purpose. The fact that there is no de facto fronted á la apt for RPM (although yum is pretty good nowadays) does not make the file format somehow bad. Ha.
updater and cleaner
Posted by: Anonymous Coward on February 17, 2007 05:43 AMurpmi --auto-select is good for a quick update check but inveriably, when I check the grphics RPM manager for updates but even when it tells me there's nothign to update, a quick check of the graphic RPM updater shows a bunch of updates missed by the CLI command.
I belive there is also a urpmi-orphan or similar command to show just the leaves from your dependancy tree. This helps for cleaning out stale packages but there's no urpmi --clean type command.
In that second one, there is the challenge of removing orphans through some verification mecanism to keep from removing depenancies for programs outside the RPM tree (ie. developers libraries independent of the RPM tree but needed for program development)
I'm on a Mandriva box so if the RPM manager is different on the other distros then I may simply be missing something but in my day to day; flaky cli support for package updates and no command or reporting on potential orphans outside of a single column text list are what I bump against most often.
More likely, there are a few solutions and I've just not yet stumbled across them in my websearches.
#