On Mon, 2011-02-21 at 11:12 -0800, David Peterson wrote: > I have some code that uses rpmdsCompare as follows: > > rpmds x, y, z; > > // code that initializes x, y, and z goes here > > int result0 = rpmdsCompare(x, z); > int result1 = rpmdsCompare(y, z); > > Adding printf() calls immediately before the calls to rpmdsCompare() > shows that x, y, and z contain the following information: > > contents of x > ------------- > type: Provides > name: kernel > epoch/version/release: 2.6.18 > flags: 0x08 [...] > contents of z > ------------- > type: Requires > name: kernel > epoch/version/release: 2.6.18-238.1.1.0.1.el5 > flags: 0x08 > > result0 gets a value of 1, indicating a match. result1 gets a > value of 0, indicating no match. Is this the expected behavior? I > would have expected a result of "no match" in both cases since > neither x nor y has an epoch/version/release value that matches z > exactly. Yeh, this confuses a lot of people because: % rpmdev-vercmp k-2.6.18 k-2.6.18-1 0:k-2.6.18-1 is newer ...and so: Requires: k = k-2.6.18-1 Provides: k = k-2.6.18 ...shouldn't match, by any normal definition ... but rpm isn't "normal" here :) rpm actually treats the above like: Requires: k = k-2.6.18-1 Provides: k = k-2.6.18-* ...so you can require any release you want, and it'll match. This is normally not a problem because a package name like "kernel" always specifies a full EVR, but the kernel is different and _also_ provides a none release version. Eg. % rpm -q --provides kernel-2.6.18-194.32.1.el5 | fgrep 'kernel ' kernel = 2.6.18 kernel = 2.6.18-194.32.1.el5 ...and thus. the first one will match against "kernel = 2.6.18-blah". _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
