* Appending '+' to version, since 2.6.35-rc2
@ 2010-06-13 19:01 Mark Hills
2010-06-14 6:52 ` Alexey Dobriyan
2010-06-15 13:48 ` Benny Halevy
0 siblings, 2 replies; 4+ messages in thread
From: Mark Hills @ 2010-06-13 19:01 UTC (permalink / raw)
To: linux-kernel; +Cc: David Rientjes, Michal Marek
Commit 85a256d adds a new feature:
[...] When CONFIG_LOCALVERSION_AUTO is not enabled, a `+' is appended
to the kernel version to represent that the kernel has been revised
since the last release unless "make LOCALVERSION=" was used to uniquely
identify the build.
I'm finding this inconvenient for 'casual' kernel development.
For example, my usual workflow goes something like:
1) find something I suspect is a bug
2) upgrade to the latest stable or -rc kernel, to confirm
3) experiment with patch to fix it
Since 2.6.35-rc2, going from step 2 to 3 causes the version of the kernel
to change: forcing time-consuming rebuilds, installing modules, and manual
changes associated with a new version number; eg. updating the lilo/grub
config, or the distribution's initrd.
Whilst I can understand the motivation for the '+' being mandatory, the
added stages above unnecessarily raise the bar for casual developers, or
other people who need to 'dip' into the kernel and test patches. These
people are least likely to be aware of using LOCALVERSION to override it
too.
May I suggest that this particular part of the commit be reverted (example
below)? In favour of a user, if they wish, explicitly setting LOCALVERSION
or using CONFIG_LOCALVERSION_AUTO.
--
Mark
From: Mark Hills <mark@pogo.org.uk>
Date: Sun, 13 Jun 2010 19:16:55 +0100
Subject: [PATCH] kbuild: Do not append mandatory '+' to kernel release
Signed-off-by: Mark Hills <mark@pogo.org.uk>
---
Makefile | 14 --------------
1 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/Makefile b/Makefile
index d49d96c..6870f6f 100644
--- a/Makefile
+++ b/Makefile
@@ -909,14 +909,6 @@ $(vmlinux-dirs): prepare scripts
# $(scm-identifier) (unique SCM tag, if one exists)
# ./scripts/setlocalversion (only with CONFIG_LOCALVERSION_AUTO)
# .scmversion (only with CONFIG_LOCALVERSION_AUTO)
-# + (only without CONFIG_LOCALVERSION_AUTO
-# and without LOCALVERSION= and
-# repository is at non-tagged commit)
-#
-# For kernels without CONFIG_LOCALVERSION_AUTO compiled from an SCM that has
-# been revised beyond a tagged commit, `+' is appended to the version string
-# when not overridden by using "make LOCALVERSION=". This indicates that the
-# kernel is not a vanilla release version and has been modified.
pattern = ".*/localversion[^~]*"
string = $(shell cat /dev/null \
@@ -942,12 +934,6 @@ endif
ifdef CONFIG_LOCALVERSION_AUTO
localver-extra = $(scm-identifier)
-else
- ifneq ($(scm-identifier),)
- ifeq ($(LOCALVERSION),)
- localver-extra = +
- endif
- endif
endif
localver-full = $(localver)$(LOCALVERSION)$(localver-extra)
--
1.7.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: Appending '+' to version, since 2.6.35-rc2
2010-06-13 19:01 Appending '+' to version, since 2.6.35-rc2 Mark Hills
@ 2010-06-14 6:52 ` Alexey Dobriyan
2010-06-14 7:38 ` Mark Hills
2010-06-15 13:48 ` Benny Halevy
1 sibling, 1 reply; 4+ messages in thread
From: Alexey Dobriyan @ 2010-06-14 6:52 UTC (permalink / raw)
To: Mark Hills; +Cc: linux-kernel, David Rientjes, Michal Marek
On Sun, Jun 13, 2010 at 08:01:26PM +0100, Mark Hills wrote:
> Commit 85a256d adds a new feature:
>
> [...] When CONFIG_LOCALVERSION_AUTO is not enabled, a `+' is appended
> to the kernel version to represent that the kernel has been revised
> since the last release unless "make LOCALVERSION=" was used to uniquely
> identify the build.
>
> I'm finding this inconvenient for 'casual' kernel development.
>
> For example, my usual workflow goes something like:
>
> 1) find something I suspect is a bug
> 2) upgrade to the latest stable or -rc kernel, to confirm
> 3) experiment with patch to fix it
>
> Since 2.6.35-rc2, going from step 2 to 3 causes the version of the kernel
> to change: forcing time-consuming rebuilds,
init/version.c
kernel/configs.c
+ whatever patch has changed
+ vmlinux 2 or 3 times
That's not time consuming.
> installing modules, and manual
> changes associated with a new version number; eg. updating the lilo/grub
> config, or the distribution's initrd.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Appending '+' to version, since 2.6.35-rc2
2010-06-14 6:52 ` Alexey Dobriyan
@ 2010-06-14 7:38 ` Mark Hills
0 siblings, 0 replies; 4+ messages in thread
From: Mark Hills @ 2010-06-14 7:38 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: linux-kernel, David Rientjes, Michal Marek
On Mon, 14 Jun 2010, Alexey Dobriyan wrote:
> On Sun, Jun 13, 2010 at 08:01:26PM +0100, Mark Hills wrote:
> > Commit 85a256d adds a new feature:
> >
> > [...] When CONFIG_LOCALVERSION_AUTO is not enabled, a `+' is appended
> > to the kernel version to represent that the kernel has been revised
> > since the last release unless "make LOCALVERSION=" was used to uniquely
> > identify the build.
> >
> > I'm finding this inconvenient for 'casual' kernel development.
> >
> > For example, my usual workflow goes something like:
> >
> > 1) find something I suspect is a bug
> > 2) upgrade to the latest stable or -rc kernel, to confirm
> > 3) experiment with patch to fix it
> >
> > Since 2.6.35-rc2, going from step 2 to 3 causes the version of the kernel
> > to change: forcing time-consuming rebuilds,
>
> init/version.c
> kernel/configs.c
> + whatever patch has changed
> + vmlinux 2 or 3 times
>
> That's not time consuming.
There is also the modpost step, which is most time consuming.
>
> > installing modules, and manual
> > changes associated with a new version number; eg. updating the lilo/grub
> > config, or the distribution's initrd.
>
--
Mark
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Appending '+' to version, since 2.6.35-rc2
2010-06-13 19:01 Appending '+' to version, since 2.6.35-rc2 Mark Hills
2010-06-14 6:52 ` Alexey Dobriyan
@ 2010-06-15 13:48 ` Benny Halevy
1 sibling, 0 replies; 4+ messages in thread
From: Benny Halevy @ 2010-06-15 13:48 UTC (permalink / raw)
To: Mark Hills; +Cc: linux-kernel, David Rientjes, Michal Marek
On Jun. 13, 2010, 15:01 -0400, Mark Hills <mark@pogo.org.uk> wrote:
> Commit 85a256d adds a new feature:
>
> [...] When CONFIG_LOCALVERSION_AUTO is not enabled, a `+' is appended
> to the kernel version to represent that the kernel has been revised
> since the last release unless "make LOCALVERSION=" was used to uniquely
> identify the build.
>
> I'm finding this inconvenient for 'casual' kernel development.
>
> For example, my usual workflow goes something like:
>
FWIW, I agree with this.
If I wanted a version suffix of this sort I'd just use CONFIG_LOCALVERSION_AUTO.
Benny
> 1) find something I suspect is a bug
> 2) upgrade to the latest stable or -rc kernel, to confirm
> 3) experiment with patch to fix it
>
> Since 2.6.35-rc2, going from step 2 to 3 causes the version of the kernel
> to change: forcing time-consuming rebuilds, installing modules, and manual
> changes associated with a new version number; eg. updating the lilo/grub
> config, or the distribution's initrd.
>
> Whilst I can understand the motivation for the '+' being mandatory, the
> added stages above unnecessarily raise the bar for casual developers, or
> other people who need to 'dip' into the kernel and test patches. These
> people are least likely to be aware of using LOCALVERSION to override it
> too.
>
> May I suggest that this particular part of the commit be reverted (example
> below)? In favour of a user, if they wish, explicitly setting LOCALVERSION
> or using CONFIG_LOCALVERSION_AUTO.
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-06-15 13:48 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-13 19:01 Appending '+' to version, since 2.6.35-rc2 Mark Hills
2010-06-14 6:52 ` Alexey Dobriyan
2010-06-14 7:38 ` Mark Hills
2010-06-15 13:48 ` Benny Halevy
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.