Bug 104066 - Tests in depend.c think rpmVersionCompare() compares the name
Tests in depend.c think rpmVersionCompare() compares the name
Status: CLOSED UPSTREAM
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
GinGin64
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2005-10-25 20:06:19 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)

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

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