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

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
   fuss?

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
latest version?

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.

IANARHE

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 
at:

https://www.redhat.com/archives/fedora-advisory-board/

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:

https://www.redhat.com/archives/fedora-advisory-board/2006-July/msg00019.html

[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
the time.

*** 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
regarding RPM:

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

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

UPSTREAM

A resolution has been decided:

https://www.redhat.com/archives/fedora-announce-list/2006-December/msg00003.html

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:

http://rpm.org/

Thanks, everyone, for your input.