FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 04-01-2011, 02:29 PM
Jason Fleischli
 
Default Dropping unversioned kernel links/copies; adding linux-version command

Elilo's perspective
On Fri, 2011-04-01 at 04:33 +0100, Ben Hutchings wrote:
> With version 3.2 of linux-base, I've added the command 'linux-version'
> which should make these things easier, and should help you to generate
> kernel version menus without the aid of links.
[Added the command 'linux-version' to what?]
the elilo efi binary doesnt generate a kernel list and loads versioned
filenames from the local efi boot partition defined in elilo.conf under
versioned labels just fine.
The elilo efi binary wouldnt need any change. Only the elilo debian
script would need to be changed to accomodate that I believe.

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

was this adequate feedback?

-Jason


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1301668183.9288.6.camel@charlene">http://lists.debian.org/1301668183.9288.6.camel@charlene
 
Old 04-01-2011, 03:44 PM
Ben Hutchings
 
Default Dropping unversioned kernel links/copies; adding linux-version command

On Fri, Apr 01, 2011 at 08:29:43AM -0600, Jason Fleischli wrote:
> Elilo's perspective
> On Fri, 2011-04-01 at 04:33 +0100, Ben Hutchings wrote:
> > With version 3.2 of linux-base, I've added the command 'linux-version'
> > which should make these things easier, and should help you to generate
> > kernel version menus without the aid of links.
> [Added the command 'linux-version' to what?]

As I said, 'version 3.2 of linux-base'.

> the elilo efi binary doesnt generate a kernel list and loads versioned
> filenames from the local efi boot partition defined in elilo.conf under
> versioned labels just fine.
> The elilo efi binary wouldnt need any change. Only the elilo debian
> script would need to be changed to accomodate that I believe.
[...]

Yes, and that is what I am concerned with. I don't believe any of
the boot loaders themselves would have trouble with using full names.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110401154417.GC2268@decadent.org.uk">http://lists.debian.org/20110401154417.GC2268@decadent.org.uk
 
Old 04-10-2011, 02:32 PM
Ben Hutchings
 
Default Dropping unversioned kernel links/copies; adding linux-version command

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.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 04-10-2011, 03:02 PM
Ben Hutchings
 
Default Dropping unversioned kernel links/copies; adding linux-version command

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.

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

However Vladimir's demand was out of scope.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 04-24-2011, 09:21 PM
Colin Watson
 
Default Dropping unversioned kernel links/copies; adding linux-version command

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@debian.org]


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110424212133.GP31494@riva.ucam.org">http://lists.debian.org/20110424212133.GP31494@riva.ucam.org
 
Old 04-24-2011, 10:41 PM
Ben Hutchings
 
Default Dropping unversioned kernel links/copies; adding linux-version command

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.
 

Thread Tools




All times are GMT. The time now is 07:05 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org