Bug 143301 - Removing "Epoch: 0" breaks rpm -F
Removing "Epoch: 0" breaks rpm -F
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-18 08:45 EST by Ville Skyttä
Modified: 2013-01-09 22:37 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-26 03:52:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Old version: foo 0:1-1 (239 bytes, text/plain)
2004-12-18 08:47 EST, Ville Skyttä
no flags Details
New version: foo (none):2-1 (221 bytes, text/plain)
2004-12-18 08:48 EST, Ville Skyttä
no flags Details
Fix bug in freshen case where original package had Epoch: 0 (394 bytes, patch)
2005-02-26 20:23 EST, Tom "spot" Callaway
no flags Details | Diff
Another approach (1003 bytes, patch)
2005-02-27 05:27 EST, Ville Skyttä
no flags Details | Diff
Missing epoch is the same as Epoch: 0. (1.13 KB, patch)
2006-08-05 05:15 EDT, Jeff Johnson
no flags Details | Diff

  None (edit)
Description Ville Skyttä 2004-12-18 08:45:47 EST
Updating a package's EVR from eg. 0:1-1 to (none):2-1 breaks "rpm -F", it won't
freshen to the newer version (without "Epoch: 0"), it does nothing and doesn't
output anything.  rpm -U works as expected.  rpm -F also works as expected if
"Epoch: 0" is not dropped, ie in 0:1-1 to 0:2-1.

This is rpm-4.3.2-21 on FC3.  Will attach two sample reproducer specfiles.
Comment 1 Ville Skyttä 2004-12-18 08:47:42 EST
Created attachment 108845 [details]
Old version: foo 0:1-1
Comment 2 Ville Skyttä 2004-12-18 08:48:31 EST
Created attachment 108846 [details]
New version: foo (none):2-1
Comment 3 Tom "spot" Callaway 2005-02-26 20:21:42 EST
This is simple enough to fix. Patch attached.
Comment 4 Tom "spot" Callaway 2005-02-26 20:23:15 EST
Created attachment 111458 [details]
Fix bug in freshen case where original package had Epoch: 0
Comment 5 Ville Skyttä 2005-02-27 05:27:47 EST
Created attachment 111460 [details]
Another approach

I'm not sure that is the correct fix.

If I read correctly, it's now skipping version (and release) comparison
altogether if the first package has epoch:0 and the second does not have epoch
at all.

Also, the "else if" branch below the patch should probably be taken care of
too.  Version comparison cannot be stopped if the first packages doesn't have
an epoch, but the second does (as the 2nd may be 0).

How about something like this?	Untested, and comes from a non-C-coder, so
it'll need a review.
Comment 6 Tom "spot" Callaway 2005-02-27 12:48:41 EST
You're not reading it correctly. It's still doing version and release
comparison. (Your patch is wrong, causes lovely segfaults and db corruption).

The only weird case would be where one epoch is 0, and the other is null. This
is the "unstated equal" case in the rpmVersionCompare function.

So, lets see what happens if we use your example specs and make two packages
where the %{name}-%{version}-%{release} are identical, and the only difference
is that one package has Epoch: 0, and the other has no Epoch.

[root@localhost rpm-4.4.1]# rpm -qp --qf "%{epoch}\n" foo-1-1.epoch0.i386.rpm
foo-1-1.noepoch.i386.rpm
0
(none)

If no release-version checking is occuring, then it should always succeed.
So, lets test it (./rpm has my patch installed).
First, we install the package with no epoch:

[root@localhost rpm-4.4.1]# ./rpm -ivh foo-1-1.noepoch.i386.rpm
Preparing...                ########################################### [100%]
   1:foo                    ########################################### [100%]

Next, we freshen to the package with Epoch: 0

[root@localhost rpm-4.4.1]# ./rpm -Fvh foo-1-1.epoch0.i386.rpm
Preparing...                ########################################### [100%]
        package foo-1-1 is already installed

Just to confirm, lets do the opposite. 

First, we install the package with an Epoch: 0:

[root@localhost rpm-4.4.1]# ./rpm -ivh foo-1-1.epoch0.i386.rpm
Preparing...                ########################################### [100%]
   1:foo                    ########################################### [100%]

Next, we try to freshen to the package without an Epoch:

[root@localhost rpm-4.4.1]# ./rpm -Fvh foo-1-1.noepoch.i386.rpm
Preparing...                ########################################### [100%]
        package foo-1-1 is already installed

And just to show that version and release comparison are still happening,
let's make two more packages: foo-2-2 (with epoch:0), and foo-2-2 (without epoch:0)

[root@localhost rpm-4.4.1]# rpm -qp --qf "%{epoch}\n" foo-2-2.noepoch.i386.rpm
(none)

First, lets start with foo-1-1.epoch0:

[root@localhost rpm-4.4.1]# ./rpm -ivh foo-1-1.epoch0.i386.rpm
Preparing...                ########################################### [100%]
   1:foo                    ########################################### [100%]

Then, lets try to freshen to foo-2-2.noepoch (this is the (epochOne != NULL &&
epochTwo == NULL) case):

[root@localhost rpm-4.4.1]# ./rpm -Fvh foo-2-2.noepoch.i386.rpm
Preparing...                ########################################### [100%]
   1:foo                    ########################################### [100%]

Works as expected.
Comment 7 Ville Skyttä 2005-02-27 13:51:26 EST
Fair enough, that seems to work.

