Bug#205960: Patch
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
Reply to: