Re: dpkg doing wrong math (0.09 = 0.9) ?-
On Fri, Aug 11, 2006 at 07:17:43AM +0200, Florian Weimer wrote:
> "." is not special as far as version numbers are concerned. It's not
> a separator, for instance, and "1." is a valid version number (which
> is equal to "1.0").
Uhm, where does the "0" come from? This is grossly unintuitive, and I would
consider this a bug. Both strings parse as follows:
"1." => "", 1, "."
"1.0" => "", 1, ".", 0
Lexicographically, the former is obviously smaller. In every single version
comparison scheme I saw before, non-numeric and numeric parts get compared
alternatively until a mismatch is found. It's just dpkg which instead
parses both strings as:
"1." => ("",1), (".",0)
"1.0" => ("",1), (".",0)
That is, dpkg will make up a 0 at the end.
> We need a total ordering of version strings, and any approach is
> arbitrary to some degree because we don't want to use purely
> lexicographic comparison (otherwise, "9.x" would be greater than
> "10.x", which is clearly counterintuitive). There are upstream
> version number schemes for which the Policy algorithm works perfectly
> well (1.01, 1.02, ..., 1.09, 1.10, ...) and others where it doesn't.
GNU strverscmp() will handle numeric substrings starting with a 0
differently, leading to a switch and possible breakage once "09" turns into
"1" ("09" < "1" < "10", but "19" > "2" < "20". This what I call unnecesary
complication, and it's obvious why this is bad.
I think the same about inventing a "0" from thin air.
And another bug: "2a.0" is _lesser_ than "2.0"! This works as documented,
but is totally against lexicography, expectations and common sense.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Reply to: