If you have two RPMs with EVRs of 1.0.1-10.7.2 and 1.0.1-10mdk, RPM doesn't know which is newer. The rpmvercmp function always returns 1, reguardless of which order they are passed to it. Bug #21392 tried to fix this, but is just changed the return value, and didn't fix the underlying problem. It used to always return -1, now it returns 1. The attached patch will prevent the current ambiguity, and will not break existing RPM functionality. With this patch 10.1mdk is still newer than 10mdk.
Created attachment 26355 [details] Patch against tip of branch rpm-4_0 in CVS
Having tested this patch some more, one other thing has shown up: distributions which start with an alpha string in the release will always loose version comparisons. Currently, Mandrake, Connectiva and Scyld use alpha strings appended on to the release, while Ximian prepends an alpha string to the release. As an unintended side effect of this patch is that it helps with the issue of users upgrading from RHL+Ximian GNOME to RH's next release having a mixture of Red Hat and Ximian RPMS left on their machine. A couple of examples: Original Bug #21392 This patch -------- ---------- ----------5 < 6 5 < 6 5 < 6 10 > 9 10 > 9 10 > 9 10mdk > 10 10mdk > 10 10mdk > 10 10mdk < 10.1mdk 10mdk > 10.1mdk 10mdk < 10.1mdk 10.1mdk < 10mdk 10.1mdk > 10mdk 10.1mdk > 10mdk 8 < ximian.1 8 > ximian.1 8 > ximian.1 ximian.1 < 8 ximian.1 < 8 ximian.1 < 8 Originally, RPM always returned -1 (less than) when comparing alpha and numeric values (reguardless of the order). When the patch from Bug #21392 got applied to RPM, it always returned 1 (greater than).
(Replying at Jeff's request) First impressions: the behaviour in your patch is: a) obviously unacceptable for our current scheme -- as you note, all ximian packages would then lose version comparisons, making our packages virtually uninstallable. We would have to resort to bumping epochs on our packages, something I can't tell you how much I want to avoid. b) rather hackish, as what you're essentially doing is implicitly breaking a single field (version/release) into multiple fields, where 10mdk and 10.1mdk become "10" "mdk" and "10.1" "mdk" before comparison starts. (Yes, I realize this isn't how the code actually does it, but it's semantically identical.) Realize that your patch is essentially the opposite of something we sent off to Jeff a while back (and what was applied to our copy of rpmvercmp inside red carpet), which makes alpha sort higher than numeric (behaviour: ximian.1 > 1 (good), 10mdk > 10.1mdk (bad)). We fixed the appended alpha problem by stripping these characters off, as they don't appear to be used for anything other than immediate vendor recognition (more on this later). Thus, when confronted with 10mdk and 10.1mdk, we just stripped the mdk parts first, then compared 10 and 10.1, which works fine. The presence of the "mdk", occuring as it does after the rest of the release string, doesn't really affect the comparison except in a few cases. Now, I can understand that you might view this as suboptimal. ;-) Proposal: Stop allowing alpha characters in the release, and define appropriate behaviour for the version. Vendor information should go in the VENDOR header tag. This sucks because it's then unclear how to easily relate packages from different vendors (not that it's clear at all today). IE if distribution A ships with foo-1.0-5, and we then ship Ximian GNOME for A, we would probably have to start our package at release 6 (foo-1.0-6) to ensure that things correctly installed. This breaks, of course, if A later ships an update to foo as foo-1.0-33 (perfectly within their rights and logical if they've been through 28-some internal releases). Perhaps it makes sense to allow package dependencies to encode vendor information without putting this into the release field. Thus, if we ship mozilla and nautilus with modifications such that our nautilus packages only work correctly with our mozilla packages, we could have nautilus require something like mozilla > {XIMIAN}0.9.1... I apologize for how long and stream of consciousness this is, but I'm short on sleep and quite a bit sick. As to timing, the sooner this gets resolved the better, I think. I'd love it if we could all come to some consensus and then work our an appropriate ruleset, move to whatever new naming scheme is chosen, etc without much trouble.
This defect really needs to be fixed, but there's simply no way to get it done in time for the next release... thanks for reporting this one, though!
Created attachment 26553 [details] 2nd try at a patch
After I found the Ximian issue, I assumed it would not be a satisfactory solution. The last thing I want to do is encourage epoch inflation. I also don't want to create two different rpmvercmp functions - one for versions and one for revisions. I think that forcing the release to be only numeric is a little drastic, and would prevent things like 2.10m, which some programs, such as util-linux use for version numbers. The basic premise of the fixes is that the following should be true: 1) if (a = b) then (b =a ) and 2) if (a > b) then (b < a) Currently, only #1 is guarenteed to be true. #2 frequently true, but sometimes (a > b) and (b > a), which causes problems when trying to figure out what to upgrade. My 2nd try at a fix uses the fix from 21392, but changes the code that searchs for the endpoints of the substring. If the beginning of both substrings are alpha, the is no change in the logic -- it scans until it finds a non-alpha char. However, if _either_ substring begins with a number, it finds the first numeric substring in each string, and compares those. So what does this mean to existing packages? Here are some examples from my previous table, plus a couple more: Patch #26553 ------------ 5 < 6 10 > 9 10mdk > 10 these are all as expected 10mdk < 10.1mdk 10.1mdk > 10mdk finally, this is correct 8 > ximian.4 ximian.4 < 8 same as the last patch, but hold on 2 < ximian.4 ximian.4 > 2 nifty. We are only comparing the numbers, so it works. So, as was suggested, add-on/overlay vendors, such as Ximian, VA Linux, and Scyld would have to make sure that packages shared with a base distribution started release numbering with the base's release number. The issue about errata still exists, however. For Ximian's packages, if Red Hat had a package version 1.0.1-5, Ximian would have to start with 1.0.1-ximian.6. As to the second suggestion, the idea allowing dependencies on RPMTAG_VENDOR, I will hold off on that. It should probably get opened as a seperate bug. I must appologize if this seems like a really bad fix. I came up with it on the way home, and I am very tired. But I agree that it would be good to get this fixed soon.
Adding vendor as part of dependency solving is The Wrong Thing To Do for open source. There's certainly nothing stopping you from, say, coloring all ximian packaging with Requires: ximian_is_my_vendor and adding the corresponding Provide" somewhere. Attached are my comments sent privately, now public.
Created attachment 26636 [details] rpmvercmp background comments
Jeff, I commend you on your email. You have done an excellent job of summarizing the issue. I hope that this gets brought up on rpm-list soon. As to the current characters in use, Daniel Veillard gave me a dump of the unique versions and releases in rpmfind's database. They are available at http://www.scyld.com/~pzb/version and http://www.scyld.com/~pzb/release These character sets for these are very similar: version uses 0-9a-zA-Z and . _ + - @ release uses 0-9a-zA-Z and . _ + - Looking at the rpmfind dataset,, @ in version seems to primarily be from failed configure replacements. The - was a suprise because it should be disallowed and the + seems to be rarely used. For the new code, I would suggesting using a case-insensitive comparisson function, but this would probably cause the Oracle guys some problems (Sorry deviant, gafton, et al). Additionally, it would be nice to drop + - and @ from the valid list, which would leave RPM with an effective list of a-z, 0-9, ., and _ which seem like plenty. It might even be possible to s/_/./ so that it would just be letters, numbers, and . For legacy purposes, + - and @ could be converted to _ or . This still doesn't solve the floating point issue, but I don't think there is a good answer to that, because 2.04.7ac8 is, presumably, equal to 2.4.7ac8, but 10.01 is not equal to 10.1.
*** Bug 51333 has been marked as a duplicate of this bug. ***
Created attachment 31838 [details] here is what we are probably going to use in the 8.1
Jeff, in response to your question in the email you attached to this bug, I think implementing the pain would be best in rpm 4.1. its a big-ish shift in what rpm does and people with any amount of sense know things are going to break a little then.
I tend to agree with Seth. Now is the right time to change this. I think that all parties now agree that numbers should be sorted higher than letters. We (Ximian) are using a patch that does this. I think that it is the One Right Way, as it ensures, on that distros that append a static string to the release, such as Mandrake, Conectiva, and PLD, that version compares continue to work as expected. This also makes rpmvercmp transitive, which will make many people happy. The only dissenter in the past has been Ximian, but we now agree that it is the Right Thing(TM).
Created attachment 60884 [details] Make rpmvercmp transitive
*** Bug 69342 has been marked as a duplicate of this bug. ***
P.S. it appears that RHN is also using the "non-assimmetric" relation (same as rpm?) that also causes problem (see dup bug 69342), but up2date somehow is using something else!
I wrote a testjig to determine the impact of patch 60884. I tested upgrade and downgrade senarios for all packages in Red Hat Linux 6.2 through 8.0. The testjig code, with the testcases, is available at http://www.linux.org.uk/~pzb/50977-testjig.tar.gz. The patch in question determines a sort order when comparing an alpha char to a numeric char. The numeric char is determined to always sort higher than the alpha char. Testing shows that only four packages in RHL have any sort of issue with this change -- cipe, fileutils, hanterm-xf, and textutils. cipe-1.4snap-1.i386.rpm shipped with RHL7.0. More recent RHL releases have 1.4.5-{5,6,9,11}. Upgrades will work as expected, because numbers are still sorted higher than letters in the modified function. fileutils 4.0x-3 shipped in RHL7.0, and fileutils 4.0.36-4 shipped in RHL7.1. As above, the upgrade will work as expected. hanterm-xf p19-15 shipped in RHL7.2 and RHL7.3, and hanterm-xf 2.0.0-6 shipped in RHL8.0. As above, the upgrade will work as expected. textutils 2.0e-6 shipped in RHL6.2 and textutils 2.0e-8 shipped in RHL7.0. In RHL7.1 textutils 2.0.11-7 was shipped. As above, the upgrade will work as expected. All of these will work on upgrade, but, in the past, you could also "upgrade" back to the version from the previous release without rpm complaining. With the patch, you must pass the --oldpackage flag. I think that this is what people will expect, as a downgrade should require the --oldpackage flag. I hope that patch 60844 can get into RPM 4.2.
Adding patch #60844 in rpm-4.2-0.55. Thanks for the help getting this sorted out *finally*.
*** Bug 82639 has been marked as a duplicate of this bug. ***