Who maintains RPM? [LWN.net]

Who maintains RPM?

Posted Aug 22, 2006 22:55 UTC (Tue) by smoogen (subscriber, #97)
Parent article: Who maintains RPM?

Jon,

A very important correction to your article please.

> For the purposes of the people using distributions from Red Hat and SUSE,
> RPM is essentially unmaintained.

This is untrue for Red Hat (and probably SuSE.) For Red Hat, Paul Nasrat has been doing lots of work with RPM in the last year or so for Red Hat Enterprise and the porting/creation of patches to RPM in Fedora.

The reason for not upgrading in RPM for Red Hat Enterprise is pretty clear that the ABI/API for RHEL-3/4 {and SuSE 9) should be set in stone so that people can write RPMs and not have to redo syntax, logic in triggers and such.

The reason that it hasnt been upgraded in Fedora seems to have been that some of the changes in syntax, options in the 4.4.5 RPM has things that yum, mock, and apt would choke on for things like "alternatives" and other items. [I do not state this as fact however... but on hearsay from the yum original author.]

to post comments

Who maintains RPM?

Posted Aug 23, 2006 1:59 UTC (Wed) by louie (guest, #3285) [Link] (1 responses)

SuSE also does (or at least did when I left there) fairly active development on their branch of RPM. So "Red Hat and SUSE's RPM development trees are internal, not public, and not coordinated centrally", or "no one uses jbj's branch of RPM", would both be accurate, but "RPM is unmaintained" is not accurate, as far as I can tell.

Who maintains RPM?

Posted Aug 23, 2006 2:57 UTC (Wed) by skvidal (guest, #3094) [Link]

Suse's branch is pretty close in terms of what they support to fedora rpm.

In short, we're all watching each other trying to figure out where to go next.

I believe that's referred to as some kind of standoff.

-sv

Who maintains RPM?

Posted Aug 23, 2006 3:02 UTC (Wed) by skvidal (guest, #3094) [Link] (2 responses)

the problem with the soft dependencies is that we've got no defined semantic for handling them automatically. Additionally, we have no policy to keep someone from doing:

Enhances: glibc

and having their package pulled in EVERY time.

This, among other reasons, is why we wanted to stage in things like Suggests/Enhances - the soft deps.

We wanted to be able to know when those things would go in. And since they would have fairly far-reaching impact gracefully add them - probably as a major point release or at the very least not a minor.minor release.

I think it would be radical and exciting if rpm had:
1. a roadmap
2. a development cycle based on time or at least based on feature
3. some concept that some features break things or cause other havoc so they need to cycle them through in something other than point release.

-sv

Who maintains RPM?

Posted Aug 23, 2006 11:44 UTC (Wed) by n3npq (guest, #40075) [Link] (1 responses)

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?

Posted Sep 4, 2006 4:40 UTC (Mon) by hazelsct (guest, #3659) [Link]

> 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.