Bug 104066 - Tests in depend.c think rpmVersionCompare() compares the name
Summary: Tests in depend.c think rpmVersionCompare() compares the name
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
(Show other bugs)
Version: GinGin64
Hardware: All Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2003-09-09 16:19 UTC by Michael Schröder
Modified: 2007-04-18 16:57 UTC (History)
1 user (show)

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

Attachments (Terms of Use)

Description Michael Schröder 2003-09-09 16:19:27 UTC
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 12:34:28 UTC
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 13:27:46 UTC
Yes, the iterator uses RPMTAG_PROVIDENAME, not RPMTAG_NAME

Comment 3 Jeff Johnson 2003-09-10 19:15:46 UTC
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 10:38:33 UTC
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-15 02:55:32 UTC
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-15 02:57:30 UTC
Apologies s/up fraded/upgraded/

Comment 7 Michael Schröder 2003-09-15 09:56:51 UTC
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 17:17:08 UTC
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-26 00:06:19 UTC
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 09:48:02 UTC
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.