LWN: Comments on "Who maintains RPM?"

Who maintains RPM?

johannbg — Thu, 01 Sep 2016 23:25:07 +0000

If a primary core/base component like RPM is not being updated due to a simple internal dispute between Red Hat and it's formal employee over it's originally owned product my oh my if that history repeats itself in Fedora and are people still wondering how Red Hat holds Fedora hostage after this spectacle? ( we are not talking about some random component but a core component in the distribution <sigh> )

I cant stop rofl and I cant believe I somehow missed this golden nugget from Red Hat all those years I spent crawling through bz.rh and I would love to hear the reason why Suse never updated it. Is it because they are just using rebuild components from Red Hat or was it something else and if so what exactly.

RPM is not the only one

Wol — Tue, 30 Aug 2016 17:16:38 +0000

> 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

Who maintains RPM?

Wol — Tue, 30 Aug 2016 17:07:27 +0000

> If Red Hat and SuSE could figure out a way to switch to deb and apt, and abandon RPM altogether, the linux world would be a better place.

And then we end up with the same nightmare that we had between Red Hat and SuSE. Where the RH/SuSE debs will have clashing names for different contents etc etc. And who gives way and changes packaging policy?

Can anyone name a apt/deb distro that is NOT a debian derivative? They've inherited the original packaging/naming policy, and can be declared out-of-line if they're different. When SuSE adopted rpm, they had an existing policy. If RH/SuSE adopt apt/deb, they will bring that same problem to the .deb world.

Cheers,
Wol

Who maintains RPM?

Wol — Tue, 30 Aug 2016 17:00:03 +0000

> Sounds like a job for Freedesktop.org to me.

> It's in the LSB so all distros have to support it, right?

Wrong. rpm the program is NOT in the lsb.

A subset of the rpm spec is in the lsb. Most importantly, if you use rpm features that are not supported by alien, then you cannot be lsb-compliant.

Declaration of interest - I was part of the lsb when all this was hashed out. I didn't particularly agree with what the lsb was doing back then, nor do I agree now, but I got involved to try and influence things. Unfortunately (from my pov) the juggernaut was not for turning ...

Cheers,
Wol

Upstart instead of launchd

ttfkam — Mon, 04 Sep 2006 17:28:23 +0000

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.

Who maintains RPM?

hazelsct — Mon, 04 Sep 2006 04:40:52 +0000

> Or even better, fix the package that contains a bogus dependency.

That's a lot easier done in Debian, where the project controls all 17,000 packages, then in Fedora, where unofficial repositories contain a large fraction of the packages in common use.

Who maintains RPM? A defense of Jeff Johnson

dag- — Sat, 02 Sep 2006 02:01:52 +0000

I agree with sarnold on this.

Jeff's sarcasm and sometimes rude comments seems to have grown over time and if a company is unable to correct this for a 2 years timespan the problem is related to lack of communication or lack of resolution inside the team/company and not entirely Jeff's responsibility.

I wouldn't be surprised if discontent, burn-out or lack of empowerment are the cause of abusive language and these are symptoms that are easy to detect and act upon. (People-skills!)

AFAICS Jeff is still maintaining RPM in good faith (despite recent public sarcasm towards Red Hat/Fedora). Red Hat however seems to favor to fork the project. This inability or unwillingness to reconciliate is an unfortunate escalation of something that is in essence fixable by good communication and mutual respect.

