2.6.Stable and EXTRAVERSION

2.6.Stable and EXTRAVERSION

[Justin M. Forbes]

With the new stable series kernels, the .x versioning is being added to
EXTRAVERSION.  This has traditionally been a space for local modification.
I know several distributions are using EXTRAVERSION for build numbers,
platform and assorted other information to differentiate their kernel
releases.
I would propose that the new stable series kernels move the .x version
information somewhere more official.  I certainly do not mind throwing
together a patch to support DOTVERSION or what ever people want to call it.
Is anyone opposed to such a change?

Thanks,
Justin M. Forbes

Re: 2.6.Stable and EXTRAVERSION

[Chris Friesen]

Justin M. Forbes wrote:
> With the new stable series kernels, the .x versioning is being added to
> EXTRAVERSION.  This has traditionally been a space for local modification.
> I know several distributions are using EXTRAVERSION for build numbers,
> platform and assorted other information to differentiate their kernel
> releases.
> I would propose that the new stable series kernels move the .x version
> information somewhere more official.  I certainly do not mind throwing
> together a patch to support DOTVERSION or what ever people want to call it.
> Is anyone opposed to such a change?

Distros could conceivably use CONFIG_LOCALVERSION, although it might be 
cleaner to add another version level.

Chris

Re: 2.6.Stable and EXTRAVERSION

[Chris Wright]

* Justin M. Forbes (jmforbes@linuxtx.org) wrote:
> With the new stable series kernels, the .x versioning is being added to
> EXTRAVERSION.  This has traditionally been a space for local modification.
> I know several distributions are using EXTRAVERSION for build numbers,
> platform and assorted other information to differentiate their kernel
> releases.

Well, it is the same scheme Linus used with 2.6.8.1...Is it posing a
real issue?

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: 2.6.Stable and EXTRAVERSION

[Andreas Gruenbacher]

On Wed, 2005-03-09 at 19:53, Justin M. Forbes wrote:
> With the new stable series kernels, the .x versioning is being added to
> EXTRAVERSION.  This has traditionally been a space for local modification.
> I know several distributions are using EXTRAVERSION for build numbers,
> platform and assorted other information to differentiate their kernel
> releases.

It's no issue for us. We're using this patch to add in the RPM release
number:

Index: linux-2.6.10/Makefile
===================================================================
--- linux-2.6.10.orig/Makefile
+++ linux-2.6.10/Makefile
@@ -158,8 +158,11 @@ endif
 LOCALVERSION = $(subst $(space),, \
 	       $(shell cat /dev/null $(localversion-files:%~=)) \
 	       $(patsubst "%",%,$(CONFIG_LOCALVERSION)))
+ifneq ($(wildcard $(srctree)/rpm-release),)
+RPM_RELEASE := -$(shell cat $(srctree)/rpm-release)
+endif
 
-KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(LOCALVERSION)
+KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(RPM_RELEASE)$(LOCALVERSION)
 
 # SUBARCH tells the usermode build what the underlying arch is.  That is set
 # first, and if a usermode build is happening, the "ARCH=um" on the command


Cheers,
-- 
Andreas Gruenbacher <agruen@suse.de>
SUSE Labs, SUSE LINUX GMBH

Re: 2.6.Stable and EXTRAVERSION

[Bill Davidsen]

Justin M. Forbes wrote:
> With the new stable series kernels, the .x versioning is being added to
> EXTRAVERSION.  This has traditionally been a space for local modification.
> I know several distributions are using EXTRAVERSION for build numbers,
> platform and assorted other information to differentiate their kernel
> releases.
> I would propose that the new stable series kernels move the .x version
> information somewhere more official.  I certainly do not mind throwing
> together a patch to support DOTVERSION or what ever people want to call it.
> Is anyone opposed to such a change?

I think it will confuse scripts which expect something local in the 4th 
field. I confess that I have such, and that field is turned into a 
directory name during builds, so test results are saved in a proper 
place. I think vendors and people who care will just keep three digits, 
and those who want the last can make their EXTRAVERSION
    2.Joes_Bar_&_Grill_486
or whatever is needed.

Add to that the confusion of having mainline releases
   2.6.x.LOCAL
and stable be
   2.6.x.y.LOCAL
and you really make work for people who do things with scripts. This is 
probably not an issue for humans, and people could program around it, 
but I think it's a solution to a non-problem. Vendors will have the 
-stable and their own patches, so they probably will only keep three 
fields anyway.

And don't even suggest tell Linus to start calling mainline releases 
2.6.x.0 because that would probably break even more things.

Leave well enough alone!

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: 2.6.Stable and EXTRAVERSION

[Bill Davidsen]

On Fri, 11 Mar 2005, Chris Friesen wrote:

> Bill Davidsen wrote:

	[...snip...]

> > I think it will confuse scripts which expect something local in the 4th 
> > field. I confess that I have such, and that field is turned into a 
> > directory name during builds, so test results are saved in a proper 
> > place. I think vendors and people who care will just keep three digits, 
> > and those who want the last can make their EXTRAVERSION
> >    2.Joes_Bar_&_Grill_486
> > or whatever is needed.
> 
> There's also the LOCALVERSION that can be set in the config file.  I've 
> switched to using that, since it means one less kernel patch to port.

I have to see what that generates. The problem is LOCALVERSION and current
use of both 3 and 4 field kernel versions. You need a smarter script to
handle that.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: 2.6.Stable and EXTRAVERSION

[Chris Friesen]

Bill Davidsen wrote:
> Justin M. Forbes wrote:
> 
>> With the new stable series kernels, the .x versioning is being added to
>> EXTRAVERSION.  This has traditionally been a space for local 
>> modification.
>> I know several distributions are using EXTRAVERSION for build numbers,
>> platform and assorted other information to differentiate their kernel
>> releases.
>> I would propose that the new stable series kernels move the .x version
>> information somewhere more official.  I certainly do not mind throwing
>> together a patch to support DOTVERSION or what ever people want to 
>> call it.
>> Is anyone opposed to such a change?
> 
> 
> I think it will confuse scripts which expect something local in the 4th 
> field. I confess that I have such, and that field is turned into a 
> directory name during builds, so test results are saved in a proper 
> place. I think vendors and people who care will just keep three digits, 
> and those who want the last can make their EXTRAVERSION
>    2.Joes_Bar_&_Grill_486
> or whatever is needed.

There's also the LOCALVERSION that can be set in the config file.  I've 
switched to using that, since it means one less kernel patch to port.

Chris

Re: 2.6.Stable and EXTRAVERSION

[Sam Ravnborg]

On Thu, Mar 10, 2005 at 09:25:54AM +0100, Andreas Gruenbacher wrote:
> On Wed, 2005-03-09 at 19:53, Justin M. Forbes wrote:
> > With the new stable series kernels, the .x versioning is being added to
> > EXTRAVERSION.  This has traditionally been a space for local modification.
> > I know several distributions are using EXTRAVERSION for build numbers,
> > platform and assorted other information to differentiate their kernel
> > releases.
> 
> It's no issue for us. We're using this patch to add in the RPM release
> number:
> 
> Index: linux-2.6.10/Makefile
> ===================================================================
> --- linux-2.6.10.orig/Makefile
> +++ linux-2.6.10/Makefile
> @@ -158,8 +158,11 @@ endif
>  LOCALVERSION = $(subst $(space),, \
>  	       $(shell cat /dev/null $(localversion-files:%~=)) \
>  	       $(patsubst "%",%,$(CONFIG_LOCALVERSION)))
> +ifneq ($(wildcard $(srctree)/rpm-release),)
> +RPM_RELEASE := -$(shell cat $(srctree)/rpm-release)
> +endif
>  
> -KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(LOCALVERSION)
> +KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(RPM_RELEASE)$(LOCALVERSION)
>  
>  # SUBARCH tells the usermode build what the underlying arch is.  That is set
>  # first, and if a usermode build is happening, the "ARCH=um" on the command

Naming your rpm-release file: localversion00-rpm would do the same
without the need to patch the kernel.

	Sam

Re: 2.6.Stable and EXTRAVERSION

[Matan Peled]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

Bill Davidsen wrote:
> I have to see what that generates. The problem is LOCALVERSION and current
> use of both 3 and 4 field kernel versions. You need a smarter script to
> handle that.
> 

... To which the knee jerk solution would be ...

Name Linus's kernel releases 2.6.z.0 ... ?


-- 
[Name      ]   ::  [Matan I. Peled    ]
[Location  ]   ::  [Israel            ]
[Public Key]   ::  [0xD6F42CA5        ]
[Keyserver ]   ::  [keyserver.kjsl.com]
encrypted/signed  plain text  preferred


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]