Dropping unversioned kernel links/copies; adding linux-version command

Colin Watson cjwatson at debian.org
Sun Apr 24 21:21:33 UTC 2011


On Sun, Apr 10, 2011 at 04:02:36PM +0100, Ben Hutchings wrote:
> On Sun, 2011-04-10 at 15:32 +0100, Ben Hutchings wrote:
> > On Sun, 2011-04-10 at 14:15 +0200, Vladimir 'φ-coder/phcoder' Serbinenko
> > wrote:
> > > On 01.04.2011 14:04, Ben Hutchings wrote:
> > > > There isn't an official spec.  However the source and unit tests for the
> > > > DebianLinux Perl module (added to linux-base to support this command)
> > > > explain the rules I came up with.
> > > 
> > > I don't feel that this is enough. I wanted something that we could agree
> > > on, so this could be pulled upstream and eventually also become
> > > guideline for other distros. Also having a spec has a benefic effect of
> > > clearness and it would also serve as guideline for choosing the version
> > > names for uploads.
> > 
> > Then *you* can write a spec.  Don't tell me what extra work I should be
> > doing.

I don't think Vladimir did any more than what you did; you could just as
easily be interpreted as telling us to make a change to GRUB (at some
level, whether upstream or in Debian).  But, more realistically, both of
you are essentially offering bug reports.  Why not just keep the
conversation at that level rather than getting offended and calling
things "demands"?  It seems like it'd be easier for everyone.

It seems entirely reasonable for an upstream maintainer to seek
something that we can agree on upstream rather than something that's
Debian-specific.

> For the avoidance of doubt, this still applies:
> 
> "If there are any remaining reasons to continue using the unversioned
> links, or additional features you think linux-version should provide,
> please let us know."

Just for clarity, GRUB does not use the unversioned links.

Since nobody else seems to want to do it, I'll attempt to write a spec,
then, and maybe people can find time to review and discuss it.  Here's a
mostly English description of the rules that the DebianLinux Perl module
uses:

  1) Split the version number into a series of components (using greedy
     matching) each of which is either a string of digits, a hyphen
     followed by zero or more non-digits, or a string of non-hyphen
     non-digit characters.

  2) For each component, apply each of the following comparisons in
     sequence, stopping at the first unequal comparison:

    1) If a component is "-rc" or "-trunk", then it indicates a
       pre-release.  Pre-releases sort before non-pre-releases.

    2) End-of-string sorts before non-end-of-string.

    3) If both sides are numeric, compare numerically.  Otherwise,
       compare according to ASCII order.

  3) If all components compare equal, the versions are equal.

Upstream GRUB currently compares version numbers using 'sort -n'.

Debian GRUB currently transforms anything matching
/[._-](pre|rc|test|git|old|trunk)/ into ~$1, and then compares using
'dpkg --compare-versions'.

We should definitely improve GRUB's sorting algorithm; 'sort -n' is
obviously over-simplistic (consider 2.6.9 vs. 2.6.10 - the -n option
isn't enough to compare each component numerically).  The Debian patch
largely makes it work fine in practice but there's been the odd glitch.
While I could patch it in Debian to use linux-version instead, I'd much
rather have something we can agree on upstream, and clearly a
Debian-specific command won't cut it there.  The above algorithm seems
simple enough; I can probably find time to propose a strawman patch to
grub-mkconfig_lib for that at some point.

The main thing that I'm unsure about in DebianLinux's algorithm is the
pre-release handling.  Debian GRUB has several more ways in which
pre-releases have been named, as mentioned above, and while they may not
be used right now I'm pretty sure that we added them because they were
used in the past.  Is there any reason not to add those extra names for
pre-releases to DebianLinux?

Thanks,

-- 
Colin Watson                                       [cjwatson at debian.org]



More information about the Pkg-grub-devel mailing list