RPM is not the only one
Posted Aug 23, 2006 7:40 UTC (Wed) by
joey (subscriber, #328)
Parent article:
Who maintains RPM?
rpm is not the only peice of software that is a major component of many linux distributions but has no agreed-upon upstream maintainer, and thus effectively one fork per distro. Another such peice of software is cron.
Vixie cron was last released in '93. In many distributions it's still used,
but in eg, Debian, the package is the result of 13 years of patches on top
of that release. The debian version number is 3.0pl1-96. That's ninty-six
versions based on 3.0pl1. The Red Hat sub-version is in the fourtys.
There's no standard version anymore, just this pile of patches, and other
piles of patches in other distributions. If we're lucky, they at least
share the same security fixes.
Another example is makedev, which was had its last upstream release in '98
and is at patchlevel 82 in Debian. Or netcat, last released in '96,
patchlevel 32 in Debian, and a fork/rewrite at netcat.sourceforge.net. Or
xgalaga, whose upstream author has fallen off the net and last released it
in '98. The Debian package, which I maintain, is at patchlevel 37,
and seeme to be the only place a lot of people can find to send patches to.
But I don't want to be its upstream maintainer.
This is the kind of thing that makes me gibber in horror when people at
Ubuntu talk about Debian and other distros being part of an "ecosystem of
software". I don't want to be part of an ecosystem; I'd rather be part of
something that works not something that muddles through via massive
trial-and-error and redundancy. Biomass is another word for "shit".
But I digress..
The most productive thing I've seen done to try to address this general
problem is the
Unmaintained
Free Software wiki, which tries to track this software and find new
maintainers. That has managed to match up some software with interested
people (though it failed with xgalaga), but I think it actually works less well for big and important software that ends up forked and maintained separately by the major linux distributions.
I, myself, am beginning to use the degree of divergence from upstream
as an indicator of how well a distribution maintains a given peice of
software, with more divergence == bad. A distro that's doing a good job
will a) get their patches integrated upstream and b) should work with other distros to find a new
developer if upstream goes missing or insane.This is the inverse of what people
might naively consider a good metric of how much work a distro is doing,
but I think it leads to better software in the long run.
PS: My limited interaction with Jeff when I used to maintain rpm for Debian was fairly problem-free.
PPS: I've written hundreds of spec files compeltly by hand, a dozen years ago. :-)
(
Log in to post comments)