On Mon, 1 Sep 2003, Matt Zimmerman wrote: > Thanks for the patch. This is approximately what I had decided would need > to be done, but I'm not sure that I like it. It seems like the problem that > '~' was meant to solve should be solvable by some means which does not break > the rule that shorter version numbers are smaller. I'll think on it some > more.
Sorry, I don't get what you mean... please show me an example :-)) First, I think this ~ feature is an ingenious idea in dpkg. I've been wondering a lot on how pre-version can be gracefully solved in package managers' versioning scheme. I even had so terrible ideas such as negative numbers (e.g. 3.-1.0) but I didn't like it. Mandrake uses 0.x in the release part. SuSE simply forgets to reflect in the version number that it's a preversion. All of these are ugly. Dpkg's idea of ~ is fantastic. Second, even though I haven't thoroughly tested my patch, I can't see where it can be buggy. apt already contains the code that gathers numeric segments of both version numbers. For example if you try to compare 5~foo with 42 then it's not the ~ < 2 relation that decides the question, apt collects digits (5 and 42), compares these two numbers and decides that 5 < 42. It doesn't even hit that ~ character and hence I believe it doesn't run the code I've patched. And even if it didn't do so and it compared from byte to byte, than still if it founds a ~ in one of the versions, while the other one continues with a digit, than it's likely that this other one is a bigger number since it has more digits. So it would be okay in this case too. One non-trivial issue is numbers with leading zeros, but apt's code seems to skip leading zeros, so currently (with my patch) dpkg and apt agree on that 6~beta-1 < 6-1 < 007~beta-1 < 007-1 < 8~beta-1 < 8-1. I'll try to think on it but at this moment I can't see any situations where either the specification of ~ is not good or this patched apt behaves differently that one would expect. -- Egmont
