Hi all!
I'd like to put a old but still valid discussion on the table again where a solution never was found: Pre-release kernel versioning.
In short: Kernel like for example kernel-2.6.20-1.3066.fc7 are in reality 2.6.21-rc6-git5. That's not only confusing to users, it also breaks outside kernel modules sometimes; just yesterday I saw a patch in 3rd party repo applied that did this...
+-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,21) ++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
...to make it compile against the kernel from FC4-test4 (no idea if it helped, but I had to apply similar patches in the past nyself to make somethign work), as the kernels in rawhide until they switched to 2.6.21-final announces itself as 2.6.20-1.3066.fc7 instead of 2.6.21-rc6-git5, as upstream would do.
I don't want to get further into the details if I don't have to, as this stuff was discussed multiple times already on mailing lists. The last time was here: https://www.redhat.com/archives/fedora-devel-list/2007-March/msg00897.html
So, what will we do in the future? Can we (after F7 is out and rawhide rolls again) please switch to something less confusing where version somehow allows normal users to clearly see what kernel they got? And one that doesn't confuse outside modules? Something like
kernel-2.6.22-1.3200.fc7.rc2.git15
maybe?
CU thl
On Sun, 2007-04-29 at 15:03 +0200, Thorsten Leemhuis wrote:
kernel-2.6.22-1.3200.fc7.rc2.git15
Not to distract from Thorsten's good points here, but the longer the kernel n-v-r, the more painful it is for SPARC.
The SPARC bootloader (silo) can't handle label names longer than 15 characters. So, for example, when booty tries to automagically label a new kernel on Aurora, we get a label like:
2.6.22-1.3200.fc
The more we overload that n-v-r, the less useful that label is.
Proposal:
- Lose the leading 1. It really doesn't serve much purpose. It would be better to roll to 10000 if you have that many builds before the kernel increments.
If we only do this, then we get boot labels of:
2.6.22-3200.fc7
(with room for 2.6.22-10000.fc7 if we need it)
Also, I'll simply note that Fedora has established naming policy for pre-release and post-release packages, and I suspect that policy could be adapted to apply to the kernel.
(http://fedoraproject.org/wiki/Packaging/NamingGuidelines)
~spot
On Sun, Apr 29, 2007 at 08:13:19AM -0500, Tom spot Callaway wrote:
The SPARC bootloader (silo) can't handle label names longer than 15 characters. So, for example, when booty tries to automagically label a new kernel on Aurora, we get a label like:
2.6.22-1.3200.fc
The more we overload that n-v-r, the less useful that label is.
silo can't be fixed ?
Proposal:
- Lose the leading 1. It really doesn't serve much purpose. It would be
better to roll to 10000 if you have that many builds before the kernel increments.
it's the cvs ident, so it'll need some shell scripting to sed it away or something.
(with room for 2.6.22-10000.fc7 if we need it)
Eventually, it'll get that high.
Dave
On Sun, Apr 29, 2007 at 03:03:42PM +0200, Thorsten Leemhuis wrote:
So, what will we do in the future? Can we (after F7 is out and rawhide rolls again) please switch to something less confusing where version somehow allows normal users to clearly see what kernel they got? And one that doesn't confuse outside modules? Something like
kernel-2.6.22-1.3200.fc7.rc2.git15
How does this help up until rc1 ? For example right now, upstream is 2.6.21-git2, yet there's 14MB of patches already, (and much more to come before .22rc1) so it's clearly not .21 and is likely to break anything that relies upon kernel interfaces not changing vs .21 and it's not .22 either yet.
the package versioning isn't whats relevant here, it's the versioning in version.h that broken external drivers insist on comparing against instead of comparing against #defines to check for features.
Finally, there are cases where we'll change a prototype of a function in Fedora vs upstream when we backport something early, or develop some new feature etc, so just matching the version number isn't a panacea anyway.
Dave
On 29.04.2007 21:08, Dave Jones wrote:
On Sun, Apr 29, 2007 at 03:03:42PM +0200, Thorsten Leemhuis wrote:
So, what will we do in the future? Can we (after F7 is out and rawhide rolls again) please switch to something less confusing where version somehow allows normal users to clearly see what kernel they got? And one that doesn't confuse outside modules? Something like
kernel-2.6.22-1.3200.fc7.rc2.git15
How does this help up until rc1 ?
That's a good question I don't have a answer to myself, as Linus seems to increase "SUBLEVEL =" in Makefile when releasing rc1 afaics. So for this case I'm fine with either going with
kernel-2.6.21-1.3200.fc7.git3 or kernel-2.6.22-1.3200.fc7.git3
As the number before ".fc7." increases in any case we don't have to care what comes after in in %release as it won't confuse rpmvercmp.
For example right now, upstream is 2.6.21-git2, yet there's 14MB of patches already, (and much more to come before .22rc1) so it's clearly not .21 and is likely to break anything that relies upon kernel interfaces not changing vs .21 and it's not .22 either yet.
I just want no special Fedora handling. Just let the Fedora kernel identify itself similar to what upstream would do, as everything else just confuses external modules and users -- the latter includes probably other Kernel developers as well, if they are not aware how Fedora versions its kernels. If seen that on LKML once or twice.
the package versioning isn't whats relevant here, it's the versioning in version.h that broken external drivers insist on comparing against instead of comparing against #defines to check for features.
Yeah, but that how life is ^w^w external module authors are.
Finally, there are cases where we'll change a prototype of a function in Fedora vs upstream when we backport something early, or develop some new feature etc, so just matching the version number isn't a panacea anyway.
Happens, we are all used to it. But that is not relevant for the discusson at hand IMHO, as that "feature" is independent of version and release in any case (e.g. it can happen to you in final or rc kernels).
CU thl
On Sun, 2007-04-29 at 15:03 +0200, Thorsten Leemhuis wrote:
In short: Kernel like for example kernel-2.6.20-1.3066.fc7 are in reality 2.6.21-rc6-git5. That's not only confusing to users, it also breaks outside kernel modules sometimes; just yesterday I saw a patch in 3rd party repo applied that did this...
+-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,21) ++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
Those issues happen when you ship a kernel which is neither 2.6.20 nor 2.6.21. They don't magically go away if you call it 2.6.21 when in fact it's only 2.6.21-rc1.
David Woodhouse schrieb:
On Sun, 2007-04-29 at 15:03 +0200, Thorsten Leemhuis wrote:
In short: Kernel like for example kernel-2.6.20-1.3066.fc7 are in reality 2.6.21-rc6-git5. That's not only confusing to users, it also breaks outside kernel modules sometimes; just yesterday I saw a patch in 3rd party repo applied that did this...
+-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,21) ++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
Those issues happen when you ship a kernel which is neither 2.6.20 nor 2.6.21. They don't magically go away if you call it 2.6.21 when in fact it's only 2.6.21-rc1.
Ehh, I'm not a kernel-developer and no real programmer at all, but I can't follow here. Can somebody be so kind and tell me what I missing here?
And sure, I fully understand that compiling a external module might break if the API that gets used changes between x, (x+1)-rc1 and (x+1). But that doesn't happen that often.
CU thl
On Mon, Apr 30, 2007 at 07:09:31PM +0200, Thorsten Leemhuis wrote:
And sure, I fully understand that compiling a external module might break if the API that gets used changes between x, (x+1)-rc1 and (x+1). But that doesn't happen that often.
Exactly the opposite, the bulk of the changes happen between x and x+1-rc1 It's neither .20, nor .21 at that point.
Dave
Dave Jones schrieb:
On Mon, Apr 30, 2007 at 07:09:31PM +0200, Thorsten Leemhuis wrote:
And sure, I fully understand that compiling a external module might break if the API that gets used changes between x, (x+1)-rc1 and (x+1). But that doesn't happen that often.
Exactly the opposite, the bulk of the changes happen between x and x+1-rc1 It's neither .20, nor .21 at that point.
Argh, my wording was bad. Sure I know that it's changing a lot between X and x+1-rc1. But it doesn't happen often that it changes twice (what was what I was up to).
To get back to the specific example to show the annoying problem of the Fedora packaging in more detail:
Download madwifi 0.93 from http://sourceforge.net/project/downloading.php?group_id=82936&use_mirror...
Extract it and run this to not get confused by a different problem: sed -i 's|COPTS+=.*-Werror||' Makefile.inc
Madwifi 0.93 includes a adjustment that was integrated weeks ago (e.g. weeks before 2.6.21 even was released) to make it compile with both 2.6.20 and 2.6.21.
See include/compat.h ; relevant part:
#include <linux/version.h> #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,21) #define ATH_REGISTER_SYSCTL_TABLE(t) register_sysctl_table(t, 1) #else #define ATH_REGISTER_SYSCTL_TABLE(t) register_sysctl_table(t) #endif
Compiling it against a recent 2.6.21 kernel from rawhide works just fine:
$ LC_ALL=C make KERNELPATH=/usr/src/kernels/2.6.21-1.3116.fc7-i686/ KERNELRELEASE=2.6.21-1.3116.fc7 UUDECODE=/usr/bin/uudecode modules Checking requirements... ok. Checking kernel configuration... ok. make -C /usr/src/kernels/2.6.21-1.3116.fc7-i686/ SUBDIRS=/home/thl/tmp/madwifi-0.9.3 modules make[1]: Entering directory `/usr/src/kernels/2.6.21-1.3116.fc7-i686' CC [M] /home/thl/tmp/madwifi-0.9.3/ath/if_ath.o
[...]
LD [M] /home/thl/tmp/madwifi-0.9.3/net80211/wlan_wep.ko CC /home/thl/tmp/madwifi-0.9.3/net80211/wlan_xauth.mod.o LD [M] /home/thl/tmp/madwifi-0.9.3/net80211/wlan_xauth.ko make[1]: Leaving directory `/usr/src/kernels/2.6.21-1.3116.fc7-i686' $ echo $? 0
Compiling it against the kernel from test4, which is nearly the same as the final 2.6.21, fails, because Fedora is playing stupid tricks with version in Makefile:
$ LC_ALL=C make KERNELPATH=/usr/src/kernels/2.6.20-1.3104.fc7-i686/ KERNELRELEASE=2.6.20-1.3104.fc7 UUDECODE=/usr/bin/uudecode modules Checking requirements... ok. Checking kernel configuration... ok. make -C /usr/src/kernels/2.6.20-1.3104.fc7-i686/ SUBDIRS=/home/thl/tmp/madwifi-0.9.3 modules make[1]: Entering directory `/usr/src/kernels/2.6.20-1.3104.fc7-i686' CC [M] /home/thl/tmp/madwifi-0.9.3/ath/if_ath.o cc1: warnings being treated as errors /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c: In function 'ath_sysctl_halparam': /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c:9315: warning: comparison of unsigned expression < 0 is always false /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c:9327: warning: comparison of unsigned expression < 0 is always false /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c:9337: warning: comparison of unsigned expression < 0 is always false /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c: In function 'ath_dynamic_sysctl_register': /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c:9600: error: too many arguments to function 'register_sysctl_table' /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c: In function 'ath_sysctl_register': /home/thl/tmp/madwifi-0.9.3/ath/if_ath.c:9754: error: too many arguments to function 'register_sysctl_table' make[3]: *** [/home/thl/tmp/madwifi-0.9.3/ath/if_ath.o] Error 1 make[2]: *** [/home/thl/tmp/madwifi-0.9.3/ath] Error 2 make[1]: *** [_module_/home/thl/tmp/madwifi-0.9.3] Error 2 make[1]: Leaving directory `/usr/src/kernels/2.6.20-1.3104.fc7-i686' make: *** [modules] Error 2
This is just annoying, makes life harder for packagers of kernel-modules in 3rd party repos and confuses users a lot. For no good reason IMHO.
CU thl
see http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=1618&sid=b96d93357... they get bugreports which are not bugs but problems caused by fedora's kernel versioning system
On Mon, 2007-04-30 at 20:58 +0200, dragoran dragoran wrote:
see http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=1618&sid=b96d93357... they get bugreports which are not bugs but problems caused by fedora's kernel versioning system
That's just the rt2x00 maintainer being a muppet.
On Mon, 2007-04-30 at 20:04 +0200, Thorsten Leemhuis wrote:
See include/compat.h ; relevant part:
#include <linux/version.h> #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,21) #define ATH_REGISTER_SYSCTL_TABLE(t) register_sysctl_table(t, 1) #else #define ATH_REGISTER_SYSCTL_TABLE(t) register_sysctl_table(t) #endif
Compiling it against a recent 2.6.21 kernel from rawhide works just fine:
I've spent a _long_ time maintaining modules outside the kernel tree; I know about compatibility hacks like this. Trust me; you have a hybrid thing which is neither 2.6.20 nor 2.6.21. Calling it "2.6.21" instead of calling it "2.6.20" doesn't actually fix any problems; it only moves them around.
David Woodhouse schrieb:
On Mon, 2007-04-30 at 20:04 +0200, Thorsten Leemhuis wrote:
See include/compat.h ; relevant part:
#include <linux/version.h> #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,21) #define ATH_REGISTER_SYSCTL_TABLE(t) register_sysctl_table(t, 1) #else #define ATH_REGISTER_SYSCTL_TABLE(t) register_sysctl_table(t) #endif
Compiling it against a recent 2.6.21 kernel from rawhide works just fine:
I've spent a _long_ time maintaining modules outside the kernel tree; I know about compatibility hacks like this. Trust me; you have a hybrid thing which is neither 2.6.20 nor 2.6.21. Calling it "2.6.21" instead of calling it "2.6.20" doesn't actually fix any problems; it only moves them around.
But calling something foo (2.6.20) if upstream calls itself bar (2.6.21) just created addition problems for Fedora users and contributors (like in this madwifi case). So why obscure the version number it? Why not follow upstream, which is afaik one of the goals of Fedora.
CU thl
On Tue, 2007-05-01 at 10:26 +0200, Thorsten Leemhuis wrote:
But calling something foo (2.6.20) if upstream calls itself bar (2.6.21) just created addition problems for Fedora users and contributors (like in this madwifi case). So why obscure the version number it? Why not follow upstream, which is afaik one of the goals of Fedora.
We can't name it like upstream -- we can't actually use the '-rc1' postfix. So whatever we'll do will have to be different from upstream. There really is little point in changing what we've been doing for years, and what people are used to.
There will _always_ be muppets out there who complain about it just because it's Fedora. And out-of-tree modules will always be painful. Screwing with nomenclature really doesn't change either of those.
David Woodhouse schrieb:
On Tue, 2007-05-01 at 10:26 +0200, Thorsten Leemhuis wrote:
But calling something foo (2.6.20) if upstream calls itself bar (2.6.21) just created addition problems for Fedora users and contributors (like in this madwifi case). So why obscure the version number it? Why not follow upstream, which is afaik one of the goals of Fedora.
We can't name it like upstream -- we can't actually use the '-rc1' postfix. So whatever we'll do will have to be different from upstream.
Sure -- all I want is to leave "VERSION = foo" in the top-level Makefile from linux unchanged. Adding other stuff like the CVS-rev (as we do already) to EXTRAVERSION is fine. Leaving "-rc1" or "-git1" in it would be nice, and is in line with our guidelines.
There really is little point in changing what we've been doing for years, and what people are used to.
"People complaining about it" and "be consistent with the guidelines" are IMHO two good reason to change it.
Nobody came up with good reasons why we are doing it like that. There was the rumor "because Linus doesn't like it" , but iirc somebody on Fudcon saying that he doesn't care. And other distros don't seem to do such stupid tricks either.
There will _always_ be muppets out there who complain about it just because it's Fedora. And out-of-tree modules will always be painful.
Agreed.
Screwing with nomenclature really doesn't change either of those.
We are screwing atm, as we change VERSION in the Makefile to be different from upstream. I want us stop screwing, as that makes life harder for users and kmod packagers.
CU thl
I'd like to put a old but still valid discussion on the table again where a solution never was found: Pre-release kernel versioning.
Yes, please, and the solution is to handle the kernel rpm just like any other prerelease package. There is no reason not to adhear with the guidelines while at the same time easing life on oot modules.
Sure, 2.6.35-rc1 is neither 2.6.34, nor 2.6.35, but the rc1 is typically already that much close to the final release API-wise that you will have lot less build failures and required patchwork.
kernel-2.6.22-1.3200.fc7.rc2.git15
Or even better since the extra version parts are supposed to come before the disttag:
kernel-2.6.22-1.rc2.git15.fc7
If the next package contains an upstream change (rc2.git16, rc3 etc) then continue with 2.6.22-1.rc..., if it is a golden release, just go 2.6.22-2.fc7, and if it is a patch/specfile change only, then also upper the buildid.
kernel@lists.fedoraproject.org
-
Axel Thimm -
Dave Jones -
David Woodhouse -
drago01 -
Josh Boyer -
Thorsten Leemhuis -
Tom Callaway