I hope a fork can be avoided by fixing what is broken. (and I'm not talking about RPM :-))

PS Backporting Jeff's work without credit for the work (Jeff already made statements about that on bugzilla) is not a good way forward. Ignoring him will also not fix the issues at heart.

PS2 Also the bugzilla entry is NOT about database corruption. You can have the same symptoms by just removing files on your disk. RPM will list them as *missing*, but of course the rpm database will still list them. That's 'work-as-designed'. You can argue if that is expected behaviour during installation, but this is not database corruption. If you take this in consideration, Jeff's comments make much more sense and less rude. KainX's comments clear this up, but the author fails to make this clear. The bug-report is basicly wrong. It does not condone the rude remarks in both directions.

Who maintains Debian?

gvy — Thu, 31 Aug 2006 21:31:55 +0000

> a robust constitution
I've heard differing opinions from Debian folks, regarding "robust".

> Anyone in the world can become a Debian Developer.
Especially if said anyone is to become the first DD in the country. Well here in Ukraine, they've trusted ALT Linux security officer who has signed my key before, and so I've signed the particular person on meeting him (it appeared we've graduated the same university, even). Wonder if this was not the case.

Just to put some sane facts over your mad science. :)

RPM is not the only one

vmole — Thu, 31 Aug 2006 19:50:30 +0000

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

kreutzm — Fri, 25 Aug 2006 19:22:41 +0000

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.

Shining more light on the problem

Tet — Fri, 25 Aug 2006 19:03:13 +0000

I would like to comment in defense of Jeff Johnson. I think he was unnecessarily vilified

As the original submitter of the bug mentioned, I feel I should comment here. I gave Jeff the benefit of the doubt for a long time, until he proved utterly unable to listen to reason. You can bleat "Show me the code" as much as you like (and I'd even agree with you -- were it more of a problem for me, I'd almost certainly have written a patch myself by now), but a maintainer of a package as significant as RPM simply has to listen to bug reports from users, and take some appropriate action. Denying that the bug even exists is simply not acceptable.

RPM is not the only one

nix — Fri, 25 Aug 2006 15:57:23 +0000

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

bojan — Thu, 24 Aug 2006 20:53:58 +0000

See if this helps:

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

Who maintains RPM? A defense of Jeff Johnson

sarnold — Thu, 24 Aug 2006 20:29:12 +0000

I've known Jeff for years; while I've had my fair share of arguments with RPM (and I've lost many :), I have always enjoyed discussing my problems with Jeff. He doesn't always like my proposed solutions to problems, but he has always been willing to talk about what problem I'm trying to solve so that he can help find a solution that works better for more people.

Mistakes were made in RPM's development, but blaming every deficiency of RPM on Jeff is also a mistake.

RPM is not the only one

vmole — Thu, 24 Aug 2006 19:22:33 +0000

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

vmole — Thu, 24 Aug 2006 19:15:25 +0000

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

Who maintains RPM?

madscientist — Thu, 24 Aug 2006 12:42:10 +0000

The whole LSB-uses-RPM thing is just a tempest in a teapot; even the Debian developers don't care about this. Why? Because an LSB-compliant package is so restrictive that it completely does not matter which package format it uses. The legal fields in an LSB RPM package are a strict subset of "full-blown" RPM. They can list dependencies ONLY on a very limited set of prerequisites: basically only on a package representing the LSB version (and maybe other 3rd party LSB packages; it's been a while since I read the spec). As already mentioned, the LSB does not require that the underlying distribution use RPM or any other particular package management tool: only that there be some application "rpm" which can install and uninstall packages that use this specific subset of RPM.

So yes, it may be slightly more work for non-RPM-based distributions to create a translator between RPM and their native package management, but it's certainly not difficult and, in fact, has already been done with alien.

So, it's just not worth arguing about this, or expending any effort to change it. IMO.

Who maintains RPM?

madscientist — Thu, 24 Aug 2006 12:35:32 +0000

Not only that, but Debian is 100% developed, directed, and controlled by volunteers. They have a robust constitution and regular public elections, open to all developers. Anyone in the world can become a Debian Developer. The distribution is completely free AND completely open. Red Hat and Fedora are absolutely inappropriate for serving as the basis for a major new Linux distribution such as Ubuntu.

RPM is not the only one

nowster — Thu, 24 Aug 2006 09:27:55 +0000

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.

Shining more light on the problem

hadess — Thu, 24 Aug 2006 08:33:16 +0000

[...] We were a paying customer and submitted a bug report. [...]

Bugzilla is not a support system. From the front page of the Red Hat Bugzilla:

Bugzilla is not an avenue for technical assistance or support, but simply a bug tracking system.

I think that makes it pretty clear.

Who maintains RPM?

seyman — Thu, 24 Aug 2006 08:24:23 +0000

Is there something technicallly advantageous in deb packages compared to rpm packages or other way around?

Joey has a very complete page on the differences between dpkg and rpm

Note that rpm now handles recommendations and suggestions but Fedora and Suse aren't picking up the upstream version that does this.

Who maintains RPM?

lamikr — Thu, 24 Aug 2006 07:50:15 +0000

Is there something technicallly advantageous in deb packages compared to rpm packages or other way around?

Like does either of these systems have superiour dependency handling tools for the package developers, or better syntax for handling those dependencies.

Or are these tools just offering about the same level of functionality while being incompatible with each others and requiring that the app packagers need to handle both of the syntaxes. In that case maybe it would go a good idea from fedora to jump also to jump to use debian packages by default. At least for the end users that could be a win in the long run.

Who maintains RPM?

robla — Thu, 24 Aug 2006 02:12:24 +0000

Ummm...please. Ubuntu is based on Debian because Mark Shuttleworth is a long time Debian guy, and he writes the checks. I'm sure at least some of the reason /why/ he's a long time Debian guy is because he felt as though Debian was a superior starting point, though I don't pretend to speak for him. Your assessment, however, is highly implausible.

Who maintains RPM?

dankamongmen — Thu, 24 Aug 2006 01:33:23 +0000

Thanks very much for an interesting and informative story on a topic I, as a Debian elitist, would otherwise have likely missed in toto. It's articles like this that keep me subscribing.

Who maintains RPM?

emkey — Wed, 23 Aug 2006 21:00:14 +0000

Well, we're up to update four? on RHEL 4 at this point so the more important question is who built it for the past couple of updates.

Who maintains RPM?

n3npq — Wed, 23 Aug 2006 19:44:35 +0000

Guess who built rpm for RHEL4?

RPM is not the only one

dberkholz — Wed, 23 Aug 2006 18:17:23 +0000

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

Who maintains RPM?

nevyn — Wed, 23 Aug 2006 17:46:26 +0000

This is a slightly ridiculous situation.

Not at all, if the software is open source debian can just package it themself. If it's closed then Red Hat and Novell still have almost all the market, and debian/ubuntu have alien support.

If Red Hat and SuSE could figure out a way to switch to deb and apt, and abandon RPM altogether, the linux world would be a better place.

Why would they screw their customers over like that, the deb format is not any better than the rpm format (has Suggests/Enhances doesn't have file deps). The dpkg tool is much worse than rpm, IMNSHO, and the higher level tools (yum, apt-get, smart, open-carpet, etc.) are all roughly equal technically. Also (from a long time Red Hat/Fedora users POV) the base system in debian is very different, and one of the main reasons I don't use ubuntu.

Ubuntu didn't base off of debian because it was technically better, they did it because it was bigger ... plus IMO because there were more unemployed people who know debian well than know Red Hat well, which you might take as a flame but I can't help that...

Who maintains RPM?

emkey — Wed, 23 Aug 2006 17:11:15 +0000

RedHat has been making some much needed improvements in the RHEL 4 version of rpm at least. A couple of years back Mr. Johnson apparently decided it was a good idea to remove all DB file locking from RPM rather then fix the limited locking that existed at the time. This was needless to say a rather bad idea and led to lots of accidental corruption. RedHat has fixed this issue. They've also been very responsive to other suggestions for fixes and changes. For instance until recently there was no equivalent for --ignoresize when trying to remove rpm's. Why did this matter? Because until recently rpm insisted on stat'ing every single mounted filesystem any time it did an add or remove. It is not out of the ordinary to have one or more remote filesystems in a less then happy state if you're environment is large and complex. Having your rpm remove hang for long periods of time was very frustrating.

In summary, RedHat has been doing a much better job recently on the RPM front. Now they need to formalize things and take back control. Based on past experience I wouldn't touch anything Mr. Johnson worked on with a fifty foot pole.

Shining more light on the problem

anonymous21 — Wed, 23 Aug 2006 17:04:03 +0000

Let's correct that:

... the rpm database could be repaired (sometimes) by using the rebuild option...

RPM was always a fearful tool for me.

Although it has probably vastly improved since then. (redhat 6,7,8)

Mark

Shining more light on the problem

dowdle — Wed, 23 Aug 2006 16:22:52 +0000

That was a bug from long ago... and the rpm database could be repaired by using the rebuild flag. They fixed that the bug.

I'd rather not see this discussion digress into an rpm vs. dpkg thing.

Shining more light on the problem

dowdle — Wed, 23 Aug 2006 16:19:33 +0000

I'm confused. There needs to be some sort of timeline here.

RPM reporting on Red Hat's bugzilla was part of the confusion... as the open project was using the commercial vendor's bugzilla for bug tracking. Were bugs reported for the open project or for the vendor? Bugzilla *IS NOT* the Red Hat Support system and anyone using it for that is spinning their wheels.

When was Jeff Johnson working as a Red Hat employee and when was he NOT? Were his responses in bugzilla an official part of his Red Hat job or part of the open project?

See, lots of room for confusion.

Who maintains RPM?

stock — Wed, 23 Aug 2006 15:22:29 +0000

i would say that mandrake/mandriva did a tremendous job of their own.
Their (S)RPM system never gave me problems with them. everything works
like expected and reported. Here's the Mandriva wiki's on RPM :

Mandriva RPM HOWTO
http://qa.mandriva.com/twiki/bin/view/Main/RpmHowTo

URPMI resources page
http://qa.mandriva.com/twiki/bin/view/Main/UrpmiResources

Who maintains RPM?

n3npq — Wed, 23 Aug 2006 11:44:22 +0000

Not true.

The mechanism for soft dependencies in rpm sets a RPMSENSE_MISSINGOK bit which has
pre-defined semantics that the dependency is provided to depsolvers who are free
to do whatever they wish with the dependency including ignoring the dependency
entirely as rpmlib does.

So ignore
Enhances: glibc
in yum if you wish.

Or even better, fix the package that contains a bogus dependency.

Who maintains RPM?

drag — Wed, 23 Aug 2006 11:39:49 +0000

Well Debian does support installing RPM packages, though, through the alien stuff.

As you see in the wajig list-command output it has a couple (somewhat redundant) commands for handling rpm format.

So I figure that Debian-based systems should support it also, even if it's not in a official capacity.

For ISVs then it would make sense to target RPM for packages. Debian supports it, Debian-based systems should support it, but Redhat and such don't support Deb packages.

What is left is just making it sane to use in non-native-rpm systems for the average end user.. if a thing is ever possible. (which I have no idea about)

RPM is not the only one

rahulsundaram — Wed, 23 Aug 2006 11:36:12 +0000

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

job — Wed, 23 Aug 2006 10:44:23 +0000

I like fcron.

I've heard others praise dcron, too.

RPM is not the only one

kleptog — Wed, 23 Aug 2006 09:59:23 +0000

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

Shining more light on the problem

kleptog — Wed, 23 Aug 2006 09:55:56 +0000

Ouch! If I got a corrupt database everytime I hit Ctrl-C while running dpkg, I'd be pretty pissed.

Dpkg may not be perfect, but it's never ever corrupted it's database on me, and I've beaten it pretty badly over the years.

RPM is not the only one

Frej — Wed, 23 Aug 2006 09:40:06 +0000

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.