Re: Debian version numbers and strcmp()
Adeodato Simó writes ("Debian version numbers and strcmp()"):
> I'd like to hear from members of this list what they think about the
> following issue: I just noticed that to determine whether two Debian
> versions are equal, one can't use strcmp() or similar, and must
> implement the full comparison algorithm. For example, 0.9 and 0.09 are
> the same version according to Policy.
I defined the version number comparison algorithm originally, so I'm
afraid this is my fault :-). But I still think I made the right
decisions, near enough.
My goal was to allow most packages' upstream version numbers to be
used directly. Obviously not all packages can be handled in this way
because some of them do insane and incompatible things - for example,
at the time I defined the Debian scheme there was a project which went
1.2.1, 1.2.2, 1.2.3, 1.2 - yes, 1.2 > 1.2.1.
By far the majority of projects did and do treat numbers containing
multiple strings of digits as integers rather than decimal fractions.
So that's what the algorithm I specified and implemented does.
If we had wanted to use strcmp then we would have had to pre-zero-pad
every upstream version number. GCC versions would be 4.001.003
because of the risk that they might get up to what upstream would call
something like 4.102.271.
Raphael Hertzog writes ("Re: Debian version numbers and strcmp()"):
> This awkwardness has led to several epoch usage and/or uptsream
> version mangling on Debian packages. I have seen upstream publish
> 1.001 to 1.006 then 1.2 (and we noticed because we had to work
> around it).
Unfortunately it is not possible to come up with a sane version number
scheme which supports this kind of interpretation of version
numbers, as well as the more conventional. If upstream think that
1.006 < 1.2 they will also think that 1.206 < 1.3. But everyone else
thinks that 1.3 < 1.206.
It might have been possible to special-case this for version numbers
with leading zeroes (something along the lines of Russ's suggestion)
but I'm not sure that adding extra complications would have been
wise. The current scheme has the virtue that it's not that hard to do
by eye as well as by computer.
Certainly changing it now is a non-starter. (Introducing the new ~
character with its special semantics was a great idea though; I'm just
ashamed I didn't think of it myself from the beginning - if I had we
could perhaps have used a less weird character for it.)
Regards,
Ian.
Reply to: