Re: 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
Re: 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 [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110424212133.gp31...@riva.ucam.org
Re: 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. signature.asc Description: This is a digitally signed message part
Re: 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. signature.asc Description: This is a digitally signed message part
Re: Dropping unversioned kernel links/copies; adding linux-version command
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. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110401154417.gc2...@decadent.org.uk
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301668183.9288.6.camel@charlene
Re: Dropping unversioned kernel links/copies; adding linux-version command
On Fri, 2011-04-01 at 13:49 +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Hello, all. I'm not a packager but GRUB2 upstream maintainer and so I'll > speak from our point of view. > > Dropping unversioned kernel links/copies > Go for it. These files are just a nuisance > > As I understand it, the main reason for these is to allow boot loaders > > to be configured using the unversioned link names, so that neither users > > nor maintainers have to update the configuration for new kernel > > versions. > > > Hm, goal not really accomplished. But I'll provide some GRUB2 > configuration snippets to accomplish this with scanning the kernel list > at boot time if some admins don't want to rely on update-grub being > correctly run. These scripts would just be an alternative, not default. > > - Comparing and sort versions (grub gets this wrong) > > > > > Trouble comes from Debian adopting seemingly unpredictable version > suffixes. No it doesn't. '-rcN' is just as problematic as '-trunk'. > Could you perhaps provide a spec on how to compile 2 Linux > versions so we all get it right and done in the same way? > > 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. > > > Haven't checked it yet. However I would like to avoid using > debian-specific tool if possible. So I'd prefer a spec. 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. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Dropping unversioned kernel links/copies; adding linux-version command
Hello, all. I'm not a packager but GRUB2 upstream maintainer and so I'll speak from our point of view. > Dropping unversioned kernel links/copies Go for it. These files are just a nuisance > As I understand it, the main reason for these is to allow boot loaders > to be configured using the unversioned link names, so that neither users > nor maintainers have to update the configuration for new kernel > versions. > Hm, goal not really accomplished. But I'll provide some GRUB2 configuration snippets to accomplish this with scanning the kernel list at boot time if some admins don't want to rely on update-grub being correctly run. These scripts would just be an alternative, not default. > - Comparing and sort versions (grub gets this wrong) > > Trouble comes from Debian adopting seemingly unpredictable version suffixes. Could you perhaps provide a spec on how to compile 2 Linux versions so we all get it right and done in the same way? > 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. > Haven't checked it yet. However I would like to avoid using debian-specific tool if possible. So I'd prefer a spec. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature
Dropping unversioned kernel links/copies; adding linux-version command
As you may be aware, the kernel team has been gradually simplifying the
maintainer scripts of kernel image packages and removing features that
are redundant with hooks. (Note that packages built with make-kpkg or
the upstream 'deb-pkg' target already lack these features.)
One of those features remaining is the creation of symlinks (or hard
links, or copies!) in / or /boot named {vmlinu[zx],initrd.img}{,.old}.
As I understand it, the main reason for these is to allow boot loaders
to be configured using the unversioned link names, so that neither users
nor maintainers have to update the configuration for new kernel
versions.
The problems with these unversioned links is:
- Boot loaders that use them don't show kernel version numbers
- The logic to update them safely is extremely complex
- They often end up broken after a package removal (particularly
the .old links), and this can prevent updating the boot loader
The difficulties with including all kernel versions seems to be:
- Listing installed kernel images (?)
- Comparing and sort versions (grub gets this wrong)
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.
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.
Ben.
--
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.
signature.asc
Description: This is a digitally signed message part
