* Re: Linux 2.6.32-rc3
2009-10-06 16:31 ` Linus Torvalds
@ 2009-10-06 16:40 ` Ingo Molnar
2009-10-06 18:12 ` Theodore Tso
2009-10-06 17:15 ` Stefan Richter
` (5 subsequent siblings)
6 siblings, 1 reply; 131+ messages in thread
From: Ingo Molnar @ 2009-10-06 16:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dirk Hohndel, Len Brown, Linux Kernel Mailing List
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, 6 Oct 2009, Linus Torvalds wrote:
> >
> > Unless:
> >
> > > _That_ i think is a lot harder to confuse with the real .31 than a
> > > v2.6.31-1234-g16123c4 version string.
> >
> > .. are you saying that it would be just some automatically generated
> > thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a
> > CONFIG_LOCALVERSION_AUTO_SHORTFORM?
>
> So how about this?
>
> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> way:
>
> - if it is set, things work the way they always have, and you get a
> extended kernel release like
>
> 2.6.32-rc3-00052-g0eca52a-dirty
>
> - but if it is _not_ set, we'll still try to get a version from the
> underlying SCM (we actually support git, hg and SVN right now, even if
> some comments may say "git only"), and if the underlying SCM says it
> has a local version, we append just "+", so you get a version number
> like
>
> 2.6.32-rc3+
>
> IOW, you'd never get 2.6.32-rc0, but you'd get either the complex git
> version number (or SVN/hg/whatever), or at least "2.6.31+" with the "+"
> showing that it is more than plain 2.6.31.
>
> The "+" could be anything else, of course. The diff is pretty obvious,
> you can argue about exactly _what_ you'd like to see as a suffix for
> "and then some".
Could we, for consistency's sake, make it:
2.6.32-rc3+00052-g0eca52a-dirty
2.6.32-rc3+
? Or do we want to keep the old version string alone for some reason?
The reason is that i have been confused in the past by having seen
something like:
2.6.29-00052-g0eca52a-dirty
and parsing out (in an admittedly weak moment) the gibberish after the
first dash. Had it said:
2.6.29+00052-g0eca52a-dirty
i'm sure i'd have noticed that it's not vanilla v2.6.29 - that plus sign
stands out like a lightning rod.
Ingo
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 16:40 ` Ingo Molnar
@ 2009-10-06 18:12 ` Theodore Tso
2009-10-06 18:24 ` Ingo Molnar
0 siblings, 1 reply; 131+ messages in thread
From: Theodore Tso @ 2009-10-06 18:12 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On Tue, Oct 06, 2009 at 06:40:28PM +0200, Ingo Molnar wrote:
>
> Could we, for consistency's sake, make it:
>
> 2.6.32-rc3+00052-g0eca52a-dirty
> 2.6.32-rc3+
>
> ? Or do we want to keep the old version string alone for some reason?
I'm a bit concerned that changing from what we've currently had:
> 2.6.29-00052-g0eca52a-dirty
might break some packaging scripts. I'm also personally used to that
naming scheme; in fact at the moment I'm using
2.6.32-rc1-00292-gb0390e2. :-)
- Ted
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 18:12 ` Theodore Tso
@ 2009-10-06 18:24 ` Ingo Molnar
2009-10-06 21:19 ` Stefan Richter
0 siblings, 1 reply; 131+ messages in thread
From: Ingo Molnar @ 2009-10-06 18:24 UTC (permalink / raw)
To: Theodore Tso, Linus Torvalds, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
* Theodore Tso <tytso@mit.edu> wrote:
> On Tue, Oct 06, 2009 at 06:40:28PM +0200, Ingo Molnar wrote:
> >
> > Could we, for consistency's sake, make it:
> >
> > 2.6.32-rc3+00052-g0eca52a-dirty
> > 2.6.32-rc3+
> >
> > ? Or do we want to keep the old version string alone for some reason?
>
> I'm a bit concerned that changing from what we've currently had:
>
> > 2.6.29-00052-g0eca52a-dirty
>
> might break some packaging scripts. [...]
( Sidenote: such scripts might as well need fixing then, even without
any upstream changes - adding a localversion file to the top level
directory (which many out of tree projects do) would possibly break
them as well. )
> [...] I'm also personally used to that naming scheme; in fact at the
> moment I'm using 2.6.32-rc1-00292-gb0390e2. :-)
Yeah, i'm pretty happy with auto-localversion as well and use it
everywhere. What i suggested is a small tweak to that: to make it more
clear what people get during the merge window - when the string says
"2.6.31-00292-gb0390e2". Plus a small tweak to the non-auto-localversion
naming: to make the uname output more clear when people disable the
auto-localversion option:
Linux europe 2.6.31+ #2 SMP Tue Oct 6 19:26:58 CEST 2009 i686 i686 i386 GNU/Linux
versus the inaccurate:
Linux europe 2.6.31 #2 SMP Tue Oct 6 19:26:58 CEST 2009 i686 i686 i386 GNU/Linux
string which we emit today.
Ingo
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 18:24 ` Ingo Molnar
@ 2009-10-06 21:19 ` Stefan Richter
0 siblings, 0 replies; 131+ messages in thread
From: Stefan Richter @ 2009-10-06 21:19 UTC (permalink / raw)
To: Ingo Molnar
Cc: Theodore Tso, Linus Torvalds, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
Ingo Molnar wrote:
[...]
> Linux europe 2.6.31+ #2 SMP Tue Oct 6 19:26:58 CEST 2009 i686 i686 i386 GNU/Linux
>
> versus the inaccurate:
>
> Linux europe 2.6.31 #2 SMP Tue Oct 6 19:26:58 CEST 2009 i686 i686 i386 GNU/Linux
>
> string which we emit today.
It's not the string which is inaccurate. To assume that the version
string which is embedded into the kernel image fully describes the
kernel is inaccurate. :-) The + suffix is an improvement in the sense
that it asserts that this kernel is not of a specific version...
--
Stefan Richter
-=====-==--= =-=- --==-
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 16:31 ` Linus Torvalds
2009-10-06 16:40 ` Ingo Molnar
@ 2009-10-06 17:15 ` Stefan Richter
2009-10-06 18:16 ` Ingo Molnar
2009-10-06 17:22 ` Frans Pop
` (4 subsequent siblings)
6 siblings, 1 reply; 131+ messages in thread
From: Stefan Richter @ 2009-10-06 17:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ingo Molnar, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
Linus Torvalds wrote:
> So how about this?
>
> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> way:
>
> - if it is set, things work the way they always have, and you get a
> extended kernel release like
>
> 2.6.32-rc3-00052-g0eca52a-dirty
>
> - but if it is _not_ set,
[...]
> we append just "+", so you get a version number like
>
> 2.6.32-rc3+
[...]
> The "+" could be anything else, of course. The diff is pretty obvious, you
> can argue about exactly _what_ you'd like to see as a suffix for "and then
> some".
The "+" suffix is already in informal use with a different meaning.
It's customary to write "For feature XY, you need kernel 2.6.31+" as a
shorthand for "kernel 2.6.31 or any later release".
--
Stefan Richter
-=====-==--= =-=- --==-
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 17:15 ` Stefan Richter
@ 2009-10-06 18:16 ` Ingo Molnar
0 siblings, 0 replies; 131+ messages in thread
From: Ingo Molnar @ 2009-10-06 18:16 UTC (permalink / raw)
To: Stefan Richter
Cc: Linus Torvalds, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
* Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> Linus Torvalds wrote:
> > So how about this?
> >
> > It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> > way:
> >
> > - if it is set, things work the way they always have, and you get a
> > extended kernel release like
> >
> > 2.6.32-rc3-00052-g0eca52a-dirty
> >
> > - but if it is _not_ set,
> [...]
> > we append just "+", so you get a version number like
> >
> > 2.6.32-rc3+
> [...]
> > The "+" could be anything else, of course. The diff is pretty obvious, you
> > can argue about exactly _what_ you'd like to see as a suffix for "and then
> > some".
>
> The "+" suffix is already in informal use with a different meaning.
> It's customary to write "For feature XY, you need kernel 2.6.31+" as a
> shorthand for "kernel 2.6.31 or any later release".
'+' is also informally used to denote addition and a whole ton of other
things. (and likewise all other ASCII characters)
The primary context in where it's used, uname output and "I used kernel
v2.6.31+" statements is pretty unambigous i think.
Ingo
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 16:31 ` Linus Torvalds
2009-10-06 16:40 ` Ingo Molnar
2009-10-06 17:15 ` Stefan Richter
@ 2009-10-06 17:22 ` Frans Pop
2009-10-06 17:32 ` Linus Torvalds
2009-10-06 17:35 ` [patch] kbuild: Improve version string logic Ingo Molnar
` (3 subsequent siblings)
6 siblings, 1 reply; 131+ messages in thread
From: Frans Pop @ 2009-10-06 17:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: mingo, hohndel, linux-kernel
Linus Torvalds wrote:
> - but if it is _not_ set, we'll still try to get a version from the
> underlying SCM (we actually support git, hg and SVN right now, even if
> some comments may say "git only"), and if the underlying SCM says it
> has a local version, we append just "+", so you get a version number
> like
>
> 2.6.32-rc3+
Doesn't this leave users of the git snapshot tarballs in the cold?
That seems a serious disadvantage as different users will get different
versions (and thus report different versions in bug reports).
The advantage of an -rc0 in the Makefile is that everybody gets it.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 17:22 ` Frans Pop
@ 2009-10-06 17:32 ` Linus Torvalds
2009-10-06 18:29 ` Frans Pop
0 siblings, 1 reply; 131+ messages in thread
From: Linus Torvalds @ 2009-10-06 17:32 UTC (permalink / raw)
To: Frans Pop; +Cc: mingo, hohndel, linux-kernel
On Tue, 6 Oct 2009, Frans Pop wrote:
>
> Doesn't this leave users of the git snapshot tarballs in the cold?
You can save it in .scmversion if you want to, we've supported that as a
"export versions outside of the SCM" way since introducing
LOCALVERSION_AUTO.
> The advantage of an -rc0 in the Makefile is that everybody gets it.
Have you missed the whole discussion about why it doesn't work?
Have you missed the point on why it is FUNDAMENTALLY WRONG to do?
You also seem to be making up more and more ludicrous examples of things
to do. Why the f*ck cares about somebody taking a random git tree, tarring
it up, and then building it like that?
I mean really.
Linus
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 17:32 ` Linus Torvalds
@ 2009-10-06 18:29 ` Frans Pop
2009-10-07 0:51 ` Florian Mickler
0 siblings, 1 reply; 131+ messages in thread
From: Frans Pop @ 2009-10-06 18:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: mingo, hohndel, linux-kernel
On Tuesday 06 October 2009, Linus Torvalds wrote:
> Have you missed the whole discussion about why it doesn't work?
> Have you missed the point on why it is FUNDAMENTALLY WRONG to do?
No, I've followed the discussion. I guess I just disagree with you as my
perspective is different. I still think there are practical advantages to
it, even if it is not 100% theoretically correct from a versioning PoV
(which I've already said I agree with).
> You also seem to be making up more and more ludicrous examples of things
> to do.
Those ludicrous examples work very well for me and keep mixtures of stable,
development and bisection kernels on 6 different architectures manageable.
Call me weird.
I was not proposing my scheme as a general solution, but just presenting it
as an example of what can be done locally.
Anyway, as long as I can continue to follow my own scheme, I'm happy
enough.
> Why the f*ck cares about somebody taking a random git tree, tarring it
> up, and then building it like that?
Because they are not random. I build inbetween trees mostly when I see that
fixes for issues I've seen have been merged. My method, making use of the
possibilities of the distro package management system, gives me perfect
version management for these kernels. And that is something, I do care
about (for my own systems, not as something to force on others).
Cheers,
FJP
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 18:29 ` Frans Pop
@ 2009-10-07 0:51 ` Florian Mickler
0 siblings, 0 replies; 131+ messages in thread
From: Florian Mickler @ 2009-10-07 0:51 UTC (permalink / raw)
To: Frans Pop; +Cc: linux-kernel, mingo, hohndel, Linus Torvalds
On Tue, 6 Oct 2009 20:29:08 +0200
Frans Pop <elendil@planet.nl> wrote:
> On Tuesday 06 October 2009, Linus Torvalds wrote:
> > Have you missed the whole discussion about why it doesn't work?
> > Have you missed the point on why it is FUNDAMENTALLY WRONG to do?
>
> No, I've followed the discussion. I guess I just disagree with you as my
> perspective is different. I still think there are practical advantages to
> it, even if it is not 100% theoretically correct from a versioning PoV
> (which I've already said I agree with).
We shouldn't try to weaken the version-numbering-scheme
more. And every action which only 'suggests' that the version-number
has more weight, than it actually has is just papering over the real
bug.
It works if you are only some bird sitting at
one branch of the kernel-development-tree (the git DAG, that is)
looking at what he thinks is the tip of the tree.
But this scheme does not work in the 'decentralised' kernel-scenario.
Because if only one subsystem-maintainer forgets to 'put the zero' into
his branch, anybody who tries that branch is at the same situation
as before. So it would be useless for any 'colaboration based effort'.
Nice to have as a bird, but as a ranger you can't expect every tree to
have a tip. ( actually you can .. note to self: ... i'm getting
confused in this alegory... whatever... just relax, refocus and go
on.. )
On the other hand, if you could modify the DNA of the trees to make
them
a) better, so they prevail and other trees extinguish over time and
b) have him grow 'pluses' at the tip (or whatever distinguishing
feature a released tree exhibits ) the ranger could then wander through
the forest and just look for pluses to do, whatever he needs to do
with those branches.. aerm trees ... ah whatever.
i hope you are not lost in the woods, and to sumarize: i've no business
whatsoever in the linux-kernel, but read lkml instead of doing smth
useful. ah, and i think a change in the build-mechanics to distinguish
releases is the way to go, instead of a commit.
but the problem you noted with the 'export' from git into the ''real
world'' is of course there.
maybe there is a solution to this? eventually smth like "if you don't
use git you have to always tell the truth? or any other way to
'dirty' the makefile at export-time ? in-kernel boot-time checksumming
of the kernel-image? to get at least uname -r right?
dunno,
Florian
--
A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
>> A: Top-posting.
>>> Q: What is the most annoying thing in e-mail?
^ permalink raw reply [flat|nested] 131+ messages in thread
* [patch] kbuild: Improve version string logic
2009-10-06 16:31 ` Linus Torvalds
` (2 preceding siblings ...)
2009-10-06 17:22 ` Frans Pop
@ 2009-10-06 17:35 ` Ingo Molnar
2009-10-06 18:37 ` Johannes Berg
` (2 more replies)
2009-10-06 17:40 ` Linux 2.6.32-rc3 Len Brown
` (2 subsequent siblings)
6 siblings, 3 replies; 131+ messages in thread
From: Ingo Molnar @ 2009-10-06 17:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dirk Hohndel, Len Brown, Linux Kernel Mailing List
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, 6 Oct 2009, Linus Torvalds wrote:
> >
> > Unless:
> >
> > > _That_ i think is a lot harder to confuse with the real .31 than a
> > > v2.6.31-1234-g16123c4 version string.
> >
> > .. are you saying that it would be just some automatically generated
> > thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a
> > CONFIG_LOCALVERSION_AUTO_SHORTFORM?
>
> So how about this?
this patch is great IMHO. I've modified it to propagate the '+' into the
long version string as well. I've tested it with auto-version not set
and it now gives:
Linux europe 2.6.32-rc3+ #2 SMP Tue Oct 6 19:26:58 CEST 2009 i686 i686 i386 GNU/Linux
the -rc3+ is a clearly visible distinction. This will improve things
when bugs are reported with LOCALVERSION_AUTO not set - we'll always
know when a tree is not vanilla.
With autoversion set 'uname -a' gives:
Linux europe 2.6.32-rc3+00052-g0eca52a-dirty #3 SMP Tue Oct 6 19:29:54 CEST 2009 i686 i686 i386 GNU/Linux
IMO that's intuitive too. We get whatever is described in the
localversion in addition to the tag. The '+' clearly signals that 'set
union' operation we've done.
So this patch solves all the problems i had with our versioning. I've
attached it below with a changelog.
Thanks,
Ingo
--------------->
Subject: kbuild: Improve version string logic
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 6 Oct 2009 09:31:03 -0700 (PDT)
It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
way:
- if it is set, things work the way they always have, and you get a
extended kernel release like:
2.6.32-rc3+00052-g0eca52a-dirty
( with the difference that the extra version string is separated via
'+' not via '-'. This improves visibility when we have additional
changes over a vanilla tag. )
- but if it is _not_ set, we'll still try to get a version from the
underlying SCM (we actually support git, hg and SVN right now, even if
some comments may say "git only"), and if the underlying SCM says it
has a local version, we append just "+", so you get a version number
like:
2.6.32-rc3+
IOW, you'd never get 2.6.32-rc0, but you'd get either the complex git
version number (or SVN/hg/whatever), or at least "2.6.31+" with the "+"
showing that it is more than plain 2.6.31.
The "+" could be anything else, of course. The diff is pretty obvious, you
can argue about exactly _what_ you'd like to see as a suffix for "and then
some".
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
Makefile | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
Index: linux/Makefile
===================================================================
--- linux.orig/Makefile
+++ linux/Makefile
@@ -963,16 +963,21 @@ localver = $(subst $(space),, $(string)
# .scmversion is used when generating rpm packages so we do not loose
# the version information from the SCM when we do the build of the kernel
# from the copied source
-ifdef CONFIG_LOCALVERSION_AUTO
-
ifeq ($(wildcard .scmversion),)
_localver-auto = $(shell $(CONFIG_SHELL) \
- $(srctree)/scripts/setlocalversion $(srctree))
+ $(srctree)/scripts/setlocalversion $(srctree) | sed 's/^-/+/')
else
_localver-auto = $(shell cat .scmversion 2> /dev/null)
endif
+ifdef CONFIG_LOCALVERSION_AUTO
localver-auto = $(LOCALVERSION)$(_localver-auto)
+else
+ ifeq ($_localver-auto,)
+ localver-auto = $(LOCALVERSION)
+ else
+ localver-auto = $(LOCALVERSION)+
+ endif
endif
localver-full = $(localver)$(localver-auto)
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 17:35 ` [patch] kbuild: Improve version string logic Ingo Molnar
@ 2009-10-06 18:37 ` Johannes Berg
2009-10-06 18:49 ` Ingo Molnar
` (2 more replies)
2009-10-07 2:43 ` David Rientjes
2009-10-12 19:57 ` [PATCH, v2] " Ingo Molnar
2 siblings, 3 replies; 131+ messages in thread
From: Johannes Berg @ 2009-10-06 18:37 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 935 bytes --]
On Tue, 2009-10-06 at 19:35 +0200, Ingo Molnar wrote:
> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> way:
>
> - if it is set, things work the way they always have, and you get a
> extended kernel release like:
>
> 2.6.32-rc3+00052-g0eca52a-dirty
>
> ( with the difference that the extra version string is separated via
> '+' not via '-'. This improves visibility when we have additional
> changes over a vanilla tag. )
I really don't see how it improves visibility (unless you're oblivious
to the difference between long and short strings), but I do know that I
have a few parsers that this will break.
I think adding the + unconditionally will also break things like
debian's make-kpkg, for instance, since the + would get propagated into
the package version which reserves the + for something else.
Etc. Can we please make this stuff optional?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 18:37 ` Johannes Berg
@ 2009-10-06 18:49 ` Ingo Molnar
2009-10-06 18:55 ` Johannes Berg
2009-10-06 19:03 ` Theodore Tso
2009-10-06 19:45 ` Frans Pop
2 siblings, 1 reply; 131+ messages in thread
From: Ingo Molnar @ 2009-10-06 18:49 UTC (permalink / raw)
To: Johannes Berg
Cc: Linus Torvalds, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
* Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2009-10-06 at 19:35 +0200, Ingo Molnar wrote:
>
> > It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> > way:
> >
> > - if it is set, things work the way they always have, and you get a
> > extended kernel release like:
> >
> > 2.6.32-rc3+00052-g0eca52a-dirty
> >
> > ( with the difference that the extra version string is separated via
> > '+' not via '-'. This improves visibility when we have additional
> > changes over a vanilla tag. )
>
> I really don't see how it improves visibility (unless you're oblivious
> to the difference between long and short strings), but I do know that
> I have a few parsers that this will break.
It improves visibility the same way the + at the end of the short
version improves visibility.
That said, i'm perfectly fine with just having the short version include
the '+' sign (i.e. Linus's original patch), that was my original
suggestion and that is already a big step forward.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 18:49 ` Ingo Molnar
@ 2009-10-06 18:55 ` Johannes Berg
0 siblings, 0 replies; 131+ messages in thread
From: Johannes Berg @ 2009-10-06 18:55 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
On Tue, 2009-10-06 at 20:49 +0200, Ingo Molnar wrote:
> That said, i'm perfectly fine with just having the short version include
> the '+' sign (i.e. Linus's original patch), that was my original
> suggestion and that is already a big step forward.
However, that still breaks current make-kpkg iirc. I haven't used it in
quite some time, so I don't particularly care.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 18:37 ` Johannes Berg
2009-10-06 18:49 ` Ingo Molnar
@ 2009-10-06 19:03 ` Theodore Tso
2009-10-06 19:45 ` Frans Pop
2 siblings, 0 replies; 131+ messages in thread
From: Theodore Tso @ 2009-10-06 19:03 UTC (permalink / raw)
To: Johannes Berg
Cc: Ingo Molnar, Linus Torvalds, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Tue, Oct 06, 2009 at 08:37:07PM +0200, Johannes Berg wrote:
>
> I really don't see how it improves visibility (unless you're oblivious
> to the difference between long and short strings), but I do know that I
> have a few parsers that this will break.
>
> I think adding the + unconditionally will also break things like
> debian's make-kpkg, for instance, since the + would get propagated into
> the package version which reserves the + for something else.
>
> Etc. Can we please make this stuff optional?
That's exactly what I'm afraid of. I'd really like to keep the long
version AUTOVERSION strings the same, please.
- Ted
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 18:37 ` Johannes Berg
2009-10-06 18:49 ` Ingo Molnar
2009-10-06 19:03 ` Theodore Tso
@ 2009-10-06 19:45 ` Frans Pop
2009-10-06 19:48 ` Johannes Berg
2 siblings, 1 reply; 131+ messages in thread
From: Frans Pop @ 2009-10-06 19:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: mingo, torvalds, hohndel, lenb, linux-kernel
Johannes Berg wrote:
> I think adding the + unconditionally will also break things like
> debian's make-kpkg, for instance, since the + would get propagated into
> the package version which reserves the + for something else.
Are you sure? AFAIK it would be propagated into the package _name_, where
it is allowed. And even if it were part of the package version, it would
be in the "upstream" part of the version number, where it is also allowed.
The only reserved use of "+" I'm aware of is in the Debian part of the
package version.
But I have not used make-kpkg in ages, so I'm not 100% sure how that builds
the package version. I could be that it duplicates the kernel version in
both the package name and the upstream part of the package version, but
that should still be OK.
Cheers,
FJP
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 19:45 ` Frans Pop
@ 2009-10-06 19:48 ` Johannes Berg
2009-10-06 20:25 ` Frans Pop
0 siblings, 1 reply; 131+ messages in thread
From: Johannes Berg @ 2009-10-06 19:48 UTC (permalink / raw)
To: Frans Pop; +Cc: mingo, torvalds, hohndel, lenb, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]
On Tue, 2009-10-06 at 21:45 +0200, Frans Pop wrote:
> Johannes Berg wrote:
> > I think adding the + unconditionally will also break things like
> > debian's make-kpkg, for instance, since the + would get propagated into
> > the package version which reserves the + for something else.
>
> Are you sure?
No, I'm not.
> AFAIK it would be propagated into the package _name_, where
> it is allowed. And even if it were part of the package version, it would
> be in the "upstream" part of the version number, where it is also allowed.
>
> The only reserved use of "+" I'm aware of is in the Debian part of the
> package version.
>
> But I have not used make-kpkg in ages, so I'm not 100% sure how that builds
> the package version. I could be that it duplicates the kernel version in
> both the package name and the upstream part of the package version, but
> that should still be OK.
That may all well be true. I wasn't even aware of the distinction
between debian and upstream part of the version :)
I do, however, remember no end to trouble with autoversion and make-kpkg
so eventually gave up on using it entirely.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 19:48 ` Johannes Berg
@ 2009-10-06 20:25 ` Frans Pop
0 siblings, 0 replies; 131+ messages in thread
From: Frans Pop @ 2009-10-06 20:25 UTC (permalink / raw)
To: Johannes Berg; +Cc: mingo, torvalds, hohndel, lenb, linux-kernel
This is a bit OT, but one last reply.
On Tuesday 06 October 2009, Johannes Berg wrote:
> > AFAIK it would be propagated into the package _name_, where
> > it is allowed. And even if it were part of the package version, it
> > would be in the "upstream" part of the version number, where it is
> > also allowed.
>
> That may all well be true. I wasn't even aware of the distinction
> between debian and upstream part of the version :)
The Debian part is everything after the last dash in a package version.
> I do, however, remember no end to trouble with autoversion and make-kpkg
> so eventually gave up on using it entirely.
Yes, problems with autoversion and make-kpkg I can understand as it makes
the revision ID part of the package name, which is very simply not where
you want it [1].
I stopped using make-kpkg for 2 reasons. First of all it is insanely
complex. And second it used to always do a 'make clean' for every build,
which meant a huge inefficiency during bisections and builds after minor
changes; I understand that has been fixed though.
I was happy to discover the kernel's native deb-pkg target. There've been
some improvements to that in recent kernels that make it quite powerful
and flexible for building custom kernels as Debian packages.
Cheers,
FJP
[1] The deb-pkg target does the same, so autoversion is not usable with
that either. What I do is manipulate the output of 'git describe' to set
an ENVVAR that gets used as package version.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 17:35 ` [patch] kbuild: Improve version string logic Ingo Molnar
2009-10-06 18:37 ` Johannes Berg
@ 2009-10-07 2:43 ` David Rientjes
2009-10-12 19:57 ` [PATCH, v2] " Ingo Molnar
2 siblings, 0 replies; 131+ messages in thread
From: David Rientjes @ 2009-10-07 2:43 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On Tue, 6 Oct 2009, Ingo Molnar wrote:
> Subject: kbuild: Improve version string logic
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Tue, 6 Oct 2009 09:31:03 -0700 (PDT)
>
> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> way:
>
> - if it is set, things work the way they always have, and you get a
> extended kernel release like:
>
> 2.6.32-rc3+00052-g0eca52a-dirty
>
> ( with the difference that the extra version string is separated via
> '+' not via '-'. This improves visibility when we have additional
> changes over a vanilla tag. )
>
s/changes/commits/, we'd have to look at the -dirty suffix for uncommited
changes.
The '+' doesn't necessarily always mean there are additional changes since
scripts/setlocalversion will return -00000-EXTRAVERSION when we're at a
release. So when CONFIG_LOCALVERSION_AUTO is enabled, this patch would,
for example, create the version 2.6.32-rc3+00000-rc3.
Perhaps we should suppress setlocalversion's output if git describe
doesn't have a 7-character trailing hash prefixed with 'g'?
^ permalink raw reply [flat|nested] 131+ messages in thread
* [PATCH, v2] kbuild: Improve version string logic
2009-10-06 17:35 ` [patch] kbuild: Improve version string logic Ingo Molnar
2009-10-06 18:37 ` Johannes Berg
2009-10-07 2:43 ` David Rientjes
@ 2009-10-12 19:57 ` Ingo Molnar
2009-10-12 22:04 ` Frans Pop
` (2 more replies)
2 siblings, 3 replies; 131+ messages in thread
From: Ingo Molnar @ 2009-10-12 19:57 UTC (permalink / raw)
To: Linus Torvalds, Frans Pop
Cc: Dirk Hohndel, Len Brown, Linux Kernel Mailing List
This is basically your original patch that adds '+' to the short version
string of kernels that are 'between' -rc tags. (i dropped the '+' within
the long version i did in v1 - there were objections against that)
Would this be ok?
Ingo
-------------->
>From 597e5b15dd0cbb3158afc438e5edae9986e6b76a Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 6 Oct 2009 09:31:03 -0700
Subject: [PATCH] kbuild: Improve version string logic
It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
way:
- if it is set, things work the way they always have, and you get a
extended kernel release like:
2.6.32-rc3-00052-g0eca52a
- but if it is _not_ set, we'll still try to get a version from the
underlying SCM (we actually support git, hg and SVN right now, even if
some comments may say "git only"), and if the underlying SCM says it
has a local version, we append just "+", so you get a version number
like:
2.6.32-rc3+
IOW, you'd never get 2.6.32-rc0, but you'd get either the complex git
version number (or SVN/hg/whatever), or at least "2.6.31+" with the "+"
showing that it is more than plain 2.6.31.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Frans Pop <elendil@planet.nl>
Cc: Dirk Hohndel <hohndel@infradead.org>
Cc: Len Brown <lenb@kernel.org>
LKML-Reference: <20091006173508.GA4786@elte.hu>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
Makefile | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 927d7a3..5dab509 100644
--- a/Makefile
+++ b/Makefile
@@ -963,8 +963,6 @@ localver = $(subst $(space),, $(string) \
# .scmversion is used when generating rpm packages so we do not loose
# the version information from the SCM when we do the build of the kernel
# from the copied source
-ifdef CONFIG_LOCALVERSION_AUTO
-
ifeq ($(wildcard .scmversion),)
_localver-auto = $(shell $(CONFIG_SHELL) \
$(srctree)/scripts/setlocalversion $(srctree))
@@ -972,7 +970,14 @@ else
_localver-auto = $(shell cat .scmversion 2> /dev/null)
endif
+ifdef CONFIG_LOCALVERSION_AUTO
localver-auto = $(LOCALVERSION)$(_localver-auto)
+else
+ ifeq ($_localver-auto,)
+ localver-auto = $(LOCALVERSION)
+ else
+ localver-auto = $(LOCALVERSION)+
+ endif
endif
localver-full = $(localver)$(localver-auto)
^ permalink raw reply related [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-12 19:57 ` [PATCH, v2] " Ingo Molnar
@ 2009-10-12 22:04 ` Frans Pop
2009-10-13 7:05 ` Ingo Molnar
2009-10-13 2:00 ` David Rientjes
2010-06-07 17:18 ` [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks Boaz Harrosh
2 siblings, 1 reply; 131+ messages in thread
From: Frans Pop @ 2009-10-12 22:04 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On Monday 12 October 2009, Ingo Molnar wrote:
> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> way:
>
> - if it is set, things work the way they always have, and you get a
> extended kernel release like:
>
> 2.6.32-rc3-00052-g0eca52a
>
> - but if it is _not_ set, we'll still try to get a version from the
> underlying SCM (we actually support git, hg and SVN right now, even
> if some comments may say "git only"), and if the underlying SCM says it
> has a local version, we append just "+", so you get a version number
> like:
>
> 2.6.32-rc3+
I don't object to making this the default (even a strong default), but I
still don't like the fact that it's not optional.
IMO both LOCALVERSION_AUTO *and* the added "+" can be unsuitable for some
use cases, for example for distributions.
If someone uses git to manage their custom patches, the only out this patch
leaves them to avoid the "+" is to revert it in their own trees. IMO that
should not be necessary.
To repeat some comments from <200910062137.06593.elendil@planet.nl>:
<snip>
Linus wrote:
> That said, we might make it a lot harder for people to overlook this by
> mistake when they don't care or know enough. Maybe we can have three
> levels of the "automatic" version number, and make the third level ("no
> automatic sign of versioning at all") be something that you really need
> to ask for (eg you need to have EMBEDDED enabled to show that you want
> the whole extended config option setup or something fairly draconian
> like that).
I'd opt for the "or something" as I think it would be a mistake to link it
to EMBEDDED. That has a rather different purpose.
One case to consider is distributions. They will have their own patches,
possibly as a branch off mainline in git.
AFAICT with the current patch they'd automatically always get the "+",
which is almost certain to conflict with their own naming schemes.
Distro configs with EMBEDDED set also does not seem right. Nor should it
IMHO be needed to have to patch the Makefile to get rid of it.
I think just having a config option with the three choices you suggest and
an appropriate help text to guide users should be sufficient, with the one
that activates the "+" as default.
</snip>
Cheers,
FJP
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-12 22:04 ` Frans Pop
@ 2009-10-13 7:05 ` Ingo Molnar
2009-10-13 17:51 ` Frans Pop
0 siblings, 1 reply; 131+ messages in thread
From: Ingo Molnar @ 2009-10-13 7:05 UTC (permalink / raw)
To: Frans Pop
Cc: Linus Torvalds, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
* Frans Pop <elendil@planet.nl> wrote:
> On Monday 12 October 2009, Ingo Molnar wrote:
> > It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> > way:
> >
> > - if it is set, things work the way they always have, and you get a
> > extended kernel release like:
> >
> > 2.6.32-rc3-00052-g0eca52a
> >
> > - but if it is _not_ set, we'll still try to get a version from the
> > underlying SCM (we actually support git, hg and SVN right now, even
> > if some comments may say "git only"), and if the underlying SCM says it
> > has a local version, we append just "+", so you get a version number
> > like:
> >
> > 2.6.32-rc3+
>
> I don't object to making this the default (even a strong default), but
> I still don't like the fact that it's not optional.
>
> IMO both LOCALVERSION_AUTO *and* the added "+" can be unsuitable for
> some use cases, for example for distributions.
>
> If someone uses git to manage their custom patches, the only out this
> patch leaves them to avoid the "+" is to revert it in their own trees.
Is this a bad thing?
> IMO that should not be necessary.
Why not?
Ingo
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-13 7:05 ` Ingo Molnar
@ 2009-10-13 17:51 ` Frans Pop
2009-10-13 18:01 ` Linus Torvalds
0 siblings, 1 reply; 131+ messages in thread
From: Frans Pop @ 2009-10-13 17:51 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On Tuesday 13 October 2009, Ingo Molnar wrote:
> > IMO both LOCALVERSION_AUTO *and* the added "+" can be unsuitable for
> > some use cases, for example for distributions.
> >
> > If someone uses git to manage their custom patches, the only out this
> > patch leaves them to avoid the "+" is to revert it in their own trees.
>
> Is this a bad thing?
IMHO yes. This change essentially creates a backwards incompatibility with
existing naming schemes. Requiring to patch the change out to preserve an
existing naming scheme just seems a tad unfriendly.
But if I'm the only one who feels that way, go right ahead. You might
consider adding a comment in the Makefile as a pointer though.
I appreciate that you want this to be a strong default. Does Kconfig
support defining an option that can only be set by manually editing the
config and is not displayed as a config question?
If that is supported (or if support for that could be added), then that
might be a sufficiently obscure solution that experts would know how to
find, but would leave the vast majority of users using the default.
Cheers,
FJP
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-13 17:51 ` Frans Pop
@ 2009-10-13 18:01 ` Linus Torvalds
2009-10-13 23:59 ` David Rientjes
0 siblings, 1 reply; 131+ messages in thread
From: Linus Torvalds @ 2009-10-13 18:01 UTC (permalink / raw)
To: Frans Pop; +Cc: Ingo Molnar, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On Tue, 13 Oct 2009, Frans Pop wrote:
> On Tuesday 13 October 2009, Ingo Molnar wrote:
> >
> > Is this a bad thing?
>
> IMHO yes. This change essentially creates a backwards incompatibility with
> existing naming schemes. Requiring to patch the change out to preserve an
> existing naming scheme just seems a tad unfriendly.
Let's keep the old behavior by making the AUTO option an three-way choice
("none", "short", "auto"), and making sure that it actually takes work to
choose "none" (and that "make oldconfig" doesn't choose it unless you
explicitly made the choice before - so people who just re-use old .config
files wouldn't get "none" by mistake).
Linus
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-13 18:01 ` Linus Torvalds
@ 2009-10-13 23:59 ` David Rientjes
2009-10-14 6:59 ` Ingo Molnar
2009-10-14 21:55 ` Frans Pop
0 siblings, 2 replies; 131+ messages in thread
From: David Rientjes @ 2009-10-13 23:59 UTC (permalink / raw)
To: Linus Torvalds
Cc: Frans Pop, Ingo Molnar, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Tue, 13 Oct 2009, Linus Torvalds wrote:
> > IMHO yes. This change essentially creates a backwards incompatibility with
> > existing naming schemes. Requiring to patch the change out to preserve an
> > existing naming scheme just seems a tad unfriendly.
>
> Let's keep the old behavior by making the AUTO option an three-way choice
> ("none", "short", "auto"), and making sure that it actually takes work to
> choose "none" (and that "make oldconfig" doesn't choose it unless you
> explicitly made the choice before - so people who just re-use old .config
> files wouldn't get "none" by mistake).
>
I don't think you want to do that because it would require the .config to
be posted on bug reports, for example, to determine the setting of
CONFIG_LOCALVERSION_AUTO before you can interpret the kernel version. In
other words, you wouldn't know that "2.6.32-rc4" is actually 200 commits
beyond the actual release unless you also know that the .config has
CONFIG_LOCALVERSION_AUTO="none".
Instead, it's better to force something to be appended to the kernel
release when "git describe" shows a non-zero revision count as you
earlier suggested. When CONFIG_LOCALVERSION_AUTO is enabled, that would
be the output of scripts/setlocalversion; when it is disabled, it would be
a `+'. Only when scripts/setlocalversion returns nothing (we're at an
actual kernel release) will nothing be appended.
The following is on top of my "scripts: suppress setlocalversion output if
at tagged commit" patch from
http://marc.info/?l=linux-kernel&m=125542102631704
kbuild: improve version string logic
The LOCALVERSION= string passed to "make" will now always be appended to
the kernel version after CONFIG_LOCALVERSION, if it exists, regardless of
whether CONFIG_LOCALVERSION_AUTO is set or not. This allows users to
uniquely identify their kernel builds with a string.
scripts/setlocalversion will now always be called to determine whether
the repository is beyond a tagged (release) commit. With "scripts:
suppress setlocalversion output if at tagged commit", the output of this
script is empty when at a tagged commit.
If CONFIG_LOCALVERSION_AUTO is enabled, the unique SCM tag reported by
setlocalversion (or .scmversion) is appended to the kernel version, if it
exists. 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.
The end result is this:
- when LOCALVERSION= is passed to "make", it is appended to the kernel
version,
- when CONFIG_LOCALVERSION_AUTO is enabled, a unique SCM identifier is
appended if the respository has been revised beyond a tagged commit,
and
- when CONFIG_LOCALVERSION_AUTO is disabled, a `+' is appended if the
repository has been revised beyond a tagged commit.
Also renames variables such as localver-auto and _localver-auto to more
accurately describe what they represent: localver-extra and
scm-identifier, respectively.
Signed-off-by: David Rientjes <rientjes@google.com>
---
Makefile | 32 ++++++++++++++++++++------------
1 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -898,9 +898,13 @@ $(vmlinux-dirs): prepare scripts
# $(localver)
# localversion* (files without backups, containing '~')
# $(CONFIG_LOCALVERSION) (from kernel config setting)
-# $(localver-auto) (only if CONFIG_LOCALVERSION_AUTO is set)
-# ./scripts/setlocalversion (SCM tag, if one exists)
-# $(LOCALVERSION) (from make command line if provided)
+# $(LOCALVERSION) (from make command line, if provided)
+# $(localver-extra)
+# $(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 repository is at non-tagged commit)
#
# Note how the final $(localver-auto) string is included *only* if the
# kernel config option CONFIG_LOCALVERSION_AUTO is selected. Also, at the
@@ -914,26 +918,30 @@ string = $(shell cat /dev/null \
localver = $(subst $(space),, $(string) \
$(patsubst "%",%,$(CONFIG_LOCALVERSION)))
-# If CONFIG_LOCALVERSION_AUTO is set scripts/setlocalversion is called
-# and if the SCM is know a tag from the SCM is appended.
-# The appended tag is determined by the SCM used.
+# scripts/setlocalversion is called to create a unique identifier if the source
+# is managed by a known SCM and the repository has been revised since the last
+# tagged (release) commit. The format of the identifier is determined by the
+# SCM's implementation.
#
# .scmversion is used when generating rpm packages so we do not loose
# the version information from the SCM when we do the build of the kernel
# from the copied source
-ifdef CONFIG_LOCALVERSION_AUTO
-
ifeq ($(wildcard .scmversion),)
- _localver-auto = $(shell $(CONFIG_SHELL) \
+ scm-identifier = $(shell $(CONFIG_SHELL) \
$(srctree)/scripts/setlocalversion $(srctree))
else
- _localver-auto = $(shell cat .scmversion 2> /dev/null)
+ scm-identifier = $(shell cat .scmversion 2> /dev/null)
endif
- localver-auto = $(LOCALVERSION)$(_localver-auto)
+ifdef CONFIG_LOCALVERSION_AUTO
+ localver-extra = $(scm-identifier)
+else
+ ifneq ($scm-identifier,)
+ localver-extra = +
+ endif
endif
-localver-full = $(localver)$(localver-auto)
+localver-full = $(localver)$(LOCALVERSION)$(localver-extra)
# Store (new) KERNELRELASE string in include/config/kernel.release
kernelrelease = $(KERNELVERSION)$(localver-full)
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-13 23:59 ` David Rientjes
@ 2009-10-14 6:59 ` Ingo Molnar
2009-10-14 7:24 ` David Rientjes
2009-10-14 21:55 ` Frans Pop
1 sibling, 1 reply; 131+ messages in thread
From: Ingo Molnar @ 2009-10-14 6:59 UTC (permalink / raw)
To: David Rientjes
Cc: Linus Torvalds, Frans Pop, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
* David Rientjes <rientjes@google.com> wrote:
> On Tue, 13 Oct 2009, Linus Torvalds wrote:
>
> > > IMHO yes. This change essentially creates a backwards incompatibility with
> > > existing naming schemes. Requiring to patch the change out to preserve an
> > > existing naming scheme just seems a tad unfriendly.
> >
> > Let's keep the old behavior by making the AUTO option an three-way
> > choice ("none", "short", "auto"), and making sure that it actually
> > takes work to choose "none" (and that "make oldconfig" doesn't
> > choose it unless you explicitly made the choice before - so people
> > who just re-use old .config files wouldn't get "none" by mistake).
>
> I don't think you want to do that because it would require the .config
> to be posted on bug reports, for example, to determine the setting of
> CONFIG_LOCALVERSION_AUTO before you can interpret the kernel version.
> In other words, you wouldn't know that "2.6.32-rc4" is actually 200
> commits beyond the actual release unless you also know that the
> .config has CONFIG_LOCALVERSION_AUTO="none".
We've come a full circle ...
That's the current !CONFIG_LOCALVERSION_AUTO status quo ... That was
being asked to be preserved for (unspecified) packaging reasons. So
your suggestion is to do away with that behavior altogether?
Ingo
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-14 6:59 ` Ingo Molnar
@ 2009-10-14 7:24 ` David Rientjes
2009-10-14 7:33 ` Ingo Molnar
0 siblings, 1 reply; 131+ messages in thread
From: David Rientjes @ 2009-10-14 7:24 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Frans Pop, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Wed, 14 Oct 2009, Ingo Molnar wrote:
> > I don't think you want to do that because it would require the .config
> > to be posted on bug reports, for example, to determine the setting of
> > CONFIG_LOCALVERSION_AUTO before you can interpret the kernel version.
> > In other words, you wouldn't know that "2.6.32-rc4" is actually 200
> > commits beyond the actual release unless you also know that the
> > .config has CONFIG_LOCALVERSION_AUTO="none".
>
> We've come a full circle ...
>
> That's the current !CONFIG_LOCALVERSION_AUTO status quo ... That was
> being asked to be preserved for (unspecified) packaging reasons. So
> your suggestion is to do away with that behavior altogether?
>
I don't think it's helpful to specify a version as "2.6.32-rc4" when in
reality it has 200 commits beyond the release and I like the addition of
`+' for !CONFIG_LOCALVERSION_AUTO if we're not at a tagged commit.
That's what my two patches do so the only time you could get a
"2.6.32-rc4" version string is for when it's the equivalent of
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.32-rc4.tar.bz2
(and you would actually get that regardless of whether you're using
CONFIG_LOCALVERSION_AUTO or not).
There's another possible extension that could be made: we could allow
LOCALVERSION= as passed to "make" to override the added `+' since it is
used to identify kernel versions by a string anyway; so make
LOCALVERSION=-slub_fixes would become v2.6.32-rc4-slub_fixes if
CONFIG_LOCALVERSION_AUTO were disabled, regardless of what commit we're
at, and v2.6.32-rc4-slub_fixes-00094-g80f5069 if it were enabled.
Regardless of future improvements, I think my two patches allow the kernel
version to more accurately describe what is running. That is predicated
on my belief that "v2.6.32-rc4", though, should never describe _anything_
except the kernel.org v2.6.32-rc4 kernel.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-14 7:24 ` David Rientjes
@ 2009-10-14 7:33 ` Ingo Molnar
2009-10-14 7:42 ` David Rientjes
0 siblings, 1 reply; 131+ messages in thread
From: Ingo Molnar @ 2009-10-14 7:33 UTC (permalink / raw)
To: David Rientjes
Cc: Linus Torvalds, Frans Pop, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
* David Rientjes <rientjes@google.com> wrote:
> On Wed, 14 Oct 2009, Ingo Molnar wrote:
>
> > > I don't think you want to do that because it would require the .config
> > > to be posted on bug reports, for example, to determine the setting of
> > > CONFIG_LOCALVERSION_AUTO before you can interpret the kernel version.
> > > In other words, you wouldn't know that "2.6.32-rc4" is actually 200
> > > commits beyond the actual release unless you also know that the
> > > .config has CONFIG_LOCALVERSION_AUTO="none".
> >
> > We've come a full circle ...
> >
> > That's the current !CONFIG_LOCALVERSION_AUTO status quo ... That was
> > being asked to be preserved for (unspecified) packaging reasons. So
> > your suggestion is to do away with that behavior altogether?
> >
>
> I don't think it's helpful to specify a version as "2.6.32-rc4" when
> in reality it has 200 commits beyond the release and I like the
> addition of `+' for !CONFIG_LOCALVERSION_AUTO if we're not at a tagged
> commit. That's what my two patches do so the only time you could get
> a "2.6.32-rc4" version string is for when it's the equivalent of
> http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.32-rc4.tar.bz2
> (and you would actually get that regardless of whether you're using
> CONFIG_LOCALVERSION_AUTO or not).
>
> There's another possible extension that could be made: we could allow
> LOCALVERSION= as passed to "make" to override the added `+' since it
> is used to identify kernel versions by a string anyway; so make
> LOCALVERSION=-slub_fixes would become v2.6.32-rc4-slub_fixes if
> CONFIG_LOCALVERSION_AUTO were disabled, regardless of what commit
> we're at, and v2.6.32-rc4-slub_fixes-00094-g80f5069 if it were
> enabled.
>
> Regardless of future improvements, I think my two patches allow the
> kernel version to more accurately describe what is running. That is
> predicated on my belief that "v2.6.32-rc4", though, should never
> describe _anything_ except the kernel.org v2.6.32-rc4 kernel.
I agree with all that - in fact i started this thread by stating that
view and suggesting the '+' extension to the short version name.
But there's been packaging related objections from Frans and others, and
i suspect you'll need to answer/address those instead of further
detailing the virtues of proper version names (which i still 100% agree
with).
Btw., i only minimally agree with the packaging objections: there's
certainly no harm in enabling for folks to still keep things as they
were for years. But we can definitely change the default and we can make
it difficult to choose the faulty short-name scheme.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-14 7:33 ` Ingo Molnar
@ 2009-10-14 7:42 ` David Rientjes
2009-10-14 23:43 ` Frans Pop
2009-10-15 8:01 ` David Rientjes
0 siblings, 2 replies; 131+ messages in thread
From: David Rientjes @ 2009-10-14 7:42 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Frans Pop, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Wed, 14 Oct 2009, Ingo Molnar wrote:
> > Regardless of future improvements, I think my two patches allow the
> > kernel version to more accurately describe what is running. That is
> > predicated on my belief that "v2.6.32-rc4", though, should never
> > describe _anything_ except the kernel.org v2.6.32-rc4 kernel.
>
> I agree with all that - in fact i started this thread by stating that
> view and suggesting the '+' extension to the short version name.
>
Yeah, my patches build upon the base that you originally proposed. I like
the `+' suffix for configs with CONFIG_LOCALVERSION_AUTO that aren't
vanilla kernels.
> But there's been packaging related objections from Frans and others, and
> i suspect you'll need to answer/address those instead of further
> detailing the virtues of proper version names (which i still 100% agree
> with).
>
We could easily go with my suggestion of allowing "make LOCALVERSION=" to
override all additions to the kernel version when CONFIG_LOCALVERSION_AUTO
is disabled. For such configurations, kernels would be built with this
variable to specify how it's different from the vanilla version and would
suppress the `+'.
Frans and others, how does adding a unique string passed by the user for a
more descriptive kernel version interact poorly with certain packaging
requirements?
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-14 7:42 ` David Rientjes
@ 2009-10-14 23:43 ` Frans Pop
2009-10-15 7:37 ` David Rientjes
2009-10-15 9:03 ` Ingo Molnar
2009-10-15 8:01 ` David Rientjes
1 sibling, 2 replies; 131+ messages in thread
From: Frans Pop @ 2009-10-14 23:43 UTC (permalink / raw)
To: David Rientjes
Cc: Ingo Molnar, Linus Torvalds, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Wednesday 14 October 2009, David Rientjes wrote:
> On Wed, 14 Oct 2009, Ingo Molnar wrote:
> Yeah, my patches build upon the base that you originally proposed. I
> like the `+' suffix for configs with CONFIG_LOCALVERSION_AUTO that
> aren't vanilla kernels.
That is fine for custom kernels. I still maintain that it is hopelessly
wrong for distro kernels.
Distro kernels generally have their own naming schemes.
Debian uses: 2.6.30-2-amd64 (<version>-<ABI>-<flavor>)
Fedora uses: 2.6.30.5-43.fc11.i586
And those kernel versions implicitly already contain the information that
they are not vanilla kernels. So a "+" suffix is totally redundant.
My main argument is that if they build kernels from an SCM, which is quite
likely, they should not suddenly get a "+" appended to those versions.
And IMO they should also not have to patch the Makefile to avoid it.
If this change is made, it should be made in such a way that old version
naming schemes are still possible.
> > But there's been packaging related objections from Frans and others,
I'm personally not convinced that there are actual *technical* packaging
issues, at least not for Debian (see my posts elsewhere in the thread).
However, it is very much possible that the change will break random
scripts that are in use and that expect a certain naming scheme.
Having an out would help those cases as well.
> > and i suspect you'll need to answer/address those instead of further
> > detailing the virtues of proper version names (which i still 100%
> > agree with).
>
> We could easily go with my suggestion of allowing "make LOCALVERSION="
> to override all additions to the kernel version when
> CONFIG_LOCALVERSION_AUTO is disabled. For such configurations, kernels
> would be built with this variable to specify how it's different from the
> vanilla version and would suppress the `+'.
Using LOCALVERSION= for that would be wrong as it is on a different level
from AUTOVERSION. They should be independent. However, that basic approach
of using an environment variable is certainly an option.
And, while I was working on the patch to implement a tristate AUTOVERSION,
I thought of a very common use case that IMO we do want to cover here.
Many users build custom kernels using a distro config as starting point.
The distro does not want the "+", but we very much _do_ want it in the
custom kernel built by the user.
So the conclusion is that suppressing the "+" is simply not something that
can be set in the config, and thus the tristate solution is wrong.
Only alternative I see is that it must be a build option.
So I propose the following patch on top of the patch proposed by David.
It offers a clean out for users who explicitly do not want *any* SCM-based
suffix added to their kernel version, and is IMO both 1) obvious enough
for expert users and 2) obscure enough that regular users are unlikely to
abuse it. Is that acceptable?
The patch also fixes up the comment I mentioned earlier. The old comment
was outdated anyway and partially made redundant by the change David
already made in the later comment. And it has a typo fix.
David: I think it would be best to just merge this into your patch.
diff --git a/Makefile b/Makefile
index 24e54fd..6fcaba7 100644
--- a/Makefile
+++ b/Makefile
@@ -906,10 +906,8 @@ $(vmlinux-dirs): prepare scripts
# + (only without CONFIG_LOCALVERSION_AUTO
# and repository is at non-tagged commit)
#
-# Note how the final $(localver-auto) string is included *only* if the
-# kernel config option CONFIG_LOCALVERSION_AUTO is selected. Also, at the
-# moment, only git is supported but other SCMs can edit the script
-# scripts/setlocalversion and add the appropriate checks as needed.
+# Note that the final $(localver-extra) string can be suppressed by setting
+# the environment variable KBUILD_NO_LOCALVERSION_EXTRA.
pattern = ".*/localversion[^~]*"
string = $(shell cat /dev/null \
@@ -923,9 +921,11 @@ localver = $(subst $(space),, $(string) \
# tagged (release) commit. The format of the identifier is determined by the
# SCM's implementation.
#
-# .scmversion is used when generating rpm packages so we do not loose
+# .scmversion is used when generating rpm packages so we do not lose
# the version information from the SCM when we do the build of the kernel
# from the copied source
+ifndef KBUILD_NO_LOCALVERSION_EXTRA
+
ifeq ($(wildcard .scmversion),)
scm-identifier = $(shell $(CONFIG_SHELL) \
$(srctree)/scripts/setlocalversion $(srctree))
@@ -941,6 +941,8 @@ else
endif
endif
+endif # ifndef KBUILD_NO_LOCALVERSION_EXTRA
+
localver-full = $(localver)$(LOCALVERSION)$(localver-extra)
# Store (new) KERNELRELASE string in include/config/kernel.release
^ permalink raw reply related [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-14 23:43 ` Frans Pop
@ 2009-10-15 7:37 ` David Rientjes
2009-10-15 14:13 ` Frans Pop
2009-10-15 9:03 ` Ingo Molnar
1 sibling, 1 reply; 131+ messages in thread
From: David Rientjes @ 2009-10-15 7:37 UTC (permalink / raw)
To: Frans Pop
Cc: Ingo Molnar, Linus Torvalds, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Thu, 15 Oct 2009, Frans Pop wrote:
> That is fine for custom kernels. I still maintain that it is hopelessly
> wrong for distro kernels.
>
> Distro kernels generally have their own naming schemes.
> Debian uses: 2.6.30-2-amd64 (<version>-<ABI>-<flavor>)
> Fedora uses: 2.6.30.5-43.fc11.i586
>
> And those kernel versions implicitly already contain the information that
> they are not vanilla kernels. So a "+" suffix is totally redundant.
>
And that's why I suggested, in addition to my patch, that we allow "make
LOCALVERSION=" to override the `+' suffix for kernels compiled without
CONFIG_LOCALVERSION_AUTO. In your examples, they would pass
LOCALVERSION=-2-amd64 or LOCALVERSION=-43.fc11.i586, respectively, to
make.
> My main argument is that if they build kernels from an SCM, which is quite
> likely, they should not suddenly get a "+" appended to those versions.
> And IMO they should also not have to patch the Makefile to avoid it.
> If this change is made, it should be made in such a way that old version
> naming schemes are still possible.
>
They are, with my suggestion to allow make LOCALVERSION= to override the
`+'. The question I posed directly to you was this: how does adding a
unique string passed by the user for a more descriptive kernel version
interact poorly with certain packaging requirements? You've given two
examples that are _perfect_ use cases for my suggestion.
> > We could easily go with my suggestion of allowing "make LOCALVERSION="
> > to override all additions to the kernel version when
> > CONFIG_LOCALVERSION_AUTO is disabled. For such configurations, kernels
> > would be built with this variable to specify how it's different from the
> > vanilla version and would suppress the `+'.
>
> Using LOCALVERSION= for that would be wrong as it is on a different level
> from AUTOVERSION. They should be independent. However, that basic approach
> of using an environment variable is certainly an option.
>
Now I'm confused, because currently LOCALVERSION= can only be used when
CONFIG_LOCALVERSION_AUTO is defined; in other words, it's completely
dependent on it. My patch changes that and seems to be your desire as
well?
> So I propose the following patch on top of the patch proposed by David.
> It offers a clean out for users who explicitly do not want *any* SCM-based
> suffix added to their kernel version, and is IMO both 1) obvious enough
> for expert users and 2) obscure enough that regular users are unlikely to
> abuse it. Is that acceptable?
>
No, it actually makes things much worse because now instead of forcing the
user to post his .config to determine the setting of
CONFIG_LOCALVERSION_AUTO to intepret the version string, it forces them to
recall what their KBUILD_NO_LOCALVERSION_EXTRA environment variable
happened to be at the time of build.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-15 7:37 ` David Rientjes
@ 2009-10-15 14:13 ` Frans Pop
2009-10-15 20:38 ` David Rientjes
0 siblings, 1 reply; 131+ messages in thread
From: Frans Pop @ 2009-10-15 14:13 UTC (permalink / raw)
To: David Rientjes
Cc: Ingo Molnar, Linus Torvalds, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Thursday 15 October 2009, David Rientjes wrote:
> And that's why I suggested, in addition to my patch, that we allow "make
> LOCALVERSION=" to override the `+' suffix for kernels compiled without
> CONFIG_LOCALVERSION_AUTO. In your examples, they would pass
> LOCALVERSION=-2-amd64 or LOCALVERSION=-43.fc11.i586, respectively, to
> make.
Who says they are using LOCALVERSION to add the suffix?
> > My main argument is that if they build kernels from an SCM, which is
> > quite likely, they should not suddenly get a "+" appended to those
> > versions. And IMO they should also not have to patch the Makefile to
> > avoid it. If this change is made, it should be made in such a way that
> > old version naming schemes are still possible.
>
> They are, with my suggestion to allow make LOCALVERSION= to override the
> `+'. The question I posed directly to you was this: how does adding a
> unique string passed by the user for a more descriptive kernel version
> interact poorly with certain packaging requirements? You've given two
> examples that are _perfect_ use cases for my suggestion.
I'm not a Debian kernel maintainer, so I cannot answer that question. I
will alert the Debian kernel team to this discussion so they can respond
for themselves.
The thing is that you are assuming people do things in a certain way and
your patches will break existing naming schemes for anybody who happens to
do things slightly differently. My proposal offered full backwards
compatibility for people who know what they are doing.
> > Using LOCALVERSION= for that would be wrong as it is on a different
> > level from AUTOVERSION. They should be independent. However, that
> > basic approach of using an environment variable is certainly an
> > option.
>
> Now I'm confused, because currently LOCALVERSION= can only be used when
> CONFIG_LOCALVERSION_AUTO is defined; in other words, it's completely
> dependent on it. My patch changes that and seems to be your desire as
> well?
That change seemed logical to me. And I did say my patch was on top of
yours, so yes, my comment was based on that change being implemented.
> > So I propose the following patch on top of the patch proposed by
> > David. It offers a clean out for users who explicitly do not want
> > *any* SCM-based suffix added to their kernel version, and is IMO both
> > 1) obvious enough for expert users and 2) obscure enough that regular
> > users are unlikely to abuse it. Is that acceptable?
>
> No, it actually makes things much worse because now instead of forcing
> the user to post his .config to determine the setting of
> CONFIG_LOCALVERSION_AUTO to intepret the version string, it forces them
> to recall what their KBUILD_NO_LOCALVERSION_EXTRA environment variable
> happened to be at the time of build.
As I've already said, I think that build variable is sufficiently obscure
that I expect it will only be used by people who know what they are doing.
And I can only repeat that even with your patch you will never get 100%
coverage. People who really don't want the "+" will simply patch it out.
Why not give them a clean way to avoid it?
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-15 14:13 ` Frans Pop
@ 2009-10-15 20:38 ` David Rientjes
2009-10-15 21:01 ` Frans Pop
0 siblings, 1 reply; 131+ messages in thread
From: David Rientjes @ 2009-10-15 20:38 UTC (permalink / raw)
To: Frans Pop
Cc: Ingo Molnar, Linus Torvalds, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Thu, 15 Oct 2009, Frans Pop wrote:
> > And that's why I suggested, in addition to my patch, that we allow "make
> > LOCALVERSION=" to override the `+' suffix for kernels compiled without
> > CONFIG_LOCALVERSION_AUTO. In your examples, they would pass
> > LOCALVERSION=-2-amd64 or LOCALVERSION=-43.fc11.i586, respectively, to
> > make.
>
> Who says they are using LOCALVERSION to add the suffix?
>
You would prefer that CONFIG_LOCALVERSION overrides the `+' when
CONFIG_LOCALVERSION_AUTO is disabled?
> The thing is that you are assuming people do things in a certain way and
> your patches will break existing naming schemes for anybody who happens to
> do things slightly differently. My proposal offered full backwards
> compatibility for people who know what they are doing.
>
Your proposal doesn't work because the context (the state of an
environment variable at build, in your case) isn't known to interpret the
version string.
The point is that you should be able to look at a kernel version without
asking for enviornment variables or configs and know what kernel is
running. That's not always going to be valid, someone can make additional
changes outside of a git respository and use it, but the net impact is
that versions have become much more descriptive from a large majority of
the general population that posts to linux-kernel, git users, and it's
going to save a lot of time.
> > No, it actually makes things much worse because now instead of forcing
> > the user to post his .config to determine the setting of
> > CONFIG_LOCALVERSION_AUTO to intepret the version string, it forces them
> > to recall what their KBUILD_NO_LOCALVERSION_EXTRA environment variable
> > happened to be at the time of build.
>
> As I've already said, I think that build variable is sufficiently obscure
> that I expect it will only be used by people who know what they are doing.
>
Do you really expect people to email bug reports and say "btw, I compiled
with KBUILD_NO_LOCALVERSION_EXTRA because I thought it looked prettier,
this is actually Linus' git at a3ccf63"?
> And I can only repeat that even with your patch you will never get 100%
> coverage. People who really don't want the "+" will simply patch it out.
> Why not give them a clean way to avoid it?
>
Sigh, this is becoming ridiculous. If you're doing development and have
revisions beyond a tagged release, then why would you want the version to
still be "v2.6.32-rc4" without giving it a descriptive name of your own?
Why wouldn't you use LOCALVERSION=-slub_merge, for example, to describe
what the kernel was? The scenario you're describing is where everyone has
100 different v2.6.32-rc4 kernels sitting around because they've disabled
CONFIG_LOCALVERSION_AUTO and aren't able to tell the difference between
them. That's just a poor work environment.
[ I can understand if you frequently do build and boot testing, but even
then you can get rid of that `+' very easily by giving it a descriptive
LOCALVERSION= name if `+' causes you so much grief. ]
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-15 20:38 ` David Rientjes
@ 2009-10-15 21:01 ` Frans Pop
0 siblings, 0 replies; 131+ messages in thread
From: Frans Pop @ 2009-10-15 21:01 UTC (permalink / raw)
To: David Rientjes
Cc: Ingo Molnar, Linus Torvalds, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Thursday 15 October 2009, David Rientjes wrote:
> Sigh, this is becoming ridiculous.
Yes, I thoroughly agree. I'm afraid I don't see much point in repeating my
arguments anymore.
We seem to be unable to get eachothers arguments. I think I understand your
PoV, or at least your aims, and I even agree with those. I don't think you
really get my concerns about the implementation, but I give up. I seem
unable to make you understand; probably my limitation. So, let's just
agree to disagree.
My conclusion in the mean time is that the whole concept of having the "+"
is broken. Especially since my discovery earlier today [1] that it is more
than likely to break existing scripts in userspace (not packaging, but
regular userspace).
I plan to continue to use my own naming conventions, even if that means I
have to patch the "+' out of the Makefile. Especially since it seems I
have to decide between risking breakage in user space and confirming to
this new standard. And that choice is simple.
> Do you really expect people to email bug reports and say "btw, I
> compiled with KBUILD_NO_LOCALVERSION_EXTRA because I thought it looked
> prettier, this is actually Linus' git at a3ccf63"?
In the current situation I already frequently provide the output of 'git
describe master' as part of bug reports. Nothing new there. And users will
*still* need to do that as the "+" does not tell anyone where exactly they
are at. It could equally be release +50 or +4000 commits.
Cheers.
FJP
[1] http://lkml.org/lkml/2009/10/15/210
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-14 23:43 ` Frans Pop
2009-10-15 7:37 ` David Rientjes
@ 2009-10-15 9:03 ` Ingo Molnar
2009-10-15 14:42 ` Frans Pop
1 sibling, 1 reply; 131+ messages in thread
From: Ingo Molnar @ 2009-10-15 9:03 UTC (permalink / raw)
To: Frans Pop
Cc: David Rientjes, Linus Torvalds, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
* Frans Pop <elendil@planet.nl> wrote:
> On Wednesday 14 October 2009, David Rientjes wrote:
> > On Wed, 14 Oct 2009, Ingo Molnar wrote:
> > Yeah, my patches build upon the base that you originally proposed. I
> > like the `+' suffix for configs with CONFIG_LOCALVERSION_AUTO that
> > aren't vanilla kernels.
>
> That is fine for custom kernels. I still maintain that it is hopelessly
> wrong for distro kernels.
>
> Distro kernels generally have their own naming schemes.
> Debian uses: 2.6.30-2-amd64 (<version>-<ABI>-<flavor>)
> Fedora uses: 2.6.30.5-43.fc11.i586
>
> And those kernel versions implicitly already contain the information
> that they are not vanilla kernels. So a "+" suffix is totally
> redundant.
It's not "totally redundant" _AT ALL_.
"2.6.30+-2-amd64" tells us that not only do we have the usual per distro
patches on top of vanilla .30 (which patches can be found in the deb or
src.rpm), but we _ALSO_ have extra _vanilla kernel_ commits since
v2.6.30.
So it is very much meaningful. If i hunt a weird bug visible in a distro
but not visible in my reproduction, i will be alerted to the fact that
the distro isnt using a precise tag as a base but something inbetween.
That is useful information. Why do you keep insisting that it's "totally
redundant"? It is clearly not. It's a property of the upstream kernel
version - any per distro pile of patches on top of that is a different
space. _Both_ pieces of information are important - that's why Debian
put that -5 there.
Besides, distros building on kernels inbetween -rc's is very rare. If it
happens it's sufficiently unusual to alert users to that fact via the
'+' sign. The '+' sign will go away if a distro uses a precise upstream
version.
Ingo
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-15 9:03 ` Ingo Molnar
@ 2009-10-15 14:42 ` Frans Pop
2009-10-15 20:45 ` David Rientjes
0 siblings, 1 reply; 131+ messages in thread
From: Frans Pop @ 2009-10-15 14:42 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Rientjes, Linus Torvalds, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Thursday 15 October 2009, Ingo Molnar wrote:
> > Distro kernels generally have their own naming schemes.
> > Debian uses: 2.6.30-2-amd64 (<version>-<ABI>-<flavor>)
> > Fedora uses: 2.6.30.5-43.fc11.i586
> >
> > And those kernel versions implicitly already contain the information
> > that they are not vanilla kernels. So a "+" suffix is totally
> > redundant.
>
> It's not "totally redundant" _AT ALL_.
>
> "2.6.30+-2-amd64" tells us that not only do we have the usual per distro
But it would not be "2.6.30+-2-amd64"; it would become "2.6.30-2-amd64+",
which IMO sucks.
> patches on top of vanilla .30 (which patches can be found in the deb or
> src.rpm), but we _ALSO_ have extra _vanilla kernel_ commits since
> v2.6.30.
This is where you are wrong. Yes, the patches are in the deb [1], but how
do they end up there? The distro patches themselves are also maintained in
an SCM, quite possibly as a branch from mainline, and the package
maintainers will build *from* that SCM. So *the distro patches themselves*
will trigger the "+".
You simply cannot distinguish between "extra vanilla kernel commits"
and "distro commits" in a tree. Both are changes since the tagged release;
both will trigger the "+", which makes the "+" meaningless.
Also, any distro cherry-picks upstream patches from later versions
as "distro patches" (at least, that's the case for over 90% of the patches
in Debian stable kernels). And we already know such patches are included
whenever we see a distro kernel version, so I still think having the "+"
does not add any meaningful information.
> Besides, distros building on kernels inbetween -rc's is very rare.
True. Which is why we shouldn't be adding the "+".
> If it happens it's sufficiently unusual to alert users to that fact via
> the '+' sign. The '+' sign will go away if a distro uses a precise
> upstream version.
But that's the whole point. It does not!
Even if they _only_ add their packaging infrastructure on top and have no
patches that affect the the kernel itself (which is unlikely), they would
still end up with the "+" because the commit(s) that add the packaging
infrastructure make the tree unequal to the tagged release.
Cheers,
FJP
[1] Actually they are in the .diff.gz, which contains all changes relative
to the original tarball, but I understand what you mean.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-15 14:42 ` Frans Pop
@ 2009-10-15 20:45 ` David Rientjes
0 siblings, 0 replies; 131+ messages in thread
From: David Rientjes @ 2009-10-15 20:45 UTC (permalink / raw)
To: Frans Pop
Cc: Ingo Molnar, Linus Torvalds, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Thu, 15 Oct 2009, Frans Pop wrote:
> You simply cannot distinguish between "extra vanilla kernel commits"
> and "distro commits" in a tree. Both are changes since the tagged release;
> both will trigger the "+", which makes the "+" meaningless.
>
I can guarantee that distro is not going to be releasing a "v2.6.33"
kernel with patches on top of it without modifying the version string in
some way. With my patch, the `+' is suppressed when LOCALVERSION= is
used.
I chose not to allow CONFIG_LOCALVERSION to suppress the `+' because the
config normally does not change with a revision, a build does. So while
CONFIG_LOCALVERSION may describe the packager of the kernel, LOCALVERSION=
would describe a particular release.
> > Besides, distros building on kernels inbetween -rc's is very rare.
>
> True. Which is why we shouldn't be adding the "+".
>
The `+' is irrelevant at -rc releases, it wouldn't be added anyway! It's
purpose is to identify non-vanilla release kernels.
> But that's the whole point. It does not!
> Even if they _only_ add their packaging infrastructure on top and have no
> patches that affect the the kernel itself (which is unlikely), they would
> still end up with the "+" because the commit(s) that add the packaging
> infrastructure make the tree unequal to the tagged release.
>
Why would you add packaging infrastructure to the kernel source itself?
Normally you would have a Makefile for rpm packaging that would call into
the kernel Makefile, leaving it vanilla.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-14 7:42 ` David Rientjes
2009-10-14 23:43 ` Frans Pop
@ 2009-10-15 8:01 ` David Rientjes
2009-10-15 8:59 ` Ingo Molnar
1 sibling, 1 reply; 131+ messages in thread
From: David Rientjes @ 2009-10-15 8:01 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Frans Pop, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Wed, 14 Oct 2009, David Rientjes wrote:
> We could easily go with my suggestion of allowing "make LOCALVERSION=" to
> override all additions to the kernel version when CONFIG_LOCALVERSION_AUTO
> is disabled. For such configurations, kernels would be built with this
> variable to specify how it's different from the vanilla version and would
> suppress the `+'.
>
The following patch implements this suggestion and folds both of my
proposed patches together.
kbuild: improve version string logic
The LOCALVERSION= string passed to "make" will now always be appended to
the kernel version after CONFIG_LOCALVERSION, if it exists, regardless of
whether CONFIG_LOCALVERSION_AUTO is set or not. This allows users to
uniquely identify their kernel builds with a string.
scripts/setlocalversion will now always be called to determine whether
the repository is beyond a tagged (release) commit. When at a tagged
commit, this script will now suppress all output.
If CONFIG_LOCALVERSION_AUTO is enabled, the unique SCM tag reported by
setlocalversion (or .scmversion) is appended to the kernel version, if it
exists. 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.
The end result is this:
- when LOCALVERSION= is passed to "make", it is appended to the kernel
version,
- when CONFIG_LOCALVERSION_AUTO is enabled, a unique SCM identifier is
appended if the respository has been revised beyond a tagged commit,
and
- when CONFIG_LOCALVERSION_AUTO is disabled, a `+' is appended if the
repository has been revised beyond a tagged commit and LOCALVERSION=
was not passed to "make".
Examples:
With CONFIG_LOCALVERSION_AUTO: "make" results in
v2.6.32-rc4-00149-ga3ccf63. If there are uncommited changes to the
respository, it results in v2.6.32-rc4-00149-ga3ccf63-dirty. If
"make LOCALVERSION=kbuild" were used, it results in
v2.6.32-rc4-kbuild-00149-ga3ccf63-dirty.
Without CONFIG_LOCALVERSION_AUTO, "make" results in v2.6.32-rc4+
unless the repository is at the Linux v2.6.32-rc4 commit (in which
case the version would be v2.6.32-rc4). If "make LOCALVERSION=kbuild"
were used, it results in v2.6.32-rc4-kbuild.
Also renames variables such as localver-auto and _localver-auto to more
accurately describe what they represent: localver-extra and
scm-identifier, respectively.
Signed-off-by: David Rientjes <rientjes@google.com>
---
Makefile | 43 +++++++++++++++++++++++++++----------------
scripts/setlocalversion | 3 ++-
2 files changed, 29 insertions(+), 17 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -898,14 +898,19 @@ $(vmlinux-dirs): prepare scripts
# $(localver)
# localversion* (files without backups, containing '~')
# $(CONFIG_LOCALVERSION) (from kernel config setting)
-# $(localver-auto) (only if CONFIG_LOCALVERSION_AUTO is set)
-# ./scripts/setlocalversion (SCM tag, if one exists)
-# $(LOCALVERSION) (from make command line if provided)
+# $(LOCALVERSION) (from make command line, if provided)
+# $(localver-extra)
+# $(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)
#
-# Note how the final $(localver-auto) string is included *only* if the
-# kernel config option CONFIG_LOCALVERSION_AUTO is selected. Also, at the
-# moment, only git is supported but other SCMs can edit the script
-# scripts/setlocalversion and add the appropriate checks as needed.
+# 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 \
@@ -914,26 +919,32 @@ string = $(shell cat /dev/null \
localver = $(subst $(space),, $(string) \
$(patsubst "%",%,$(CONFIG_LOCALVERSION)))
-# If CONFIG_LOCALVERSION_AUTO is set scripts/setlocalversion is called
-# and if the SCM is know a tag from the SCM is appended.
-# The appended tag is determined by the SCM used.
+# scripts/setlocalversion is called to create a unique identifier if the source
+# is managed by a known SCM and the repository has been revised since the last
+# tagged (release) commit. The format of the identifier is determined by the
+# SCM's implementation.
#
# .scmversion is used when generating rpm packages so we do not loose
# the version information from the SCM when we do the build of the kernel
# from the copied source
-ifdef CONFIG_LOCALVERSION_AUTO
-
ifeq ($(wildcard .scmversion),)
- _localver-auto = $(shell $(CONFIG_SHELL) \
+ scm-identifier = $(shell $(CONFIG_SHELL) \
$(srctree)/scripts/setlocalversion $(srctree))
else
- _localver-auto = $(shell cat .scmversion 2> /dev/null)
+ scm-identifier = $(shell cat .scmversion 2> /dev/null)
endif
- localver-auto = $(LOCALVERSION)$(_localver-auto)
+ifdef CONFIG_LOCALVERSION_AUTO
+ localver-extra = $(scm-identifier)
+else
+ ifneq ($scm-identifier,)
+ ifeq ($(LOCALVERSION),)
+ localver-extra = +
+ endif
+ endif
endif
-localver-full = $(localver)$(localver-auto)
+localver-full = $(localver)$(LOCALVERSION)$(localver-extra)
# Store (new) KERNELRELASE string in include/config/kernel.release
kernelrelease = $(KERNELVERSION)$(localver-full)
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -26,7 +26,8 @@ if head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
# If we are past a tagged commit (like "v2.6.30-rc5-302-g72357d5"),
# we pretty print it.
if atag="`git describe 2>/dev/null`"; then
- echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'
+ echo "$atag" | awk -F- 'int($(NF-1)) > 0 \
+ {printf("-%05d-%s", $(NF-1),$(NF))}'
# If we don't have a tag at all we print -g{commitish}.
else
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-15 8:01 ` David Rientjes
@ 2009-10-15 8:59 ` Ingo Molnar
0 siblings, 0 replies; 131+ messages in thread
From: Ingo Molnar @ 2009-10-15 8:59 UTC (permalink / raw)
To: David Rientjes
Cc: Linus Torvalds, Frans Pop, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
* David Rientjes <rientjes@google.com> wrote:
> On Wed, 14 Oct 2009, David Rientjes wrote:
>
> > We could easily go with my suggestion of allowing "make LOCALVERSION=" to
> > override all additions to the kernel version when CONFIG_LOCALVERSION_AUTO
> > is disabled. For such configurations, kernels would be built with this
> > variable to specify how it's different from the vanilla version and would
> > suppress the `+'.
> >
>
> The following patch implements this suggestion and folds both of my
> proposed patches together.
thanks David!
Acked-by: Ingo Molnar <mingo@elte.hu>
Ingo
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-13 23:59 ` David Rientjes
2009-10-14 6:59 ` Ingo Molnar
@ 2009-10-14 21:55 ` Frans Pop
1 sibling, 0 replies; 131+ messages in thread
From: Frans Pop @ 2009-10-14 21:55 UTC (permalink / raw)
To: David Rientjes
Cc: Linus Torvalds, Ingo Molnar, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Wednesday 14 October 2009, David Rientjes wrote:
> On Tue, 13 Oct 2009, Linus Torvalds wrote:
> > Let's keep the old behavior by making the AUTO option an three-way
> > choice ("none", "short", "auto"), and making sure that it actually
> > takes work to choose "none" (and that "make oldconfig" doesn't choose
> > it unless you explicitly made the choice before - so people who just
> > re-use old .config files wouldn't get "none" by mistake).
I'm working on a patch that implements this; will post it later.
> I don't think you want to do that because it would require the .config
> to be posted on bug reports, for example, to determine the setting of
> CONFIG_LOCALVERSION_AUTO before you can interpret the kernel version.
> In other words, you wouldn't know that "2.6.32-rc4" is actually 200
> commits beyond the actual release unless you also know that the .config
> has CONFIG_LOCALVERSION_AUTO="none".
Even with this patch you can never be 100% sure of that, for example
because you cannot be 100% certain that a kernel was built from a tree
that's under revision control. The most *any* change can do is increase
the likelyhood that we get that information in the version number.
Will explain more in a different reply later.
> Signed-off-by: David Rientjes <rientjes@google.com>
> ---
> Makefile | 32 ++++++++++++++++++++------------
> 1 files changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -898,9 +898,13 @@ $(vmlinux-dirs): prepare scripts
> # $(localver)
> # localversion* (files without backups, containing '~')
> # $(CONFIG_LOCALVERSION) (from kernel config setting)
> -# $(localver-auto) (only if CONFIG_LOCALVERSION_AUTO is set)
> -# ./scripts/setlocalversion (SCM tag, if one exists)
> -# $(LOCALVERSION) (from make command line if provided)
> +# $(LOCALVERSION) (from make command line, if provided)
> +# $(localver-extra)
> +# $(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 repository is at non-tagged commit)
> #
> # Note how the final $(localver-auto) string is included *only* if the
You forgot to change the $(localver-auto) here; and maybe also remove that
leading space in this line.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-12 19:57 ` [PATCH, v2] " Ingo Molnar
2009-10-12 22:04 ` Frans Pop
@ 2009-10-13 2:00 ` David Rientjes
2009-10-13 7:07 ` Ingo Molnar
2010-06-07 17:18 ` [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks Boaz Harrosh
2 siblings, 1 reply; 131+ messages in thread
From: David Rientjes @ 2009-10-13 2:00 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Frans Pop, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Mon, 12 Oct 2009, Ingo Molnar wrote:
> diff --git a/Makefile b/Makefile
> index 927d7a3..5dab509 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -963,8 +963,6 @@ localver = $(subst $(space),, $(string) \
> # .scmversion is used when generating rpm packages so we do not loose
> # the version information from the SCM when we do the build of the kernel
> # from the copied source
> -ifdef CONFIG_LOCALVERSION_AUTO
> -
> ifeq ($(wildcard .scmversion),)
> _localver-auto = $(shell $(CONFIG_SHELL) \
> $(srctree)/scripts/setlocalversion $(srctree))
> @@ -972,7 +970,14 @@ else
> _localver-auto = $(shell cat .scmversion 2> /dev/null)
> endif
>
> +ifdef CONFIG_LOCALVERSION_AUTO
> localver-auto = $(LOCALVERSION)$(_localver-auto)
> +else
> + ifeq ($_localver-auto,)
> + localver-auto = $(LOCALVERSION)
> + else
> + localver-auto = $(LOCALVERSION)+
> + endif
> endif
>
> localver-full = $(localver)$(localver-auto)
I don't see where the `+' is dropped between -rc tags;
scripts/setlocalversion should return -00000-rc5 for v2.6.32-rc5, for
example, so _localver-auto will always be non-NULL and the `+' is
appended.
I think scripts/setlocalversion should also be modified as I earlier
suggested to suppress output when git-describe shows no additional
commits beyond the tag. Then, CONFIG_LOCALVERSION_AUTO would not be
v2.6.32-rc4-00000-rc4, for example, when 2.6.32-rc4 is released.
Your patch also adds the make LOCALVERSION= string to the version without
requiring CONFIG_LOCALVERSION_AUTO. That's a change from prior behavior,
but I think it's helpful for user-specified version tags.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-13 2:00 ` David Rientjes
@ 2009-10-13 7:07 ` Ingo Molnar
2009-10-13 7:59 ` David Rientjes
0 siblings, 1 reply; 131+ messages in thread
From: Ingo Molnar @ 2009-10-13 7:07 UTC (permalink / raw)
To: David Rientjes
Cc: Linus Torvalds, Frans Pop, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
* David Rientjes <rientjes@google.com> wrote:
> On Mon, 12 Oct 2009, Ingo Molnar wrote:
>
> > diff --git a/Makefile b/Makefile
> > index 927d7a3..5dab509 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -963,8 +963,6 @@ localver = $(subst $(space),, $(string) \
> > # .scmversion is used when generating rpm packages so we do not loose
> > # the version information from the SCM when we do the build of the kernel
> > # from the copied source
> > -ifdef CONFIG_LOCALVERSION_AUTO
> > -
> > ifeq ($(wildcard .scmversion),)
> > _localver-auto = $(shell $(CONFIG_SHELL) \
> > $(srctree)/scripts/setlocalversion $(srctree))
> > @@ -972,7 +970,14 @@ else
> > _localver-auto = $(shell cat .scmversion 2> /dev/null)
> > endif
> >
> > +ifdef CONFIG_LOCALVERSION_AUTO
> > localver-auto = $(LOCALVERSION)$(_localver-auto)
> > +else
> > + ifeq ($_localver-auto,)
> > + localver-auto = $(LOCALVERSION)
> > + else
> > + localver-auto = $(LOCALVERSION)+
> > + endif
> > endif
> >
> > localver-full = $(localver)$(localver-auto)
>
> I don't see where the `+' is dropped between -rc tags;
> scripts/setlocalversion should return -00000-rc5 for v2.6.32-rc5, for
> example, so _localver-auto will always be non-NULL and the `+' is
> appended.
>
> I think scripts/setlocalversion should also be modified as I earlier
> suggested to suppress output when git-describe shows no additional
> commits beyond the tag. Then, CONFIG_LOCALVERSION_AUTO would not be
> v2.6.32-rc4-00000-rc4, for example, when 2.6.32-rc4 is released.
>
> Your patch also adds the make LOCALVERSION= string to the version
> without requiring CONFIG_LOCALVERSION_AUTO. That's a change from
> prior behavior, but I think it's helpful for user-specified version
> tags.
Good points - the patch is defective in its current form. Anyone
interested in fixing it? I'll be busy with other things.
Ingo
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic
2009-10-13 7:07 ` Ingo Molnar
@ 2009-10-13 7:59 ` David Rientjes
0 siblings, 0 replies; 131+ messages in thread
From: David Rientjes @ 2009-10-13 7:59 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Frans Pop, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Tue, 13 Oct 2009, Ingo Molnar wrote:
> > > diff --git a/Makefile b/Makefile
> > > index 927d7a3..5dab509 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -963,8 +963,6 @@ localver = $(subst $(space),, $(string) \
> > > # .scmversion is used when generating rpm packages so we do not loose
> > > # the version information from the SCM when we do the build of the kernel
> > > # from the copied source
> > > -ifdef CONFIG_LOCALVERSION_AUTO
> > > -
> > > ifeq ($(wildcard .scmversion),)
> > > _localver-auto = $(shell $(CONFIG_SHELL) \
> > > $(srctree)/scripts/setlocalversion $(srctree))
> > > @@ -972,7 +970,14 @@ else
> > > _localver-auto = $(shell cat .scmversion 2> /dev/null)
> > > endif
> > >
> > > +ifdef CONFIG_LOCALVERSION_AUTO
> > > localver-auto = $(LOCALVERSION)$(_localver-auto)
> > > +else
> > > + ifeq ($_localver-auto,)
> > > + localver-auto = $(LOCALVERSION)
> > > + else
> > > + localver-auto = $(LOCALVERSION)+
> > > + endif
> > > endif
> > >
> > > localver-full = $(localver)$(localver-auto)
> >
> > I don't see where the `+' is dropped between -rc tags;
> > scripts/setlocalversion should return -00000-rc5 for v2.6.32-rc5, for
> > example, so _localver-auto will always be non-NULL and the `+' is
> > appended.
> >
> > I think scripts/setlocalversion should also be modified as I earlier
> > suggested to suppress output when git-describe shows no additional
> > commits beyond the tag. Then, CONFIG_LOCALVERSION_AUTO would not be
> > v2.6.32-rc4-00000-rc4, for example, when 2.6.32-rc4 is released.
> >
> > Your patch also adds the make LOCALVERSION= string to the version
> > without requiring CONFIG_LOCALVERSION_AUTO. That's a change from
> > prior behavior, but I think it's helpful for user-specified version
> > tags.
>
> Good points - the patch is defective in its current form. Anyone
> interested in fixing it? I'll be busy with other things.
>
The patch itself is good, it just needs a change to
scripts/setlocalversion to suppress output when at a tagged commit.
scripts: suppress setlocalversion output if at tagged commit
It's unnecessary, even for CONFIG_LOCALVERSION_AUTO configs, to append
the "git describe" output to the version string if there are no revisions
beyond a tagged commit.
When the git respository was at the v2.6.32-rc4 tagged commit, for
example, the previous code would output "-00000-rc4," which is
unnecessary.
The comment in scripts/setlocalversion pertaining to this behavior need
not be changed since the implementation now conforms to the description.
Signed-off-by: David Rientjes <rientjes@google.com>
---
scripts/setlocalversion | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -26,7 +26,8 @@ if head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
# If we are past a tagged commit (like "v2.6.30-rc5-302-g72357d5"),
# we pretty print it.
if atag="`git describe 2>/dev/null`"; then
- echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'
+ echo "$atag" | awk -F- 'int($(NF-1)) > 0 \
+ {printf("-%05d-%s", $(NF-1),$(NF))}'
# If we don't have a tag at all we print -g{commitish}.
else
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks
2009-10-12 19:57 ` [PATCH, v2] " Ingo Molnar
2009-10-12 22:04 ` Frans Pop
2009-10-13 2:00 ` David Rientjes
@ 2010-06-07 17:18 ` Boaz Harrosh
2010-06-07 19:45 ` David Rientjes
2 siblings, 1 reply; 131+ messages in thread
From: Boaz Harrosh @ 2010-06-07 17:18 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Frans Pop, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On 10/12/2009 09:57 PM, Ingo Molnar wrote:
>
> This is basically your original patch that adds '+' to the short version
> string of kernels that are 'between' -rc tags. (i dropped the '+' within
> the long version i did in v1 - there were objections against that)
>
> Would this be ok?
>
Rrrr. If I wanted CONFIG_LOCALVERSION_AUTO, I would use that one. At least
it is actually useful and informative.
I already have my:
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 35
-EXTRAVERSION = -rc2
+EXTRAVERSION = -rc2-my_tree
Which is managed by a git tree (for everybody based on my tree)
At least give us a way out with:
CONFIG_LOCALVERSION_NO_AUTO_IM_REALLY_STUPID=y way out.
or EXTRAVERSION != $(git version)
But don't leave us cold in the woods like that. (What if I remove the git tree altogether, move to svn)
If I can shoot my self in the foot, it does not mean Government should not issue any more
gun licenses.
I already have my outer Makefile system that makes sure I don't forget to compile, or
"did I install this Kernel or not". Please let us have a way out?
Boaz
> Ingo
>
> -------------->
>>From 597e5b15dd0cbb3158afc438e5edae9986e6b76a Mon Sep 17 00:00:00 2001
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Tue, 6 Oct 2009 09:31:03 -0700
> Subject: [PATCH] kbuild: Improve version string logic
>
> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> way:
>
> - if it is set, things work the way they always have, and you get a
> extended kernel release like:
>
> 2.6.32-rc3-00052-g0eca52a
>
> - but if it is _not_ set, we'll still try to get a version from the
> underlying SCM (we actually support git, hg and SVN right now, even if
> some comments may say "git only"), and if the underlying SCM says it
> has a local version, we append just "+", so you get a version number
> like:
>
> 2.6.32-rc3+
>
> IOW, you'd never get 2.6.32-rc0, but you'd get either the complex git
> version number (or SVN/hg/whatever), or at least "2.6.31+" with the "+"
> showing that it is more than plain 2.6.31.
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> Cc: Frans Pop <elendil@planet.nl>
> Cc: Dirk Hohndel <hohndel@infradead.org>
> Cc: Len Brown <lenb@kernel.org>
> LKML-Reference: <20091006173508.GA4786@elte.hu>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
> Makefile | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 927d7a3..5dab509 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -963,8 +963,6 @@ localver = $(subst $(space),, $(string) \
> # .scmversion is used when generating rpm packages so we do not loose
> # the version information from the SCM when we do the build of the kernel
> # from the copied source
> -ifdef CONFIG_LOCALVERSION_AUTO
> -
> ifeq ($(wildcard .scmversion),)
> _localver-auto = $(shell $(CONFIG_SHELL) \
> $(srctree)/scripts/setlocalversion $(srctree))
> @@ -972,7 +970,14 @@ else
> _localver-auto = $(shell cat .scmversion 2> /dev/null)
> endif
>
> +ifdef CONFIG_LOCALVERSION_AUTO
> localver-auto = $(LOCALVERSION)$(_localver-auto)
> +else
> + ifeq ($_localver-auto,)
> + localver-auto = $(LOCALVERSION)
> + else
> + localver-auto = $(LOCALVERSION)+
> + endif
> endif
>
> localver-full = $(localver)$(localver-auto)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks
2010-06-07 17:18 ` [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks Boaz Harrosh
@ 2010-06-07 19:45 ` David Rientjes
2010-06-08 5:52 ` Boaz Harrosh
2010-06-08 8:31 ` kbuild: Fix the breakage caused by "improve version string logic" Boaz Harrosh
0 siblings, 2 replies; 131+ messages in thread
From: David Rientjes @ 2010-06-07 19:45 UTC (permalink / raw)
To: Boaz Harrosh
Cc: Ingo Molnar, Linus Torvalds, Frans Pop, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Mon, 7 Jun 2010, Boaz Harrosh wrote:
> Rrrr. If I wanted CONFIG_LOCALVERSION_AUTO, I would use that one. At least
> it is actually useful and informative.
>
> I already have my:
> VERSION = 2
> PATCHLEVEL = 6
> SUBLEVEL = 35
> -EXTRAVERSION = -rc2
> +EXTRAVERSION = -rc2-my_tree
>
You shouldn't be using EXTRAVERSION for this purpose, you should be
passing LOCALVERSION=my_tree to make.
> Which is managed by a git tree (for everybody based on my tree)
>
> At least give us a way out with:
> CONFIG_LOCALVERSION_NO_AUTO_IM_REALLY_STUPID=y way out.
>
> or EXTRAVERSION != $(git version)
>
> But don't leave us cold in the woods like that. (What if I remove the git tree altogether, move to svn)
>
> If I can shoot my self in the foot, it does not mean Government should not issue any more
> gun licenses.
>
> I already have my outer Makefile system that makes sure I don't forget to compile, or
> "did I install this Kernel or not". Please let us have a way out?
>
Unless it's a vanilla 2.6.35-rc2 kernel, it's inaccurate to persent it as
2.6.35-rc2; you'll need to pass LOCALVERSION to make to identify this as a
non-vanilla kernel.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks
2010-06-07 19:45 ` David Rientjes
@ 2010-06-08 5:52 ` Boaz Harrosh
2010-06-08 6:18 ` David Rientjes
2010-06-08 8:31 ` kbuild: Fix the breakage caused by "improve version string logic" Boaz Harrosh
1 sibling, 1 reply; 131+ messages in thread
From: Boaz Harrosh @ 2010-06-08 5:52 UTC (permalink / raw)
To: David Rientjes
Cc: Ingo Molnar, Linus Torvalds, Frans Pop, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On 06/07/2010 10:45 PM, David Rientjes wrote:
> On Mon, 7 Jun 2010, Boaz Harrosh wrote:
>
>> Rrrr. If I wanted CONFIG_LOCALVERSION_AUTO, I would use that one. At least
>> it is actually useful and informative.
>>
>> I already have my:
>> VERSION = 2
>> PATCHLEVEL = 6
>> SUBLEVEL = 35
>> -EXTRAVERSION = -rc2
>> +EXTRAVERSION = -rc2-my_tree
>>
>
> You shouldn't be using EXTRAVERSION for this purpose, you should be
> passing LOCALVERSION=my_tree to make.
>
That will not work because the way I run make is out of my control. Every
one in the working group has his system. The Makefile is part of the
public git tree, so every one will get the same identification without
any confusion with Vanilla kernel, or what was compiled.
>> Which is managed by a git tree (for everybody based on my tree)
>>
>> At least give us a way out with:
>> CONFIG_LOCALVERSION_NO_AUTO_IM_REALLY_STUPID=y way out.
>>
>> or EXTRAVERSION != $(git version)
>>
>> But don't leave us cold in the woods like that. (What if I remove the git tree altogether, move to svn)
>>
>> If I can shoot my self in the foot, it does not mean Government should not issue any more
>> gun licenses.
>>
>> I already have my outer Makefile system that makes sure I don't forget to compile, or
>> "did I install this Kernel or not". Please let us have a way out?
>>
>
> Unless it's a vanilla 2.6.35-rc2 kernel, it's inaccurate to persent it as
> 2.6.35-rc2; you'll need to pass LOCALVERSION to make to identify this as a
> non-vanilla kernel.
What are we lawyers? come on. And I do not have that problem! The output will
not be 2.6.35-rc2 as you fear. It will be 2.6.35-rc2-my-tree-my-version.
A person is checking out my tree will get my version string and the output
name is well defined, and separate from Vanilla Kernel. So even the layers are
happy. (That said, insert the: "I have a right to be stupid ..." mantra)
I don't get it. What is that CONFIG_LOCALVERSION_AUTO. It has become a *no-choice*
option. The system now tells me: "I will poke in your system, if I find it under git,
I slave it. Your choice is to have an ugly "+" sign or a more informative name based
on actual commit number". But that is no-choice don't you see?
Please stop this *none-sense* this is not your place to mandate my Kernel name. If
I'm forced to have an external Makefile I can just "mv" what ever name I choose.
The Kernel name is an ABI you have just broken that, You must revert it ASAP.
Boaz !
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks
2010-06-08 5:52 ` Boaz Harrosh
@ 2010-06-08 6:18 ` David Rientjes
2010-06-08 6:34 ` Paul Mundt
2010-06-08 6:37 ` Boaz Harrosh
0 siblings, 2 replies; 131+ messages in thread
From: David Rientjes @ 2010-06-08 6:18 UTC (permalink / raw)
To: Boaz Harrosh
Cc: Ingo Molnar, Linus Torvalds, Frans Pop, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Tue, 8 Jun 2010, Boaz Harrosh wrote:
> >> I already have my:
> >> VERSION = 2
> >> PATCHLEVEL = 6
> >> SUBLEVEL = 35
> >> -EXTRAVERSION = -rc2
> >> +EXTRAVERSION = -rc2-my_tree
> >>
> >
> > You shouldn't be using EXTRAVERSION for this purpose, you should be
> > passing LOCALVERSION=my_tree to make.
> >
>
> That will not work because the way I run make is out of my control. Every
> one in the working group has his system. The Makefile is part of the
> public git tree, so every one will get the same identification without
> any confusion with Vanilla kernel, or what was compiled.
>
If everyone using that tree wants the same version string for that kernel,
use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make
LOCALVERSION=".
> > Unless it's a vanilla 2.6.35-rc2 kernel, it's inaccurate to persent it as
> > 2.6.35-rc2; you'll need to pass LOCALVERSION to make to identify this as a
> > non-vanilla kernel.
>
> What are we lawyers? come on. And I do not have that problem! The output will
> not be 2.6.35-rc2 as you fear. It will be 2.6.35-rc2-my-tree-my-version.
That's because you're using EXTRAVERSION which is also used upstream to
describe kernel releases (stable, rc, mm, etc).
> Please stop this *none-sense* this is not your place to mandate my Kernel name. If
> I'm forced to have an external Makefile I can just "mv" what ever name I choose.
> The Kernel name is an ABI you have just broken that, You must revert it ASAP.
>
You still have the tools available to do everything you once did.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks
2010-06-08 6:18 ` David Rientjes
@ 2010-06-08 6:34 ` Paul Mundt
2010-06-08 6:39 ` Boaz Harrosh
2010-06-08 6:37 ` Boaz Harrosh
1 sibling, 1 reply; 131+ messages in thread
From: Paul Mundt @ 2010-06-08 6:34 UTC (permalink / raw)
To: David Rientjes
Cc: Boaz Harrosh, Ingo Molnar, Linus Torvalds, Frans Pop,
Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On Mon, Jun 07, 2010 at 11:18:42PM -0700, David Rientjes wrote:
> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>
> > >> I already have my:
> > >> VERSION = 2
> > >> PATCHLEVEL = 6
> > >> SUBLEVEL = 35
> > >> -EXTRAVERSION = -rc2
> > >> +EXTRAVERSION = -rc2-my_tree
> > >>
> > >
> > > You shouldn't be using EXTRAVERSION for this purpose, you should be
> > > passing LOCALVERSION=my_tree to make.
> > >
> >
> > That will not work because the way I run make is out of my control. Every
> > one in the working group has his system. The Makefile is part of the
> > public git tree, so every one will get the same identification without
> > any confusion with Vanilla kernel, or what was compiled.
> >
>
> If everyone using that tree wants the same version string for that kernel,
> use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make
> LOCALVERSION=".
>
Or just distribute a localversion-my_tree file in the top-level directory
like other trees do. This doesn't strike me as a particularly significant
problem.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks
2010-06-08 6:34 ` Paul Mundt
@ 2010-06-08 6:39 ` Boaz Harrosh
2010-06-08 7:16 ` Boaz Harrosh
0 siblings, 1 reply; 131+ messages in thread
From: Boaz Harrosh @ 2010-06-08 6:39 UTC (permalink / raw)
To: Paul Mundt
Cc: David Rientjes, Ingo Molnar, Linus Torvalds, Frans Pop,
Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On 06/08/2010 09:34 AM, Paul Mundt wrote:
> On Mon, Jun 07, 2010 at 11:18:42PM -0700, David Rientjes wrote:
>> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>>
>>>>> I already have my:
>>>>> VERSION = 2
>>>>> PATCHLEVEL = 6
>>>>> SUBLEVEL = 35
>>>>> -EXTRAVERSION = -rc2
>>>>> +EXTRAVERSION = -rc2-my_tree
>>>>>
>>>>
>>>> You shouldn't be using EXTRAVERSION for this purpose, you should be
>>>> passing LOCALVERSION=my_tree to make.
>>>>
>>>
>>> That will not work because the way I run make is out of my control. Every
>>> one in the working group has his system. The Makefile is part of the
>>> public git tree, so every one will get the same identification without
>>> any confusion with Vanilla kernel, or what was compiled.
>>>
>>
>> If everyone using that tree wants the same version string for that kernel,
>> use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make
>> LOCALVERSION=".
>>
> Or just distribute a localversion-my_tree file in the top-level directory
> like other trees do. This doesn't strike me as a particularly significant
> problem.
OK That one is actually a solution. I'll try that ASAP. If it works as expected
it's perfect. Even better than before
Thanks
Boaz
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks
2010-06-08 6:39 ` Boaz Harrosh
@ 2010-06-08 7:16 ` Boaz Harrosh
2010-06-08 7:21 ` Paul Mundt
2010-06-08 7:21 ` Boaz Harrosh
0 siblings, 2 replies; 131+ messages in thread
From: Boaz Harrosh @ 2010-06-08 7:16 UTC (permalink / raw)
To: Paul Mundt
Cc: David Rientjes, Ingo Molnar, Linus Torvalds, Frans Pop,
Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On 06/08/2010 09:39 AM, Boaz Harrosh wrote:
> On 06/08/2010 09:34 AM, Paul Mundt wrote:
>> On Mon, Jun 07, 2010 at 11:18:42PM -0700, David Rientjes wrote:
>>> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>>>
>>>>>> I already have my:
>>>>>> VERSION = 2
>>>>>> PATCHLEVEL = 6
>>>>>> SUBLEVEL = 35
>>>>>> -EXTRAVERSION = -rc2
>>>>>> +EXTRAVERSION = -rc2-my_tree
>>>>>>
>>>>>
>>>>> You shouldn't be using EXTRAVERSION for this purpose, you should be
>>>>> passing LOCALVERSION=my_tree to make.
>>>>>
>>>>
>>>> That will not work because the way I run make is out of my control. Every
>>>> one in the working group has his system. The Makefile is part of the
>>>> public git tree, so every one will get the same identification without
>>>> any confusion with Vanilla kernel, or what was compiled.
>>>>
>>>
>>> If everyone using that tree wants the same version string for that kernel,
>>> use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make
>>> LOCALVERSION=".
>>>
>> Or just distribute a localversion-my_tree file in the top-level directory
>> like other trees do. This doesn't strike me as a particularly significant
>> problem.
>
I can't manage to work this out. Here is what I did please, what did I do wrong:
[my-tree] $ git checkout v2.6.35-rc2
[my-tree] $ touch localversion-my_tree
[my-tree] $ git add localversion-my_tree; git commit; # ...
[my-tree] $ make oldconfig
[my-tree] $ make
At my make install I still get DEPMOD 2.6.35-rc2+
What else to do?
Thanks
Boaz
> OK That one is actually a solution. I'll try that ASAP. If it works as expected
> it's perfect. Even better than before
>
> Thanks
> Boaz
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks
2010-06-08 7:16 ` Boaz Harrosh
@ 2010-06-08 7:21 ` Paul Mundt
2010-06-08 7:21 ` Boaz Harrosh
1 sibling, 0 replies; 131+ messages in thread
From: Paul Mundt @ 2010-06-08 7:21 UTC (permalink / raw)
To: Boaz Harrosh
Cc: David Rientjes, Ingo Molnar, Linus Torvalds, Frans Pop,
Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On Tue, Jun 08, 2010 at 10:16:39AM +0300, Boaz Harrosh wrote:
> On 06/08/2010 09:39 AM, Boaz Harrosh wrote:
> > On 06/08/2010 09:34 AM, Paul Mundt wrote:
> >> On Mon, Jun 07, 2010 at 11:18:42PM -0700, David Rientjes wrote:
> >>> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
> >>>
> >>>>>> I already have my:
> >>>>>> VERSION = 2
> >>>>>> PATCHLEVEL = 6
> >>>>>> SUBLEVEL = 35
> >>>>>> -EXTRAVERSION = -rc2
> >>>>>> +EXTRAVERSION = -rc2-my_tree
> >>>>>>
> >>>>>
> >>>>> You shouldn't be using EXTRAVERSION for this purpose, you should be
> >>>>> passing LOCALVERSION=my_tree to make.
> >>>>>
> >>>>
> >>>> That will not work because the way I run make is out of my control. Every
> >>>> one in the working group has his system. The Makefile is part of the
> >>>> public git tree, so every one will get the same identification without
> >>>> any confusion with Vanilla kernel, or what was compiled.
> >>>>
> >>>
> >>> If everyone using that tree wants the same version string for that kernel,
> >>> use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make
> >>> LOCALVERSION=".
> >>>
> >> Or just distribute a localversion-my_tree file in the top-level directory
> >> like other trees do. This doesn't strike me as a particularly significant
> >> problem.
> >
>
>
> I can't manage to work this out. Here is what I did please, what did I do wrong:
> [my-tree] $ git checkout v2.6.35-rc2
> [my-tree] $ touch localversion-my_tree
It's not frightfully intuitive, you have to have the string in the file.
So simply doing:
$ echo "-my_tree" > localversion-my_tree
ought to work fine for your case.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks
2010-06-08 7:16 ` Boaz Harrosh
2010-06-08 7:21 ` Paul Mundt
@ 2010-06-08 7:21 ` Boaz Harrosh
2010-06-08 7:32 ` Paul Mundt
1 sibling, 1 reply; 131+ messages in thread
From: Boaz Harrosh @ 2010-06-08 7:21 UTC (permalink / raw)
To: Paul Mundt
Cc: David Rientjes, Ingo Molnar, Linus Torvalds, Frans Pop,
Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On 06/08/2010 10:16 AM, Boaz Harrosh wrote:
> On 06/08/2010 09:39 AM, Boaz Harrosh wrote:
>> On 06/08/2010 09:34 AM, Paul Mundt wrote:
>>> On Mon, Jun 07, 2010 at 11:18:42PM -0700, David Rientjes wrote:
>>>> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>>>>
>>>>>>> I already have my:
>>>>>>> VERSION = 2
>>>>>>> PATCHLEVEL = 6
>>>>>>> SUBLEVEL = 35
>>>>>>> -EXTRAVERSION = -rc2
>>>>>>> +EXTRAVERSION = -rc2-my_tree
>>>>>>>
>>>>>>
>>>>>> You shouldn't be using EXTRAVERSION for this purpose, you should be
>>>>>> passing LOCALVERSION=my_tree to make.
>>>>>>
>>>>>
>>>>> That will not work because the way I run make is out of my control. Every
>>>>> one in the working group has his system. The Makefile is part of the
>>>>> public git tree, so every one will get the same identification without
>>>>> any confusion with Vanilla kernel, or what was compiled.
>>>>>
>>>>
>>>> If everyone using that tree wants the same version string for that kernel,
>>>> use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make
>>>> LOCALVERSION=".
>>>>
>>> Or just distribute a localversion-my_tree file in the top-level directory
>>> like other trees do. This doesn't strike me as a particularly significant
>>> problem.
>>
>
>
> I can't manage to work this out. Here is what I did please, what did I do wrong:
> [my-tree] $ git checkout v2.6.35-rc2
> [my-tree] $ touch localversion-my_tree
OK I get it above should be:
[my-tree] $ echo "-my_tree" > localversion-my_tree
But now I get DEPMOD 2.6.35-rc2-my_tree+
Please fix it so if localversion* is present then the plus is
removed. And the git is not inspected
Boaz
> [my-tree] $ git add localversion-my_tree; git commit; # ...
> [my-tree] $ make oldconfig
> [my-tree] $ make
>
> At my make install I still get DEPMOD 2.6.35-rc2+
>
> What else to do?
>
> Thanks
> Boaz
>
>> OK That one is actually a solution. I'll try that ASAP. If it works as expected
>> it's perfect. Even better than before
>>
>> Thanks
>> Boaz
>
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks
2010-06-08 7:21 ` Boaz Harrosh
@ 2010-06-08 7:32 ` Paul Mundt
2010-06-08 7:52 ` Boaz Harrosh
0 siblings, 1 reply; 131+ messages in thread
From: Paul Mundt @ 2010-06-08 7:32 UTC (permalink / raw)
To: Boaz Harrosh
Cc: David Rientjes, Ingo Molnar, Linus Torvalds, Frans Pop,
Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On Tue, Jun 08, 2010 at 10:21:54AM +0300, Boaz Harrosh wrote:
> On 06/08/2010 10:16 AM, Boaz Harrosh wrote:
> OK I get it above should be:
> [my-tree] $ echo "-my_tree" > localversion-my_tree
>
> But now I get DEPMOD 2.6.35-rc2-my_tree+
>
> Please fix it so if localversion* is present then the plus is
> removed. And the git is not inspected
>
How is that a 'fix'? If I'm using localversion* and have people sending
me bug reports, I still do want to see the git ID. The + thing in this
context might not have any meaning since the 2.6.35-rc2 that you've
tagged for your tree and the release one could wildly differ, but that's
more of an argument against the + thing existing at all than anything
else.
Whether having LOCALVERSION_AUTO be compulsory is a good idea or not is
another matter entirely, the localversion* semantics are pretty
clear-cut.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks
2010-06-08 7:32 ` Paul Mundt
@ 2010-06-08 7:52 ` Boaz Harrosh
2010-06-08 9:17 ` David Rientjes
0 siblings, 1 reply; 131+ messages in thread
From: Boaz Harrosh @ 2010-06-08 7:52 UTC (permalink / raw)
To: Paul Mundt
Cc: David Rientjes, Ingo Molnar, Linus Torvalds, Frans Pop,
Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On 06/08/2010 10:32 AM, Paul Mundt wrote:
> On Tue, Jun 08, 2010 at 10:21:54AM +0300, Boaz Harrosh wrote:
>> On 06/08/2010 10:16 AM, Boaz Harrosh wrote:
>> OK I get it above should be:
>> [my-tree] $ echo "-my_tree" > localversion-my_tree
>>
>> But now I get DEPMOD 2.6.35-rc2-my_tree+
>>
>> Please fix it so if localversion* is present then the plus is
>> removed. And the git is not inspected
>>
> How is that a 'fix'? If I'm using localversion* and have people sending
> me bug reports, I still do want to see the git ID. The + thing in this
> context might not have any meaning since the 2.6.35-rc2 that you've
> tagged for your tree and the release one could wildly differ, but that's
> more of an argument against the + thing existing at all than anything
> else.
>
You lost me sorry. I don't understand what you are saying ?
> Whether having LOCALVERSION_AUTO be compulsory is a good idea or not is
> another matter entirely, the localversion* semantics are pretty
> clear-cut.
the "localversion* semantics" is not the issue here. The issue is the
CONFIG_LOCALVERSION_AUTO semantics. You have effectively made it compulsory
but with a choice of a style. "From the frying pan to the fire"
And you have broken the "localversion* semantics". Because my vanilla release
is 2.6.rc2-my_tree-my_ver as checkedout and delivered from my official tree.
Now you have added a "+" regardless of if it is an official tagged version or
not.
I do not expect a complicated "let me be smarter than you" system that
checks any tags of mine and provides an out-of-tree version system. I just
want a switch that tells the system. "Let me shoot myself in the leg,
I know what I want"
"localversion*" should override any automatism as an indication of an
alternative tagging system. (Or any other switch that can turn this off)
And please stop the politics: "having LOCALVERSION_AUTO be compulsory" is
Politics not, anything technical: "how to support my needs"
Boaz
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks
2010-06-08 7:52 ` Boaz Harrosh
@ 2010-06-08 9:17 ` David Rientjes
0 siblings, 0 replies; 131+ messages in thread
From: David Rientjes @ 2010-06-08 9:17 UTC (permalink / raw)
To: Boaz Harrosh
Cc: Paul Mundt, Ingo Molnar, Linus Torvalds, Frans Pop, Dirk Hohndel,
Len Brown, Linux Kernel Mailing List
On Tue, 8 Jun 2010, Boaz Harrosh wrote:
> And you have broken the "localversion* semantics". Because my vanilla release
> is 2.6.rc2-my_tree-my_ver as checkedout and delivered from my official tree.
> Now you have added a "+" regardless of if it is an official tagged version or
> not.
>
The `+' modifies the base kernel version, not the version string.
Otherwise, it would be impossible to determine whether a "2.6.35-rc2-foo"
kernel were vanilla 2.6.35-rc2 or otherwise modified.
> I do not expect a complicated "let me be smarter than you" system that
> checks any tags of mine and provides an out-of-tree version system. I just
> want a switch that tells the system. "Let me shoot myself in the leg,
> I know what I want"
>
If you're using git, which you obviously are, then add localversion* files
to your repository (or modify CONFIG_LOCALVERSION if you pass along your
.config as well) and use git-tag to indicate its something you're
releasing as your kernel.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: [PATCH, v2] kbuild: Improve version string logic - two for the price of one - No thanks
2010-06-08 6:18 ` David Rientjes
2010-06-08 6:34 ` Paul Mundt
@ 2010-06-08 6:37 ` Boaz Harrosh
1 sibling, 0 replies; 131+ messages in thread
From: Boaz Harrosh @ 2010-06-08 6:37 UTC (permalink / raw)
To: David Rientjes
Cc: Ingo Molnar, Linus Torvalds, Frans Pop, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On 06/08/2010 09:18 AM, David Rientjes wrote:
> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>
>>>> I already have my:
>>>> VERSION = 2
>>>> PATCHLEVEL = 6
>>>> SUBLEVEL = 35
>>>> -EXTRAVERSION = -rc2
>>>> +EXTRAVERSION = -rc2-my_tree
>>>>
>>>
>>> You shouldn't be using EXTRAVERSION for this purpose, you should be
>>> passing LOCALVERSION=my_tree to make.
>>>
>>
>> That will not work because the way I run make is out of my control. Every
>> one in the working group has his system. The Makefile is part of the
>> public git tree, so every one will get the same identification without
>> any confusion with Vanilla kernel, or what was compiled.
>>
>
> If everyone using that tree wants the same version string for that kernel,
> use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make
> LOCALVERSION=".
That does not work I tried LOCALVERSION is checked for emptiness. So the
"plus" is added just the same. I tried:
$ make # gets a plus
$ make LOCALVERSION="" # same plus
CONFIG_LOCALVERSION will not work because it, too, is not in the git. I need
something that everyone can get by checkout. (The config file is usually a
distro config with make oldconfig)
>
>>> Unless it's a vanilla 2.6.35-rc2 kernel, it's inaccurate to persent it as
>>> 2.6.35-rc2; you'll need to pass LOCALVERSION to make to identify this as a
>>> non-vanilla kernel.
>>
>> What are we lawyers? come on. And I do not have that problem! The output will
>> not be 2.6.35-rc2 as you fear. It will be 2.6.35-rc2-my-tree-my-version.
>
> That's because you're using EXTRAVERSION which is also used upstream to
> describe kernel releases (stable, rc, mm, etc).
>
That's why it is perfect. Because I have that patch as first in my tree that
changes that in Makefile. Then from time to time when I rebase I get the
conflict with Linus change of the name, and have the privilege to specify how
this is a different tree, with a different name and version. It is all git work
no external factors. (That I will keep, regardless of plus or no plus)
And you have not answered my question:
What does the CONFIG_LOCALVERSION_AUTO give me? the name is changed regardless
so now it has become. Min-Auto-Name or Informative-Auto-Name. It used to be
Auto-name-yes or Auto-Name-no. Please change the config name to reflect the choice
we actually have. (And keep the old config because we need the original choice)
>> Please stop this *none-sense* this is not your place to mandate my Kernel name. If
>> I'm forced to have an external Makefile I can just "mv" what ever name I choose.
>> The Kernel name is an ABI you have just broken that, You must revert it ASAP.
>>
>
> You still have the tools available to do everything you once did.
No! how? I couldn't find how please specify exact commands to use.
Boaz
^ permalink raw reply [flat|nested] 131+ messages in thread
* kbuild: Fix the breakage caused by "improve version string logic"
2010-06-07 19:45 ` David Rientjes
2010-06-08 5:52 ` Boaz Harrosh
@ 2010-06-08 8:31 ` Boaz Harrosh
2010-06-08 9:13 ` David Rientjes
1 sibling, 1 reply; 131+ messages in thread
From: Boaz Harrosh @ 2010-06-08 8:31 UTC (permalink / raw)
To: David Rientjes, Linus Torvalds
Cc: Ingo Molnar, Frans Pop, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
The patch: 85a256d8e0116c8f5ad276730830f5d4d473344d
Author: David Rientjes <rientjes@google.com>
Title: kbuild: improve version string logic
Broke none Linus trees that supply their own version string and
tag system via a presence of a localversion* file at the Kernel's
root subdirectory.
After This patch. The "+" (plus) is not added if a localversion*
file is present or a CONFIG_LOCALVERSION is configured.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
---
Makefile | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 654c31a..324a413 100644
--- a/Makefile
+++ b/Makefile
@@ -945,7 +945,9 @@ ifdef CONFIG_LOCALVERSION_AUTO
else
ifneq ($(scm-identifier),)
ifeq ($(LOCALVERSION),)
- localver-extra = +
+ ifeq ($(localver),)
+ localver-extra = +
+ endif
endif
endif
endif
--
1.6.6.1
^ permalink raw reply related [flat|nested] 131+ messages in thread
* Re: kbuild: Fix the breakage caused by "improve version string logic"
2010-06-08 8:31 ` kbuild: Fix the breakage caused by "improve version string logic" Boaz Harrosh
@ 2010-06-08 9:13 ` David Rientjes
2010-06-08 10:14 ` Boaz Harrosh
0 siblings, 1 reply; 131+ messages in thread
From: David Rientjes @ 2010-06-08 9:13 UTC (permalink / raw)
To: Boaz Harrosh
Cc: Linus Torvalds, Ingo Molnar, Frans Pop, Dirk Hohndel, Len Brown,
linux-kernel
On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>
> The patch: 85a256d8e0116c8f5ad276730830f5d4d473344d
> Author: David Rientjes <rientjes@google.com>
> Title: kbuild: improve version string logic
>
> Broke none Linus trees that supply their own version string and
> tag system via a presence of a localversion* file at the Kernel's
> root subdirectory.
>
> After This patch. The "+" (plus) is not added if a localversion*
> file is present or a CONFIG_LOCALVERSION is configured.
>
The only reason the `+' is being appended to your version string is
because your scm is reporting that there have been commits to the tree
since the last release; for git, that means anything that isn't at a
tagged commit.
If you were to create a tarball of your tree, for instance, and distribute
it to someone else, there would be no appended `+' because there is no
revision history. The `+' being appended simply implies that you're
beyond the base kernel version in an scm. The motivation is to be more
descriptive about what kernel is being run: the most common case where
this comes into play is when someone is running a kernel off of Linus'
tree and a bug report incorrectly shows that it is a vanilla 2.6.35-rc2
kernel, for instance.
When we discussed adding this indicator of revision history, we explicitly
noted that the `+' is a modification of the base kernel version, not the
entire string.
As mentioned previously, you can easily suppress that from being added by
using "make LOCALVERSION=-foo" to create a 2.6.35-rc2-foo kernel when you
do not have CONFIG_LOCALVERSION_AUTO enabled. You already found that you
cannot pass an empty LOCALVERSION string, so it must be something to
identify itself as unique from vanilla 2.6.35-rc2.
The usecase that you've cited before is your colleagues pulling your git
tree and then getting this `+' appended when they really don't want it.
Although localversion* files are better than (ab)using the EXTRAVERSION
variable in the Makefile, they won't suppress the `+' because your
revision history shows that you're beyond a released (tagged) kernel. The
solution is to use git-tag to indicate your particular version of Linux
that differentiates it from vanilla 2.6.35-rc2 and pass along your version
information with either localversion* files or CONFIG_LOCALVERSION if you
package your .config as well.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: kbuild: Fix the breakage caused by "improve version string logic"
2010-06-08 9:13 ` David Rientjes
@ 2010-06-08 10:14 ` Boaz Harrosh
2010-06-08 10:19 ` Boaz Harrosh
2010-06-09 6:55 ` David Rientjes
0 siblings, 2 replies; 131+ messages in thread
From: Boaz Harrosh @ 2010-06-08 10:14 UTC (permalink / raw)
To: David Rientjes
Cc: Linus Torvalds, Ingo Molnar, Frans Pop, Dirk Hohndel, Len Brown,
linux-kernel
On 06/08/2010 12:13 PM, David Rientjes wrote:
> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>
>>
>> The patch: 85a256d8e0116c8f5ad276730830f5d4d473344d
>> Author: David Rientjes <rientjes@google.com>
>> Title: kbuild: improve version string logic
>>
>> Broke none Linus trees that supply their own version string and
>> tag system via a presence of a localversion* file at the Kernel's
>> root subdirectory.
>>
>> After This patch. The "+" (plus) is not added if a localversion*
>> file is present or a CONFIG_LOCALVERSION is configured.
>>
>
> The only reason the `+' is being appended to your version string is
> because your scm is reporting that there have been commits to the tree
> since the last release; for git, that means anything that isn't at a
> tagged commit.
>
What is a tagged commit:
[my_tree] $ git branch
*master
[my_tree] $ git tag v2.6.35-rc2-my-tree
[my_tree] $ cat localversion-my-tree
-my-tree
I still get: DEPMOD 2.6.35-rc2-my-tree+
How to solve? please specify.
> If you were to create a tarball of your tree, for instance, and distribute
> it to someone else, there would be no appended `+' because there is no
> revision history. The `+' being appended simply implies that you're
> beyond the base kernel version in an scm. The motivation is to be more
> descriptive about what kernel is being run: the most common case where
> this comes into play is when someone is running a kernel off of Linus'
> tree and a bug report incorrectly shows that it is a vanilla 2.6.35-rc2
> kernel, for instance.
>
In the Linus case there is CONFIG_LOCALVERSION_AUTO=y by default for this.
In my tree there is 2.6.35-rc2-my-tree so it cannot be mistaken with
Linus tree.
CONFIG_LOCALVERSION_AUTO=n was: "Even if I have an SCM, please do not
inspect it."
I need that back
> When we discussed adding this indicator of revision history, we explicitly
> noted that the `+' is a modification of the base kernel version, not the
> entire string.
>
My base "kernel version" is 2.6.35-rc2-my-tree. There cannot be any mistake
where this tree came from. How do I get rid of the "+"?
> As mentioned previously, you can easily suppress that from being added by
> using "make LOCALVERSION=-foo" to create a 2.6.35-rc2-foo kernel when you
> do not have CONFIG_LOCALVERSION_AUTO enabled. You already found that you
> cannot pass an empty LOCALVERSION string, so it must be something to
> identify itself as unique from vanilla 2.6.35-rc2.
>
As mentioned previously this is not an option I do not have git control
over how this gets compiled.
> The usecase that you've cited before is your colleagues pulling your git
> tree and then getting this `+' appended when they really don't want it.
Yes
> Although localversion* files are better than (ab)using the EXTRAVERSION
> variable in the Makefile, they won't suppress the `+' because your
> revision history shows that you're beyond a released (tagged) kernel.
I'm now using localversion-my-tree file. It is much better thanks.
What else do I need to do so clean checkout of my tree will not have
the "+" appended. It already have the my-tree appended to it.
> The solution is to use git-tag to indicate your particular version of Linux
> that differentiates it from vanilla 2.6.35-rc2 and pass along your version
> information with either localversion*
I tried that. Only with my patch it works. Hence the patch.
files or CONFIG_LOCALVERSION if you
> package your .config as well.
Again not an option .config is derived from a distro one and is not managed
by git.
Please find me a solution? this breaks lots of stuff un-necessarily and with
no apparent gain.
Thanks
Boaz
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: kbuild: Fix the breakage caused by "improve version string logic"
2010-06-08 10:14 ` Boaz Harrosh
@ 2010-06-08 10:19 ` Boaz Harrosh
2010-06-09 6:55 ` David Rientjes
1 sibling, 0 replies; 131+ messages in thread
From: Boaz Harrosh @ 2010-06-08 10:19 UTC (permalink / raw)
To: David Rientjes
Cc: Linus Torvalds, Ingo Molnar, Frans Pop, Dirk Hohndel, Len Brown,
linux-kernel
On 06/08/2010 01:14 PM, Boaz Harrosh wrote:
> On 06/08/2010 12:13 PM, David Rientjes wrote:
>> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>>
>>>
>>> The patch: 85a256d8e0116c8f5ad276730830f5d4d473344d
>>> Author: David Rientjes <rientjes@google.com>
>>> Title: kbuild: improve version string logic
>>>
>>> Broke none Linus trees that supply their own version string and
>>> tag system via a presence of a localversion* file at the Kernel's
>>> root subdirectory.
>>>
>>> After This patch. The "+" (plus) is not added if a localversion*
>>> file is present or a CONFIG_LOCALVERSION is configured.
>>>
>>
>> The only reason the `+' is being appended to your version string is
>> because your scm is reporting that there have been commits to the tree
>> since the last release; for git, that means anything that isn't at a
>> tagged commit.
>>
>
> What is a tagged commit:
>
> [my_tree] $ git branch
> *master
> [my_tree] $ git tag v2.6.35-rc2-my-tree
OK now I get it I need:
$ git tag -a v2.6.35-rc2-my-tree
I never used the -a before though no one complained. What else
am I missing?
Boaz
> [my_tree] $ cat localversion-my-tree
> -my-tree
>
> I still get: DEPMOD 2.6.35-rc2-my-tree+
>
> How to solve? please specify.
>
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: kbuild: Fix the breakage caused by "improve version string logic"
2010-06-08 10:14 ` Boaz Harrosh
2010-06-08 10:19 ` Boaz Harrosh
@ 2010-06-09 6:55 ` David Rientjes
2010-06-09 7:54 ` Boaz Harrosh
1 sibling, 1 reply; 131+ messages in thread
From: David Rientjes @ 2010-06-09 6:55 UTC (permalink / raw)
To: Boaz Harrosh
Cc: Linus Torvalds, Ingo Molnar, Frans Pop, Dirk Hohndel, Len Brown,
linux-kernel
On Tue, 8 Jun 2010, Boaz Harrosh wrote:
> What is a tagged commit:
>
> [my_tree] $ git branch
> *master
> [my_tree] $ git tag v2.6.35-rc2-my-tree
> [my_tree] $ cat localversion-my-tree
> -my-tree
>
> I still get: DEPMOD 2.6.35-rc2-my-tree+
>
> How to solve? please specify.
>
You need to use git tag -a.
> In my tree there is 2.6.35-rc2-my-tree so it cannot be mistaken with
> Linus tree.
>
Just because you have appended "-my-tree" to the version string does not
mean it is not vanilla 2.6.35-rc2. You could append information such as
that just for a different config, for instance. The `+' modifies the base
kernel version (2.6.35-rc2), not the string itself or whatever you choose
to add to it.
> > As mentioned previously, you can easily suppress that from being added by
> > using "make LOCALVERSION=-foo" to create a 2.6.35-rc2-foo kernel when you
> > do not have CONFIG_LOCALVERSION_AUTO enabled. You already found that you
> > cannot pass an empty LOCALVERSION string, so it must be something to
> > identify itself as unique from vanilla 2.6.35-rc2.
> >
>
> As mentioned previously this is not an option I do not have git control
> over how this gets compiled.
>
If your git repository is publically accessible, it is very simple to tag
commits that you want your users to pull from to indicate it's a
"release". That allows you to determine whether other users have extra
commits on top of your release when they send you bug reports, for
example, which is quite helpful.
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: kbuild: Fix the breakage caused by "improve version string logic"
2010-06-09 6:55 ` David Rientjes
@ 2010-06-09 7:54 ` Boaz Harrosh
2010-06-09 8:18 ` Mike Galbraith
0 siblings, 1 reply; 131+ messages in thread
From: Boaz Harrosh @ 2010-06-09 7:54 UTC (permalink / raw)
To: David Rientjes
Cc: Linus Torvalds, Ingo Molnar, Frans Pop, Dirk Hohndel, Len Brown,
linux-kernel
On 06/09/2010 09:55 AM, David Rientjes wrote:
> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>
>> What is a tagged commit:
>>
>> [my_tree] $ git branch
>> *master
>> [my_tree] $ git tag v2.6.35-rc2-my-tree
>> [my_tree] $ cat localversion-my-tree
>> -my-tree
>>
>> I still get: DEPMOD 2.6.35-rc2-my-tree+
>>
>> How to solve? please specify.
>>
>
> You need to use git tag -a.
>
Right, I got that
>> In my tree there is 2.6.35-rc2-my-tree so it cannot be mistaken with
>> Linus tree.
>>
>
> Just because you have appended "-my-tree" to the version string does not
> mean it is not vanilla 2.6.35-rc2. You could append information such as
> that just for a different config, for instance.
No, this is all naming convention. Just like the '+' is. If it was a config
thing then it would be added via CONFIG_LOCALVERSION and *appended* to any
compilation using that config. From a git tree you get added the localversion*
file that gets pulled by a checkout. and so on. So at a glance I know that
the presence of my_tree was added because it is from my tree. They are all
chained and ordered so we know exactly what contributed what.
> The `+' modifies the base
> kernel version (2.6.35-rc2), not the string itself or whatever you choose
> to add to it.
>
Not, correct. As you yourself explained. The `+' modifies any Kernel that
is not a "tag -a" and/or modified from the tree it derives from.
Base kernel version has nothing to do with it.
>>> As mentioned previously, you can easily suppress that from being added by
>>> using "make LOCALVERSION=-foo" to create a 2.6.35-rc2-foo kernel when you
>>> do not have CONFIG_LOCALVERSION_AUTO enabled. You already found that you
>>> cannot pass an empty LOCALVERSION string, so it must be something to
>>> identify itself as unique from vanilla 2.6.35-rc2.
>>>
>>
>> As mentioned previously this is not an option I do not have git control
>> over how this gets compiled.
>>
>
> If your git repository is publically accessible, it is very simple to tag
> commits that you want your users to pull from to indicate it's a
> "release". That allows you to determine whether other users have extra
> commits on top of your release when they send you bug reports, for
> example, which is quite helpful.
Sigh, I give up. Let me spell it out for you once more and I'll not mention
this again:
"For multitude of reasons, there are times that even when running from
a git tree, I wish to compile a Kernel as if it's from a tar-ball. .i.e
Don't poke in my git tree for this compilation."
Because I'm cross compiling, because I'm bisecting, because my scripts and
environment demand specific names, because i need to save space and time...
But it seems I will not be granted my wish. I'll go damage my
scripts/setlocalversion and be done with this.
Thanks
Boaz
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: kbuild: Fix the breakage caused by "improve version string logic"
2010-06-09 7:54 ` Boaz Harrosh
@ 2010-06-09 8:18 ` Mike Galbraith
0 siblings, 0 replies; 131+ messages in thread
From: Mike Galbraith @ 2010-06-09 8:18 UTC (permalink / raw)
To: Boaz Harrosh
Cc: David Rientjes, Linus Torvalds, Ingo Molnar, Frans Pop,
Dirk Hohndel, Len Brown, linux-kernel
On Wed, 2010-06-09 at 10:54 +0300, Boaz Harrosh wrote:
> But it seems I will not be granted my wish. I'll go damage my
> scripts/setlocalversion and be done with this.
I dislike that annoying little <expletive deleted> '+' too, but I have
to edit Makefile constantly to whack -rc and set version to the _right_
number as defined by me anyway, so it doesn't matter much.
Thank goodness we have _something_ to gripe about :)
-Mike
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 16:31 ` Linus Torvalds
` (3 preceding siblings ...)
2009-10-06 17:35 ` [patch] kbuild: Improve version string logic Ingo Molnar
@ 2009-10-06 17:40 ` Len Brown
2009-10-06 18:16 ` Linus Torvalds
2009-10-06 17:45 ` Dirk Hohndel
2009-10-06 19:22 ` Joel Becker
6 siblings, 1 reply; 131+ messages in thread
From: Len Brown @ 2009-10-06 17:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ingo Molnar, Dirk Hohndel, Linux Kernel Mailing List
Both Ingo and Dirk clarified and amplified my original request,
that it be easy to trivially tell the difference between stuff
_based on_ on 2.6.X, and stuff _based on_ the following merge window.
I fully understand non-linear development, I undersatnd
and use CONFIG_LOCALVERSION_AUTO, but that isn't sufficient
to solve the problem I have in my use case.
In my use-case, I develop on my desktop with a backing git tree.
When I want to do builds, I throw a tar-ball over the wall
to a remote compute engine to chew on the tree for a few hours.
The compute engine runs a relatively time-consuming serialized
script to discover all of the interesting configs to build.
It then stores those configs in a unique place associated
with that release. It doesn't have a backing git tree,
so it uses the info in the Makefile -- 2.6.X.
Then the compute engine builds each config, and stores the
output in the same place -- 2.6.X. On a typical build error,
I fix, send a new tar file, and unless I've changed Kconfig,
I kick off the builds without re-generating all the config files.
Even if I could get it, I generally don't want an exact -g1234
to identify the release, because 90% of the time I want to re-use
the config files that I've already built for the snapshot
the tree is based on without the repeating the time-consuming config
re-generation step.
My big problem today is that is that the new 2.6.X results
overwrites my reference configs for the real 2.6.X.
This means that if I have a development tree that is based
on the real 2.6.X (I almost always do), as soon as I build
a merge window kernel, I've lost all the golden configs
that I may want to re-use for my branch that is based
on the real 2.6.X
This also means that I've overwritten all of the
reference build results.
Maybe this use-case is stupid and simple-minded, but I'm
sure there are more stupid and more simple-minded use cases
out there that would benefit from immediately knowing the
difference in the Makefile between something based on 2.6.X
and something based on the following merge window.
thanks for listening.
-Len
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 17:40 ` Linux 2.6.32-rc3 Len Brown
@ 2009-10-06 18:16 ` Linus Torvalds
2009-10-07 22:33 ` Len Brown
0 siblings, 1 reply; 131+ messages in thread
From: Linus Torvalds @ 2009-10-06 18:16 UTC (permalink / raw)
To: Len Brown; +Cc: Ingo Molnar, Dirk Hohndel, Linux Kernel Mailing List
On Tue, 6 Oct 2009, Len Brown wrote:
>
> This also means that I've overwritten all of the
> reference build results.
That was a really long and boring email, and all it said to me was
"I can't be bothered to turn on CONFIG_LOCALCONFIG_AUTO, or I didn't even
read the thread to find out it exists and that you can use it even
without a git tree"
> thanks for listening.
I wish I could say the same.
So now, can you please just turn on CONFIG_LOCALCONFIG_AUTO and say "oh,
I'm happy now"?
It really does work with tar-balls too. The whole tar-ball thing is a
total red herring. All you need to do is add a ".scmversion" file into the
end result, and you're done.
And you can do that easily - even _after_ you've created the tar-file, and
even if you don't have a working tree. Lookie here:
tar rvf some-random-tar-file.tar linux-x.y.z/.scmversion
see?
Or, in the case of using "git archive", you can avoid having to remember
to add that .scmversion file, and instead teach your build-bot to create
it automatically from the tar-file even if you do _not_ add a .scmversion
file to the actual tar-file. "git tar" There's a command for that: "git
get-tar-commit-id", so you can just add something like
zcat < xxx.tar.gz | git get-tar-commit-id > .scmversion
(yes, yes, you may want to massage it a bit, ie do something like
sed 's/^\(........\).*$/-g\1/'
or whatever to turn that 40-character SHA1 into a nicer extraversion.
Whatever. Truly trivial scripting, and it means that your build server
will now _always_ build a kernel that actually knows what kernel it is!
Isn't that the sign of a _good_ solution? Something that actually improves
the end result in a real way? Now your builds will know what version they
were built from!
Please?
Linus
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 18:16 ` Linus Torvalds
@ 2009-10-07 22:33 ` Len Brown
0 siblings, 0 replies; 131+ messages in thread
From: Len Brown @ 2009-10-07 22:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ingo Molnar, Dirk Hohndel, Linux Kernel Mailing List
> ... please just turn on CONFIG_LOCALCONFIG_AUTO
For git-tree-based builds, I'm delighted with CONFIG_LOCALCONFIG_AUTO.
But on my build engine, I don't need or want the exact commit id.
(I have a descriptive originating branch name for it already,
and that is a heck of a lot easier to understand)
Indeed SUBLEVEL and EXTRAVERSION in the Makefile turn out to be
just about ideal both for good .config file library re-use,
and with double buffering, storing of results.
So if the -rc* EXTRAVERSION naming scheme were applied consistently
so that it could differentiate between a final release and
the following merge window, then SUBLEVEL and EXTRAVERSION
would be all I need on my build box.
Re: scripts to generate .scmversion
I'll pass.
I'd rather a script to simply update SUBLEVEL and EXTRAVERSION
in the Makefile upon seeing the 1st commit of the merge window.
I was hoping you'd do that for me, but failing that,
I can do it for myself. Just don't jump on me when I call
the merge window rc0.
thanks,
-Len
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 16:31 ` Linus Torvalds
` (4 preceding siblings ...)
2009-10-06 17:40 ` Linux 2.6.32-rc3 Len Brown
@ 2009-10-06 17:45 ` Dirk Hohndel
2009-10-06 19:22 ` Joel Becker
6 siblings, 0 replies; 131+ messages in thread
From: Dirk Hohndel @ 2009-10-06 17:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ingo Molnar, Len Brown, Linux Kernel Mailing List
On Tue, 2009-10-06 at 09:31 -0700, Linus Torvalds wrote:
>
> On Tue, 6 Oct 2009, Linus Torvalds wrote:
> >
> > Unless:
> >
> > > _That_ i think is a lot harder to confuse with the real .31 than a
> > > v2.6.31-1234-g16123c4 version string.
> >
> > .. are you saying that it would be just some automatically generated
> > thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a
> > CONFIG_LOCALVERSION_AUTO_SHORTFORM?
That's much better than what I had suggested - and it would work for
your case with multiple trees in a sane manner as well.
> IOW, you'd never get 2.6.32-rc0, but you'd get either the complex git
> version number (or SVN/hg/whatever), or at least "2.6.31+" with the "+"
> showing that it is more than plain 2.6.31.
>
> The "+" could be anything else, of course. The diff is pretty obvious, you
> can argue about exactly _what_ you'd like to see as a suffix for "and then
> some".
The argument by Stefan Richter that '+' is already used informally as
"or later" is somewhat valid - maybe we could use an ampersand (which
originally stood for 'et cetera' - and other things).
But then I don't know if that would confuse tons of scripts as the & has
lots of other meanings in various scripting languages.
--
Dirk Hohndel
Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 131+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 16:31 ` Linus Torvalds
` (5 preceding siblings ...)
2009-10-06 17:45 ` Dirk Hohndel
@ 2009-10-06 19:22 ` Joel Becker
6 siblings, 0 replies; 131+ messages in thread
From: Joel Becker @ 2009-10-06 19:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ingo Molnar, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On Tue, Oct 06, 2009 at 09:31:03AM -0700, Linus Torvalds wrote:
> On Tue, 6 Oct 2009, Linus Torvalds wrote:
> >
> > Unless:
> >
> > > _That_ i think is a lot harder to confuse with the real .31 than a
> > > v2.6.31-1234-g16123c4 version string.
> >
> > .. are you saying that it would be just some automatically generated
> > thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a
> > CONFIG_LOCALVERSION_AUTO_SHORTFORM?
>
> So how about this?
>
> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> way:
>
> - if it is set, things work the way they always have, and you get a
> extended kernel release like
>
> 2.6.32-rc3-00052-g0eca52a-dirty
>
> - but if it is _not_ set, we'll still try to get a version from the
> underlying SCM (we actually support git, hg and SVN right now, even if
> some comments may say "git only"), and if the underlying SCM says it
> has a local version, we append just "+", so you get a version number
> like
>
> 2.6.32-rc3+
I really like this, because I don't want to see
LOCALVERSION_AUTO forced on. While I like LOCALVERSION_AUTO in theory,
in practice it means that a one-line commit forces me to install an
entirely new /lib/modules directory. On many of my test machines this
fills up quickly. So I turn of LOCALVERSION_AUTO and just set a manual
LOCALVERSION.
Joel
--
Life's Little Instruction Book #356
"Be there when people need you."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply [flat|nested] 131+ messages in thread