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.
Created attachment 108845 [details] Old version: foo 0:1-1
Created attachment 108846 [details] New version: foo (none):2-1
This is simple enough to fix. Patch attached.
Created attachment 111458 [details] Fix bug in freshen case where original package had Epoch: 0
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.
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.
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 :)
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!
FWIW, you haven't actually closed the bug... and I doubt you meant to leave it in limbo like this...
*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.
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).
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?
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.
Sorry, Ville. The analysis in #6 is total crack.
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.
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.
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.....
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.
> 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".
*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.
> *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?
Which makes sense if FC is interested in a "critically important" peice of software. Probably MacOSForge.
I don't think it ever makes sense for an upstream project to use a distro bugzilla as its main bugtracker.
Lots of things don't make sense with rpm. E.g. rpm.org, which is rotting for the 4th time again again again again.
Fixed in rpm.org tree, will be in 4.4.2.1.
Fixed in next rawhide push by rpm 4.4.2.1-rc1