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

[Ben Hutchings]

On Sun, 2011-04-24 at 22:21 +0100, Colin Watson wrote:
> 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.

I've tried to define an ordering that will be correct for official
Debian kernel packages and will sort custom packages for the same
upstream version higher than the official packages.

However, kernel version numbers really aren't linear and I fear that it
will be a lot more difficult to come up with rules that will suit all
distributions' version conventions.  Maybe not.

> > 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.

I'm aware of that, but my original mail was sent to maintainers of all
bootloaders and was therefore general.

> 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.

and are compared in ASCII order

>     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.

That matches my intent.

> 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'.

I hadn't noticed that change - probably because it came some time after
the accidental use of '-trunk' outside of experimental.

> 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.

I wasn't previously aware that searching for kernel images and sorting
them was part of upstream GRUB.  I agree that that is a good reason to
establish a cross-distro specification.

> 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?

The '-pre' and '-test' suffixes haven't been used in many years, but it
wouldn't do any harm to add them.

The '-git' snapshots from kernel.org are *later* than the version whose
name precedes the '-git' suffix, so I don't think '-git' should be
treated specially.

The '.old' suffix is used in unversioned symlinks but not in any version
numbers I can think of.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20110424/ac76222a/attachment-0001.pgp>