Bug#493389: update-grub: uses wrong ordering algorithm (sorts 1.2.3-foo before 1.2.3.1-foo)

[Henrique de Moraes Holschuh]

severity 493389 normal
thanks

> > I've written "change" not "bug" since I'm not sure it is a problem.

It is a problem, because it fails to implement the "path of least surprise"
for the users of the package.  Even for the highly technical ones like me
(kernel developer and Debian developer).

Kernels are numbered the same way Debian packages are (if you ignore "~" and
epochs).

There is absolutely NO reason for a human to accept that 1.2.3.1-foo is a
LOWER version number than 1.2.3-foo, simply because it is not.  When you add
one extra hierarchical component, it is a HIGHER version number, always.

So, update-grub is failing to do what is expected of it.

> > That is because `update-grub' is supposed to create a list with a
> > descending ordering. This means that there is a "char" comparison and
> > the one with a higher value should go first, for example -openvz-amd64

This just means the sorting algorithm is not good enough yet.

Why don't you guys get the algorithm from apt/dpkg instead of reinventing
the wheel?  Granted, you may want to simplify it since you won't need epochs
or "~", but you don't have to find clever ways to implement version sorting
from the ground up.

It is not like version sorting is easy to get right, anyway.  Better stick
to something that is already feature-complete and tested to do what is right
in every corner case that matters  (dpkg's sorting algorithm).

> > would go before -amd64 ('a' char vs 'o' char). The same way
> > -2.6.26-1-amd64 has precedence over -2.6.25-2-amd64 (25 vs 26).

Sorry, I can't agree that something that sorts 1.2.3.4-foo as lower than
1.2.3-foo is working correctly for kernel numbering.  It fails the usage for
upstream stable kernels, this is not a "theoretical issue" for anyone that
is not using Debian-packaged kernels (that just omit the stable version
level).

> Thanks Teodor.  This seems to come from #422759, which didn't make it to etch.

Looking at #422759, the test cases exemplified are very incomplete.

> For now I'd like to keep it open untill after the lenny release, since (I
> expect) a number of users might run into this during the lenny upgrade.

FIW, I ran into it on unstable, and I called it a bug because update-grub
failed to act in the way it is expected to.

If it will "cause surprises for Etch users", than it is even *WORSE* of a
problem IMO.

In light of that, I don't even agree this bug could have a priority other
than important or grave, but since I don't like bug severity fights, I will
settle for "normal".

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh