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 compared. 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) since rpm-4.0.
Apologies s/up fraded/upgraded/
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.
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"?