RPM is not the only one [LWN.net]

RPM is not the only one

Posted Aug 23, 2006 7:40 UTC (Wed) by joey (guest, #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. :-)

to post comments

RPM is not the only one

Posted Aug 23, 2006 7:59 UTC (Wed) by nowster (subscriber, #67) [Link] (3 responses)

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.

There are great problems with communicating with RedHat. Nowadays, there appears to be no named maintainer for many important packages, and using the bugzilla isn't always appropriate, especially with security-related problems.

As one distro's maintainer of several packages based on RedHat/Fedora upstream sources, this is incredibly frustrating. Finding new upstream versions is often a matter of stumbling across them by accident, rather than having a stable location to find them. I used to have read-only CVS pull access to one upstream source but that disappeared without notice one day, and I got bounces from the email address of the person I'd originally been in contact with about it.

Like joey, I get people sending me patches in frustration.

RPM is not the only one

Posted Aug 23, 2006 11:36 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

You are right about bugzilla not being the right place to handle security issues in many cases. The recommended procedure for Fedora and RHEL respectively are

http://fedoraproject.org/wiki/Security
http://www.redhat.com/security/team/contact/

cvs versions of all of Fedora is available at

http://cvs.fedoraproject.org/

If you have any other issues, feel free to mail me @fedoraproject.org

RPM is not the only one

Posted Aug 24, 2006 9:27 UTC (Thu) by nowster (subscriber, #67) [Link] (1 responses)

cvs versions of all of Fedora is available at...

Browsing the CVS, no source code is visible at any level, only the occasional Makefile or patch file. I'd email you directly about this, but you didn't give your full email address.

RPM is not the only one

Posted Aug 24, 2006 20:53 UTC (Thu) by bojan (subscriber, #14302) [Link]

See if this helps:

http://fedoraproject.org/wiki/Extras/UsingCvsFaq

RPM is not the only one

Posted Aug 23, 2006 8:24 UTC (Wed) by rsidd (subscriber, #2582) [Link] (11 responses)

Xgalaga doesn't matter -- if there are no maintainers, let it die. Cron, makedev, etc should be part of the "base system" of any Unix-like OS, and if there is no reliable upstream version, well, you need to maintain it yourself... If Debian's version, or Red Hat's version, earns respect in being well-maintained, others can use it and it may become the "canonical" version.

The BSDs do this right, by keeping all essential Unix programs in their base system and taking full responsibility for them. And all the BSDs are much smaller projects than Debian; none of them (except Apple) are corporate entities like Red Hat. If they can do it, Linux distros can too.

You may argue that this means a "fork", as FreeBSD's cron differs from NetBSD's and so on. But in cases where there is no upstream maintainer, this is unavoidable. Where an upstream maintainer does exist (gcc, binutils, openssh) the BSDs resynchronise with the upstream source periodically, and, of course, feed their own bugfixes upstream.

RPM is not the only one

Posted Aug 23, 2006 9:05 UTC (Wed) by MathFox (guest, #6104) [Link]

I agree with what you say; a distributor has to ensure that essential packages are sufficiently maintained. This may mean that she has to bite the bullet and write her own security patches.
There are some problems with distributor maintained packages. There's the "duplication of effort" issue where each distributor writes her own patches. The "selection of the fittest patch" has halted. The base versions are different, patches can not be easily ported, patches are not communicated and the "Beneficial Dictator" has left his post. The program as such will wither without central maintainer, but it is certainly thinkable that one of the distributor's forks will become the leading variant.

Should we cry about this situation? No, it's evolution in action and as long as the sources are available there is room for someone to pick up. We should get worried when community distributions like Debian and Gentoo start withering.

RPM is not the only one

Posted Aug 23, 2006 9:40 UTC (Wed) by Frej (guest, #4165) [Link] (8 responses)

Offtopic....
Well cron sucks, it does not expect your computer to be turned off.
It did make sense then, now it doens't.
Apple fixed the mess with launchd, and now the source is there with a apache 2.0 license.

RPM is not the only one

Posted Aug 23, 2006 9:59 UTC (Wed) by kleptog (subscriber, #1183) [Link] (1 responses)

And so the world created anacron, and all was well again :)

RPM is not the only one

Posted Aug 24, 2006 19:15 UTC (Thu) by vmole (guest, #111) [Link]

Unless, of course, you want support for individual crontabs.

RPM is not the only one

Posted Aug 23, 2006 10:44 UTC (Wed) by job (guest, #670) [Link] (4 responses)

I like fcron.

I've heard others praise dcron, too.

RPM is not the only one

Posted Aug 24, 2006 19:22 UTC (Thu) by vmole (guest, #111) [Link] (3 responses)

Unfortunately, neither is a drop-in replacement for Vixie cron. There's just too much history behind vixie cron to replace it with anything that doesn't support all the weird variations of crontab syntax. (Obviously, I'm talking about the general case, done on a distribution level. Individual sysadmins can do what they want, and that's fine.)

What should really happen is to develop a cron-like system with equivalent capabilities but a sane syntax, the ability to control things like "what happens when a jobbed is skipped" or "what if the previous invocation is still running", etc. etc. etc. Instead of reading crontabs, write a converter . It can fail on the corner cases so long as it tells you it's done so.

RPM is not the only one

Posted Aug 25, 2006 15:57 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

Many of those weird variations are hardly ever used. @reboot (I think it is) was broken in Debian cron for *years* before anyone reported it...

RPM is not the only one

Posted Aug 31, 2006 19:50 UTC (Thu) by vmole (guest, #111) [Link]

But the screaming that occurred when somebody noticed! It was suddenly ABSOLUTELY VITAL and we COULD NOT LIVE WITHOUT IT!!!

But I'm not bitter.

Steve, former Debian cron maintainer.

RPM is not the only one

Posted Aug 30, 2016 17:16 UTC (Tue) by Wol (subscriber, #4433) [Link]

> What should really happen is to develop a cron-like system with equivalent capabilities but a sane syntax, the ability to control things like "what happens when a jobbed is skipped" or "what if the previous invocation is still running", etc. etc. etc. Instead of reading crontabs, write a converter . It can fail on the corner cases so long as it tells you it's done so.

Is that called systemd?

(lighting blue touch paper and retiring at full speed to a safe distance ... :-)

Cheers,
Wol

Upstart instead of launchd

Posted Sep 4, 2006 17:28 UTC (Mon) by ttfkam (guest, #29791) [Link]

While in general I very much like the direction Apple has taken with its operating system, and while I think that launchd is a tremendous improvement over initd, I think Upstart is a better solution to the problem -- especially for Linux systems.

Bear in mind that I own or have owned a G3 iBook, a G4 Powerbook, and an Intel-based MacBook Pro, so I'm by no means biased against Apple products.

However, this description page for Upstart accurately reflects why I think it's better than launchd (or initd-ng for that matter).

Event-driven instead of polling loops, dynamically discoverable dependencies instead of explicitly specified dependencies, compatible and resiliant with a wider variety of hardware and software configurations, and more.

I realize that launchd is getting all the press, but that doesn't automatically make it the best choice. For OS X, where the hardware and software are almost completely controlled by a single source, launchd makes sense -- and once again, is a tremendous improvement over initd. For Linux, I think Upstart best fits the bill.

RPM is not the only one

Posted Aug 25, 2006 19:22 UTC (Fri) by kreutzm (guest, #4700) [Link]

Well, I don't know about NetBSD and FreeBSD, but OpenBSD is *proud* not to feed their bugfixes upstream, instead claiming: "We fixed this a long time ago" when someone else fixes it upstream.

RPM is not the only one

Posted Aug 23, 2006 18:17 UTC (Wed) by dberkholz (guest, #23346) [Link]

What about ftp://ftp.isc.org/isc/cron/ ? I see a 4.1 there that's released in 2004.