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
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
* Justin M. Forbes ([email protected]) 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
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 <[email protected]>
SUSE Labs, SUSE LINUX GMBH
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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
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