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.
Hmmm, the name comparison occurs when the rpmdb iterator
is initialized, only headers that match in name are
Or am I missing something?
Yes, the iterator uses RPMTAG_PROVIDENAME, not RPMTAG_NAME
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.
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.
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)
Apologies s/up fraded/upgraded/
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.
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".
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.
Hmm, is the SHA1 signature header entry "mandatory"?