Anyway, I'm apparently having trouble understanding either the expected return
values from rpmVersionCompare() (I guess -1 if second is newer, 1 if first is
newer, 0 otherwise), or how it manages to return them.  If it works, I don't mind :)
Comment 9 Matthew Miller 2006-07-10 18:35:41 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 10 Matthias Saou 2006-07-11 03:53:57 EDT
FWIW, you haven't actually closed the bug... and I doubt you meant to leave it
in limbo like this...
Comment 11 Matthew Miller 2006-07-11 11:58:50 EDT
*My* intention is to put bugs into limbo, yes. Or rather, to correctly label
bugs which are in limbo as such, so that someone will hopefully save them.

But looks like pnasrat moved this to devel but forgot to unlimbo it.
Comment 12 Matthias Saou 2006-07-11 12:03:22 EDT
Well, I'm not sure keeping old bugs for unsupported releases of Fedora Core is
useful. You wrote yourself "if... please reopen", which implied that this bug
would be closed.

I think it's best to close these old bugs, and let CC'ed people re-open them
against a newer FC release if they're still relevant (like this one).
Comment 13 Matthew Miller 2006-07-11 12:27:06 EDT
This was discussed last year (or so; whenever I did the FC2 bugs) on
fedora-maintainers, and the result was that most people were happiest with
putting the bugs to NEEDINFO and not actually closing them if no info is
provided. My original intention had been to go through a second time and close
NEEDINFO bugs, but some people prefered I not do that.

Let's take further discussion to the mailing list -- fedora-legacy if you're not
on fedora-maintainers?
Comment 14 Jeff Johnson 2006-08-05 05:15:26 EDT
Created attachment 133675 [details]
Missing epoch is the same as Epoch: 0.

The patch in #4, and the analysis in #5, are total crack.

The current rule for comparing epoch in rpm is
    Missing epoch is exactly the same as Epoch: 0.

Added to rpm cvs, will be in rpm-4.4.7 when released.
Comment 15 Jeff Johnson 2006-08-05 05:24:20 EDT
Sorry, Ville. The analysis in #6 is total crack.
Comment 16 Tom "spot" Callaway 2006-08-07 08:56:13 EDT
Ahh, the way to win friends and impress people. Insult their work.

The patch I wrote may not be the way that you'd choose to resolve the issue, but
to call it and the analysis "total crack", when I obviously went through the
trouble to generate a testcase, explain it, and display it, is simply rude and
uncalled for.

Also, stop closing rpm bugs as upstream. These are Red Hat bugs, and I've yet to
see this patch show up in rawhide.
Comment 17 Jeff Johnson 2006-08-07 14:37:48 EDT
Yep, all yer rpm bugs belong to Red Hat, even the ones I've fixed.

Not attributing contributions to a maintainer from the community (me) is perhaps
a more serious problem than a caustic comment (accompanied by a better patch)
from your well-meaning but incorrect patch.
Comment 18 Matthew Miller 2006-08-07 14:49:11 EDT
Jeff -- I think the important point is that while fixed upstream is *good*, this
isn't fixed for Fedora until we have the newer version actually in Fedora. And
the devel tree currently has version 4.4.2.....
Comment 19 Jeff Johnson 2006-08-07 18:21:23 EDT
I'm solely interested in making fixes for rpm exist in a timely fashion.

RH/FC certainly has had *years* to fix these problems if they chose to do so,
its not like I'm depriving anyone of joy of bugs, forevermore if you don't wish
to upgrade or backport fixes for rpm.

And the patch and analysis in #6 or crack no matter whether yer weenie got caught in yer zipper.
Comment 20 Matthew Miller 2006-08-07 23:15:39 EDT
> I'm solely interested in making fixes for rpm exist in a timely fashion.

Which is awesome, and thank you.

> RH/FC certainly has had *years* to fix these problems if they chose to do so,
> its not like I'm depriving anyone of joy of bugs, forevermore if you don't wish
> to upgrade or backport fixes for rpm.

Yeah. Is there a bugzilla for upstream RPM? It would be helpful for bugs like
this to become "there is a fix upstream, marked closed; please update rpm or
backport the patch".
Comment 21 Jeff Johnson 2006-08-08 00:30:43 EDT
*This* has always been the bugzilla for rpm, which is where the confusion lies.

No matter, there are like two critical rpm bugs left here to fix, the rest
are RHEL glacial fixes, then I shall be gone.
Comment 22 Matthew Miller 2006-08-08 06:29:46 EDT
> *This* has always been the bugzilla for rpm, which is where the confusion lies.

Which makes sense when upstream RPM == Red Hat RPM, but not anymore.

> No matter, there are like two critical rpm bugs left here to fix, the rest
> are RHEL glacial fixes, then I shall be gone.

Will there be a new upstream bugtracker?
Comment 23 Jeff Johnson 2006-08-08 07:16:55 EDT
Which makes sense if FC is interested in a "critically important" peice of software.

Probably MacOSForge.
Comment 24 Matthew Miller 2006-08-08 07:36:46 EDT
I don't think it ever makes sense for an upstream project to use a distro
bugzilla as its main bugtracker.
Comment 25 Jeff Johnson 2006-08-08 07:40:56 EDT
Lots of things don't make sense with rpm. E.g. rpm.org, which is rotting for the 4th time again again again 
again.
Comment 26 Panu Matilainen 2007-06-11 03:42:15 EDT
Fixed in rpm.org tree, will be in 4.4.2.1.
Comment 27 Panu Matilainen 2007-06-26 03:52:09 EDT
Fixed in next rawhide push by rpm 4.4.2.1-rc1 

Note You need to log in before you can comment on or make changes to this bug.