Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 104066 - Tests in depend.c think rpmVersionCompare() compares the name
Tests in depend.c think rpmVersionCompare() compares the name
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2003-09-09 12:19 EDT by Michael Schröder
Modified: 2007-04-18 12:57 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-25 20:06:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Schröder 2003-09-09 12:19:27 EDT
depends.c uses rpmVersionCompare() to check if two headers are identical,
but rpmVersionCompare() doesn't check the name. E.g. if foo-1.0.0 is installed
and bar-1.0.0 provides foo, foo won't get deinstalled if bar gets installed.
Comment 1 Jeff Johnson 2003-09-10 08:34:28 EDT
Hmmm, the name comparison occurs when the rpmdb iterator
is initialized, only headers that match in name are

Or am I missing something?
Comment 2 Michael Schröder 2003-09-10 09:27:46 EDT
Yes, the iterator uses RPMTAG_PROVIDENAME, not RPMTAG_NAME
Comment 3 Jeff Johnson 2003-09-10 15:15:46 EDT
Yes, PROVIDENAME, not NAME, is what dependencies are matched on.

There are no remaining cases where package name is used
in dependencies, each package provides its own N = E:V-R.

This isn't a bug.
Comment 4 Michael Schröder 2003-09-11 06:38:33 EDT
Argh, I know that it uses PROVIDENAME. The point is that it matches packages
with other names. Here's another example:

foo-1-1 provides bar. If you install bar-1.2, foo-1.1 will be uninstalled.
That's fine with me.

But if you install bar-1.1, foo-1.1 will stay, as the versions match.
Comment 5 Jeff Johnson 2003-09-14 22:55:32 EDT
Is this a theoretical issue or a real world problem?

The only case that I can think of where this might happen is
with the Provides: kernel in the kernel-smp package, so kernel-smp
is upgraded by kernel, but kernel is not up fraded by kernel-smp.

Since kernels are seldom upgraded it's pretty much moot. Arguably, it's
a packaging error as well.

No matter what, this is a matter of definition of "upgrade", and the
behavior implemented has been the defacto behavior (w/o any known problem)
since rpm-4.0.
Comment 6 Jeff Johnson 2003-09-14 22:57:30 EDT
Apologies s/up fraded/upgraded/
Comment 7 Michael Schröder 2003-09-15 05:56:51 EDT
Well, it's not theoretical, but the package in question was also packaged
Anyway, it is a bug in the code and it can be easily fixed with a comparison
of the package names. You shouldn't defend buggy code with the argument that
the bugs aren't hit in real life.
Comment 8 Jeff Johnson 2003-09-15 13:17:08 EDT
My goal is to encapsulate the meaning of "upgrade"
as much as possible within a dependency (i.e. not package names)
name space. That is simpler to implement and test, more general,
and with fewer side effects (i.e. than what was in rpm-3.0.x.

Whether the current implementation is buggy or not depends
on what the definition of "upgrade" is. That was the reason for
asking whether the problem was real world, certainly not "defending".

No matter what, the current implementation is what has been there
since rpm-4.0, and any change to the definition needs to be carefully
understood before being called "buggy".
Comment 9 Jeff Johnson 2005-10-25 20:06:19 EDT
The header SHA1 is now used to define "identical", rather than the package NEVR, in rpm-4.4.3.
So this issue is now moot.
Comment 10 Michael Schröder 2005-10-26 05:48:02 EDT
Hmm, is the SHA1 signature header entry "mandatory"? 

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