Bug 143301

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