Red Hat Bugzilla – Bug 174307
Newer upstream RPM is available
Last modified: 2013-01-13 07:32:12 EST
Description of problem:
RPM 4.4.3 is available but Rawhide wasn't updated, yet. I would like to see
this, because 4.4.3 contains new features as well as bugfixes. Upgrade shouldn't
hurt anybody, or does it? ;-)
Upgrade to rpm 4.4.3 would solve at least the following Red Hat Bugzilla IDs:
#101717, #113340, #114338, #116709, #117382, #120635, #125517, #134388, #140050,
#140597, #146842, #147196, #155256, #159221, #159235, #164953, #165434, #172878
RPM 4.4.3 also provides perl-RPM2 (as rpm-perl-4.4.x) now.
Version-Release number of selected component (if applicable):
Upgrade to 4.4.3 ;-)
Paul why are you backporting the stuff and fixes into rpm 4.4.2-10 instead of
upgrading to rpm 4.4.3?
Ping...what's up? RPM 4.4.4 is already available...
I know, that there were (are?) miscellaneous (internal?) discussions and plans
round about rpm and it's future - but wasn't a main goal of Fedora Core to be
always very close to upstream?! ;-)
My expected result is anyway an upgrade to latest (currently 4.4.4) rpm version.
NEEDINFO_ENG waiting for an answer.
Paul and Mike: WHY EXACTLY wasn't and isn't Fedora Core updated to rpm > 4.4.2?
The onliest excuse for the moment is the stabilisation of FC5 (which is really
the worst alibi I could think of), but will there be definitely an update to the
latest rpm release after FC5 is ready - yes or no...please!
And if "no", could you please explain me detailed (!) the real reason for this
decision? And FAIK, Fedora Core is a community-based distribution... ;-)
*** Bug 187887 has been marked as a duplicate of this bug. ***
Updating for 4.4.6 until 4.4.7 is already there and nothing happend *yawns*
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing
status to ASSIGNED for ENG review.
Fedora Core 6 really should match with the latest upstream RPM release. There
are many new useful features and enhancements, for example checking whether the
parent directory is packaged. At this point, Fedora Core is really a mess and
RPM %changelogs are internally converted to UTF-8 and can be trunicated to e.g.
a year ago while building the rpm which reduces rpm header size.
Another thing is, that libtool, pkgconfig, java and scriptlet requirements (and
also providings) can be automatically extracted.
RPM also carries a run-time probe dependency like
Requires: getconf(GNU_LIBPTHREAD_VERSION) = NPTL
so that can be expressed that Berkeley DB within rpm requires (!) a functional
+NPTL system, no ifs, no ands, no buts (adapted from a jbj announcement).
Nevertheless, there should be more communication between Red Hat and upstream
concerning the SELinux support in rpm (see bug #182998). Dlopen()ed stuff could
be a well solution for this making everybody happy?
RPM is since 4.4.5 also able to handle files up to 4 GB in packages and later
on, rollback support got also in. But hey, I don't want to copy the whole rpm
changelog here into.
An upgrade definitely should be an effort for both - users and developers... ;-)
Hm. Not very polite of the maintainer to not respond.
Jonathan, I completely agree with you. Some days ago, I started in #fedora-devel
something like a discussion (some would call it flamewar). The result of it is,
that "we as in the part of Red Hat that is focused on new technology" [...] "may
_not_ update to upstream RPM. They're doing some really cracked out things that
we're not comfortable consuming" (jkeating).
Current end of the story is, that the RPM tags enhances, suggests etc. seem to
be the only real problem. But "thats the only one that has come to my attention.
Granted, it is a pretty big one. Also, I haven't even LOOKED at it, thats jsut
the one that was brought to my attention" (jkeating).
And as far as I got the information, "--disable-crap" has to be implemented by
upstream and nobody at Red Hat seems to be willing to hack out what is unwanted
at downstream (because users could complain, Red Hat RPM is missing something
upstream RPM has). But "hack in"s (oppositte of "hack out") at downstram seem to
be toleranted and accepted when looking to bug #182998 for example. Are "hack
outs" and "hack ins" not on the same downstream level? Crazy world...
At least, I'll keep open and update this bug report until the hell freezes or
Red Hat updates Fedora Core to latest RPM upstream - even if we get something
similar like in bug #119185 ;-)
Any or all of the following things should concern you greatly:
- The people deciding not to upgrade RPM have not even looked at the
upstream version or its features.
- jkeating is not even an RPM developer. He is a packager.
- The Enhances/Suggests/etc. tags are not required; they are entirely
optional and need not be used in any packages if they are not desired. Not
using upstream RPM because of their presence is no less silly than not using
RPM at all because it doesn't remove *.la files, or not using the Linux
kernel because it can load non-GPL modules. This is probably a smokescreen
hiding the true *political* reasons they have for not using upstream RPM.
- Fedora packagers have made numerous and rampant policy decisions regarding
"proper" packaging. The aforementioned tags are completely unused by RPM
itself, so omitting them would simply be a policy decision. So why all the
Makes you wonder, doesn't it?
OK, then I'll just ask : Paul, what are the reasons for sticking with an old
version of rpm with currently 27 patches applied, instead of updating to the
I for instance would really like to see the automatic dependency generation
through pkgconfig files in Fedora, that's really neat and could simplify
packaging in the same way automatic dependency generation of shared libraries did!
I'm tired enough of my work being backported without even attribution
that I'm gonna slam this bug WONTFIX.
I'm seriously contemplating licensing my rpm development to ensure
that FC will never ever be able to upgrade rpm.
Go honk yer vendors fer fixes.
Reopening, because this is a Fedora bug report, not RPM upstream related. And I
definitely want to have a response by Red Hat, because Red Hat folks currently
refuses this upgrade even when Fedora is a community driven distribution (and
something like that is published everywhere). Not for nothing I marked this bug
report as FC6Blocker...
Oops...moved FC6Blocker from depends to block section to satisfy the dependency
- thank you very much Chris :)
(In reply to comment #15)
> Fedora is a community driven distribution
You don't actually believe that, do you?
Haha, can you give me any example to believe the public announcements? Core CVS
is currently completely managed by Red Hat and all bigger decisions which belong
to Core, too. Community is active in the "unimportant" parts, like e.g. Extras,
Testing, Websites, etc. And IMHO this bug report proofes my point of view.
Nevertheless this bug report is the right point to discuss this and my point of
view about the whole stuff. Only my personal opinion.
Finally said, the common used pleaded alibi of "no time to look into" isn't
simply accepted by me. If you're *really* interested in something, you can find
the time to look into it within your 8+ working hours a day. And wasn't Rawhide
a place to break things, too?
Upgrading from 4.4.2 to 4.4.5 was realized on my system by spending about an
hour (except the Fedora RPM patch misery). Upgrading from 4.4.5 to 4.4.7-devel
took another hour including some hacks to disable personally unwanted new but
nice features - otherwise I had to fix the Fedora Core package misery ("orphan
directories" and "dangling symlinks").
Expecting upgrade of RPM to latest stable upstream version for Fedora Core 6 and
response by Red Hat folks, anyway.
The backported fixes have been used to maintain the version currently in
Fedora while policy decisions are in the works for using some of the new
features. Rather than dump in a new version that features some significant
changes and letting the mayhem ensue, we want solid policies in place before
introducing the changes to the Fedora pool.
This issue is now under active discussion within the Fedora Advisory Board.
Due to the significant nature of the changes, it is improbable that the new
release will be added to Fedora Core 5 or introduced with the release of
Fedora Core 6, though later inclusion cannot be completely ruled out at this
time. We should have decisions made within FAB, FESCo and the Packaging
Committee in the near future. Your patience is appreciated.
It is also worth noting that this issue is being discussed within the
community, and that Red Hat has not been solely responsible for the hold out.
Please refrain from using this bug report as a venue for bad-mouthing the
Fedora Project or Red Hat, especially without being completely informed.
I think the route of the frustration here lies in the lack of technical
discussion on the matter. There are various bugs that in principle are solved by
upgrading to the latest version of RPM, but perhaps the solutions offered in the
upgrade are not viewed as the right technical solution. However, the point is
that there hasn't been any detailed open discussions of the technical reasons
for not upgrading, and I think this is the route of the frustration felt by
people who have commented on this bug report.
Could I make a suggestion that someone with the technical expertise required
make a wiki page describing the technical pros and cons of upgrading to the
upstream version of rpm. Regarding Comment #19, Patrick is right about bad
mouthing red hat/fedora being the wrong thing to do. However, simply saying
"this is up to FAB, it doesn't concern you" isn't an acceptable approach either.
This is supposed to be a community led distribution (yes, I still believe that),
and debate over issues such as this should be publically visible. To do
otherwise is to show contempt for the community of people who are working hard
to make Fedora better (looking at the CC list of this bug I see a number of
Fedora Extras contributors, for example).
I don't regard myself as having the technical knowledge regarding the internals
of rpm to write down a list of reasons for and against following upstream.
Hopefully someone reading this is.
The Fedora Advisory Board is a community group and is different from the
Fedora Project Board. The Fedora Advisory Board consists of many of the
Fedora Project's top contributors. The mailing list archives are open, and
anyone is welcome to send a message to the list. The archives are available
I think establishing a wiki page is a good idea. If someone doesn't beat me
to it, I'll get it started as soon as I have the time, and I'll ask the
assorted committees to use it as a central point for discussion.
Thanks, Jonathan - added http://www.fedoraproject.org/wiki/rpm-devel right
away after reading your comment. Just has to be updated by the guys providing
the contra...sorry, I've got only pro ;-)
Patrick, guess I can give back the lack of information to you - but regarding
to RPM - now looks like we're in the same boat because "that features some
significant changes and letting the mayhem ensue" sounds IMHO very similar like
me about Fedora in comment #18 *smile*
Waiting for useful and technical related discussion e.g. in the Wiki from guys
used latest RPM or even know more than just vague thinks and never tried it out
(I'm absolutely sorry, but that's my impresson when reading some replies at the
list). The page is simply a draft and was created within a few minutes. So just
feel free to improve and enhance it.
Patrick - thanks for the clarification regarding the FAB. For other readers, a
relevant FAB discussion is:
[This is also linked to at the bottom of Robert's wiki page.]
Robert - good work, this will help a lot I think, thanks very much for taking
*** Bug 200115 has been marked as a duplicate of this bug. ***
Okay folks, board meeting happend in July, but there wasn't IMHO a real result
when reading: http://www.fedoraproject.org/wiki/Board/Meetings/2006-07-18
Today I read http://interviews.slashdot.org/interviews/06/08/17/177220.shtml:
"First, we believe very strongly in working with various upstreams. The diff
between any package that we ship in Fedora and the upstream version is as small
as possible at any given time, and we are constantly submitting our patches and
changes upstream for consideration." (Max Spevack). But did he ever look into
the RPM package? Personally, I would say no, otherwise he maybe wouldn't have
said this, wouldn't he? ;-)
What's the real status about RPM from wraptastic.org for Fedora Core 7? There are
several postings on the mailing lists but they sound to me like drinking coffee,
talking about the weather and how good the cookies taste - sorry, but looks like
nobody is interested in working, because just talking about is much more easier.
Regarding Comment #25:
I notice reading the fedora project board meeting that there was an action item
Need technical leadership around this. SethVidal is recommending
PaulNasrat as a possible leader. Will speak to him and report back.
I would like to see whoever becomes technical leader be significantly more
communicative with the community than PaulNasrat is currently.
Did anyone ever considered to talk with Jeff face-to-face to talk about the
past, the present and the future, instead of ignoring him and RPM stubornly ?
For some reason it feels like Red Hat and/or Fedora consider the mere mention of
reconciliation treason. It's obvious that, for many months, if not years,
relations have grown tense and insustainable and Jeff's sarcasm seems more like
a result than a cause of this. It all seems like a bad episode of ill-communication.
But the mere fact that Jeff is still maintaining RPM and fixing a piece of
software, to me, is a clear sign that he still cares. And I doubt this cannot be
fixed by putting everything on the table and discuss openly.
Forking seems like one of the worst solutions IMO.
+1 and s/IMHO// match just with my 2 Ct - hopefully Fedora accepts PayPal ;-)
As far as I know and got told, Red Hat, Inc. is already trying to enforce its
rights for RPM (especially for the name), headed by known leading Fedora Core
developers employed at Red Hat, Inc.
Why not removing RPM completely from Fedora and using only a standalone yum
having rpmlibs competely written in Python included (that kind of yum should
get the ability to build *.rpm files then, of course) to have only one huge
ressource-wasting Python script and making most parts of the Fedora and/or Red
Hat engineering including Seth very happy? The advantage is, that yum is already
developed and only the rpmlibs would have been rewritten in Python (maybe the
also existing Red Hat pyrpm could be used and merged in). </sarcasm></irony>
Ha and just said when this or a similar day comes, I'll surely leave the whole
Fedora Project to support maybe OpenSuSE, Mandriva, Debian or even Gentoo... :)
They day RedHat seriously tries to use naming and trademark issues to force all
versions of RPM that they don't distribute to be called something else is the
day RedHat looses tons of my goodwill. I've already been considering OpenSuSE
because I like reiserfs, and that would likely be the last straw.
RPM has been around since the early 90's, I believe. Suddenly deciding in late
2006 to enforce a trademark after 10+ years of general use is legally dubious at
Of course, this would not be the first attempt by RedHat to use their lawyers to
bully a community project....
Interetingly, openSUSE stopped at (heavily patched) 4.4.2 as well. I am
wondering what are their reasons.
However, Mandriva 2007 contains 4.4.6 (I think), and 4.4.7 is planned to be
Anyone checked other distributions?
Well, SuSE is IMHO a distribution always behind regarding RPM. They stood at
rpm 3.0.x for years when 4.0.x or even 4.1.x was available, didn't they?
Ah...latest and best bits of RPM were bundled as new release called 4.4.7 :)
Now we've got 6-9 months for upgrading RPM until Fedora Core 7 is shipped. This
looks just perfect to me, to heat up the discussion again and to bother people
like Jesse or Seth as they're IMHO the hugest antagonists...
I would love to see the new rpm in fc7 as well...
Segafualts and loss of data are likely due to removing an rpmdb environment
without correcting other problems in the rpmdb.
FYI: Most rpmdb "hangs" are now definitely fixed by purging stale read locks when opening
a database environment in rpm-4.4.8-0.4. There's more to do, but I'm quite sure that a
large class of problems with symptoms of "hang" are now corrected.
Detecting damage by verifying when needed is also in rpm-4.4.8-0.4. Automatically
correcting all possible damage is going to take more work, but a large class of problems is likely
already fixed in rpm-4.4.8-0.4 as well.
A resolution has been decided:
Obviously, there's a lot of work to do, but this bug report is no longer
relevant. I'm closing this as WONTFIX. Anyone with a real interest in the
future of RPM should visit the new upstream:
Thanks, everyone, for your input.