login
Search
Yes, it's really -rc3, because I'm skipping -rc2 entirely.
Or not "entirely". As too many people pointed out, I had been somewhat
less than careful, and the 2.6.32-rc1 release actually called itself -rc2
in the Makefile. As a result, I don't want to make a 2.6.32-rc2 release,
since any bug-reports etc would then be met with the inevitable confusion:
do you mean -rc2 as in the Makefile (ie really -rc1) or -rc2 as in the
tagged release.
So I'm avoiding that confusion entirely, and consider the -rc1 release to
have also been -rc2, and thus a week later we're now at -rc3. And let's
hope that I won't have that particular "senior moment" any more. Although
I'm sure I can screw up releases some other way.
Anyway. On to the actual changes. It's actually been fairly calm,
although I'm not sure exactly why. Regardless, I'm not going to complain,
or look the gift horse in the mouth. The shortlog is appended (quite
often, the -rc2 shortlogs are still big enough that I skip them).
The biggest change in the diff is the e1000 network driver update, but the
bulk of that is actually just whitespace changes thanks to running it
through lindent along with dropping dead PCIe code (the PCIe support is in
the e1000e driver).
Apart from that single driver update (which is almost 60% of the diffs),
there's a fair number of one-liners, but also some DRM updates (mainly the
experimental radeon driver but also a capability to specify modes etc),
some pcmcia and serial updates, ext4 and btrfs, etc. With a smattering of
ACPI, sound and network code to fill in the cracks.
The appended shortlog probably gives a reasonable view into it, but one
thing that might be worth mention (despite being fairly small) is that
there's been some IO latency tweaking in the block layer (CFS scheduler).
I'm hoping that ends up being one of those noticeable things, where people
might actually notice better responsiveness. Give it a try.
Linus
---
Aaro Koskinen (1):
iop3xx: ATU ...I wrote earlier, in a reply on the Poor desktop responsiveness with background I/O-operations thread, that sometime between .30-rc6 and the .31 tag all of the recent improvements in perceived performance has been lost. I'm happy to report that as of the cmpexch64 fix, that regression is gone. Performance under load -- and particularly with significant paging -- shows a vast improvement (on my aging, 32-bit laptop). -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6 --
We have a similar problem with the period between, say, 2.6.X and 2.6.Y-rc1. The Makefile still says 2.6.X, yet during the 2.6.Y merge window the tree is very different from 2.6.X. This confuses things like my scripts that take a source tree tarball, and (re)generate config files for build testing based on the tags in the Makefile. There is no way for the scripts to know the post 2.6.X tree not the same as 2.6.X itself, the new configs overwrite the old, overwrite the old results etc. I think that BenH also had troubles with this issue and pointed it out a while back, but you were not convinced at the time that it was a problem worth solving. This could be clarified if you update Makefile on the 1st commit after 2.6.X is frozen to simply be 2.6.Y-merge or 2.6.Y-rc0 or something. Anything but 2.6.X. thanks, -Len Brown, Intel Open Source Technolgy Center --
I have seen this request many times and it seems to make perfect sense. The first commit applied after a release should change the version number to "something" - and "2.6.next-rc0" sounds as good as anything else that has been proposed so far. /D -- Dirk Hohndel Intel Open Source Technology Center --
No. It makes perfect sense just because the people who think so don't
think things through.
It doesn't help, for several reasons:
- the step function of the Makefile change happens once per release, and
if you compile anything but releases, you can never rely on just the
revision. Was it a plain -rc, a plain release, or something in
between? You'll never know, just looking at the 2.6.x.y thing.
In other words, you fundamentally have three choices:
(a) be confused. Adding an "-rc0" won't help. You'll still be confused
in between releases about exactly what you're running.
(b) use CONFIG_LOCALVERSION_AUTO=y
Now, if 'uname -r' says 2.6.31, then you _know_ it's exactly
2.6.31 and nothing else. If it's a few commits after 2.6.31, it
will say something like '2.6.31-1-g752015d', and you know that
it's one commit after 2.6.31, and you'll know _which_ commit it is!
(c) Don't compile anything but releases.
Those are the choices.
- An even _more_ fundamental reason: Linux development isn't linear.
There is not one "first commit" after a release, and there never will
be. Sure, there's a first commit that I do, but that has absolutely
zero relevance.
Learn this. Until you do, you'll be confused, and you'll show your
confusion by saying "I want a 2.6.n+1-rc0". You'll _also_ show your
confusion by things like "I was bisecting a bug that happened between
2.6.30 and 2.6.31, and suddenly git was asking me to test a kernel that
said it was version 2.6.29-rc1 - so I stopped bisecting because git was
confused".
Who was confused? Was it git, or was it the person who thought that the
Makefile version could be consistent in a non-linear world?
So no. I'm not going to do -rc0. Because doing that is _stupid_. And until
you understand _why_ it's stupid, it's pointless talking about it, and
when you _do_ understand that it's stupid, you'll agree with me.
Linus
--
I respectfully disagree. With the proposed -rc0 there is EXACTLY ONE kernel that is called 2.6.31 - the release kernel. And everything else is called something 2.6.xx-rcY. So we do get very useful information here - especially since the release kernel is supposed to be reasonably stable whereas the things right afterwards (during the merge window) are extremely likely to be unstable. So if you see something that identifies itself as -rc0, you know it's from during the merge window. If you see something that calls itself 2.6.xx then you know it's a release kernel. /D -- Dirk Hohndel Intel Open Source Technology Center --
No. That's simply not _true_. Think it through. Deeply. In particular, think about all the developers who start out at known stable points. And they are _supposed_ to start at release points. It means that a lot of versions in the -rc window will NOT have that -rc0 in them. In fact, even more commonly (for people who don't rebase, which should be the default), you'll have kernel versions in the merge window (and later) that will have Makefiles that talk about the previous release. No. No. And NO. Your kind of magical thinking leads to _problems_. It's literally been a problem that people stop bisecting, because they notice that they start testing kernels that have a version number before the release they already tested as good. Exactly because of your kind of linear thinking. We need _less_ linear thinking, not more. And you need to start thinking about other kernels than just my release tree. Linus --
The fundamental difference in our analysis is that I believe that 1% of the people using these kernels are developers as you describe above and I think those two things are entirely unrelated. How would calling the versions in the merge window -merge or -rc0 make any difference I do - I actually track multiple trees and have my own in which I do my own work. That still doesn't change my believe that the VAST MAJORITY of the people out there only track one tree. Yours. But hey, as you have stated so eloquently, I "don't know what the f*ck [I'm] talking about", so let's hear what others are thinking. /D -- Dirk Hohndel Intel Open Source Technology Center --
If they only pull from my git tree, why do they even care? And why don't you use LOCALVERSION_AUTO? Did you just not know about it? Linus --
No. You don't understand the difference between doing things right, and doing them wrong. It's not about "what does it cost me". It's about doing a really stupid thing that doesn't even _solve_ the problem in a lot of real cases, and doing the _right_ thing that solves it for every case. And the fact that people cannot see the difference between those two cases is sad. And no, this is not about "developers" vs "users". Not at all. Everything that makes it wrong for developers makes it wrong for users too. Linus --
I do understand your point, but I'm not sure that it makes sense to take bisecting as the main criterium here. Bisection will always be confusing for users the first few times, whatever you put in the Makefile. IMO it is more relevant that people who build and run pre-rc1 kernels get a clear distinction by default between their stable kernel and the (highly unstable) merge window one. When a user compiles a kernel, the only thing that's relevant is what's in Makefile *at that time*, not where the branches that are merged in happen to originate. Personally I always add a -rc0 in a local commit as soon as I pull any merge window changes (that commit gets dropped when you release -rc1). Package versions are derived from git describe. So I get (examples include local commits): linux-image-2.6.31_31.g5e9d407_amd64.deb (.31 + 31 local changes) linux-image-2.6.31.1_31.gb4adf51_amd64.deb linux-image-2.6.32-rc0_7396-g02b51df_amd64.deb linux-image-2.6.32-rc1_20.ge8343d5_amd64.deb linux-image-2.6.32-rc1_154.gb157421_i386.deb linux-image-2.6.32-rc3_18.g7e921a0_amd64.deb linux-image-2.6.32-rc3_69.g7146bc5_amd64.deb Of course this it makes no difference if you use 'make install', but for other cases I think having -rc0 in mainline first thing in the merge window would be useful. Especially for users who compile kernels from the git tarballs during the merge window (and are not aware of localversion). Of course there are plenty of options to do whatever you want locally, but why not make it easy? BTW, I've got a solution for bisection too: the versions in the Makefile get changed to something constant. And the package version is set equal to the bisection iteration. This ensures that I know exactly which kernels were build for the series and that I can always go back to a specific kernel if I need to retest for some reason. E.g. (for a bisection covering ...
It should be noted that implementing this would result in the package names becoming wildly inconsistent if you bisect over the point where this feature is introduced. In order to be useful, it would need to determine if its own implementation commit is shadowed by the 'bisect good' marker, make a note of this in a non-overwritten location (.git, eg), then disable itself and use the old behavior if it would bisect over its own introduction. --
It is already supported :-) But yes, what you note is an issue, though one that automatically fades with time. And it is softened by the fact that the scheme is not default. I deal with it in my wrapper script: that tests if the implementation commit is present and, if not [1], replaces scripts/package/builddeb with a version that does support it. That works for quite a long time back. The wrapper script also reverts the change after each build so the following good/bad does not fail because the tree is dirty. Cheers, FJP [1] It was introduced with .30: v2.6.30-rc8-79-gc72c75d. --
I understand non-linear history, but still i think that it might make sense to make it more apparent that the tree people pull from you after .31 got released is a lot closer to what .32 is going to be than to .31. (which the name implies) I.e. i think it's a fact that right now our release version is highly deceptive during the merge window. Two days into the merge window and we have more commits added than we add from .31-rc7 to .31-rc9 total. A week into the merge window we have .31 + 6000 commits merged and still call it v2.6.31, to the casual looker. We can ignore that and say "hehe, you dont understand non-linear trees and ran git remote update blindly, too bad for you", or we might do something to make things more transparent and reduce the confusion. Personally i really want people to try our git trees, but them also be fully aware of the risks involved. One option would be to make LOCALVERSION_AUTO compulsory. Or to add a tweak to the naming, something like: v2.6.31 v2.6.31+ v2.6.32-rc1 v2.6.32-rc1+ .. v2.6.32-rc9 v2.6.32-rc9+ v2.6.32 Would make it clear what's going on, even in the simplified world of limited-size version numbers. Or, IMHO it would also be a valid naming model to do this small tweak to the above naming scheme: v2.6.31 v2.6.32-rc0 v2.6.32-rc0+ v2.6.32-rc1 v2.6.32-rc1+ .. v2.6.32-rc9 v2.6.32-rc9+ v2.6.32 ... for the sole purpose of warning people that anything they pull after v2.6.31 got released is (wildly!) not vanilla v2.6.31 anymore. Not more, not less. Am i confused? :-) Ingo --
You are missing the point. The only thing we can do is to teach people that the Makefile version isn't too important, and that it really doesn't tell very much. Trying to tweak it to make it somehow "more meaningful" is a BAD THING, because it continues to spoon-feed people a lie. The cake is a lie. In between kernel versions, you can't rely on the Makefile. You should teach yourself (and others) THAT, rather than trying to teach people to believe the lie even more. Once you start believing the lie, suddenly all the subtrees will start thinking that now _their_ kernel versions are bad, so now they'll start to want to make the same idiotic changes to their Makefiles, or maybe they'll decide that they don't want to pull tagged releases, but the "one after the tag so that they'll get the updated Makefile". And even if they don't do that idiocy, the whole "the version number is Yes, I could live with that. If you're compiling from a git tree, we migth as well show the real version. It's the "let's make that meaningful and misleading number be even _more_ misleading by making people think it has meaning" magical thinking that I hate. It's wrong, and it leads people to believe in things that aren't true. I refuse to cater to that kind of wrongheaded thinking. I'd much rather screw up the version number entirely and add a _random_ number to it (so that the Makefile would say "2.6.18" after I have released 2.6.32) just so that people would be forced to _understand_ that the version number isn't as meaningful as you seem to think it is. For example, let's take Arjan's request, that kerneloops should get -rc0. Think about that for a few minutes. Really THINK about it. What happens? [ Spend some time really thinking here. ] What about people like all the networking guys who are running their development kernels that haven't been merged yet? Their kernels won't say -rc0. Are you going to ask them to do it too? Or would you be better off ...
hm, i think you ignored (or missed, or found irrelevant) my first suggested variant: v2.6.31 v2.6.31+ v2.6.32-rc1 v2.6.32-rc1+ .. v2.6.32-rc9 v2.6.32-rc9+ v2.6.32 The '+' sign says that it's more than .31. That defuses the 'lie' of trying to linerize a multi-thousand-node graph down into some catchy human-readable string pretty efficiently i think. It doesnt tell us precisely what that '+' means - it could be goodness or it could be badness. _That_ i think is a lot harder to confuse with the real .31 than a v2.6.31-1234-g16123c4 version string. My tweak #2, adding -rc0 indeed brings in problems, it's too artificial to do it right after .31 gets released - and if we dont do it then we cannot do it later either. (so we cannot really do it) [ It might bring in some advantages too btw. A pull request to you for a tree that is -rc0 based means it got rebased straight in the merge window => bad. Such a thing would be apparent at a glance. 'Good' trees should be based on some known good version of the previous stable kernel cycle. ] Ingo --
No, I didn't ignore it, it just showed that you didn't know what you were No. It shows no such thing. Because it DOES NOT EXIST in other peoples trees until they rebase on top of mine. .. 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? If so, then I don't hate "v2.6.31+", but at the same time, that single plus-sign tells _so_much_ less than v2.6.31-1234-g16123c4 that I think it's really sad and crippled. Is it so hard to teach people what "v2.6.31-1234-g16123c4" means? It's not like it's very complicated, and it's not like it's not visually very distinct indeed from the tagged release case (which is just "v2.6.31"). I'd love to use "+" instead of "-", but I was thinking that there are various version things that get unhappy about special characters like that, so we've always used '-' as the separator (since we've always used it). So I'm _entirely_ open to changing how 'CONFIG_LOCALVERSION_AUTO' works, or extending on that notion. What I'm _not_ open to doing is to add made-up commits that change the top-level Makefile at non-release points. Because that way really does lie insanity. Linus --
Agreed, and in my internal testing i've made LOCALVERSION_AUTO compulsory long time ago. But at least to me there's a simple benchmark: i have been confused by this. In one of the merge windows i thought i booted .31 vanilla while in fact it was a few days into the merge window already. Took me a few minutes to figure out why it was crashing ;-) YMMV. Maybe a variant of the full string: v2.6.31+1234-g16123c4 would be even less confusing. I tend to ignore dashes sub-consciously (as a 'minor versions' kind of thing) - while in this ~1 week out of the 9 weeks of your tree's cycle it means something much more than that, and we dont emphasise the difference strongly enough. But ... that's just my own experience. I also see -tip users become a lot more cautious for a few rc's once we go -rc1 - while they happily test things in the merge window (which is _way_ more dangerous than pretty much any post-rc1 tree you push out). Basically IMHO the inflection point between v2.6.31 and the merge window is way too 'smooth', and not obviously so, and it lures people who are not careful enough into testing something they probably wouldnt test otherwise. It's a purely human thing - to a machine it's already very obvious what g16123c4 means - it doesnt need any of the fancy v2.6.31 stuff either. Ingo --
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".
Linus
---
Makefile | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index e50569a..c62b7cc 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)
--
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
--
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 --
( 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 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 --
Ingo Molnar wrote: 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/ --
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/ --
'+' 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 --
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. --
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 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 --
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 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 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 --
On Tue, 6 Oct 2009 20:29:08 +0200 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 -- --
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, ...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
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 --
However, that still breaks current make-kpkg iirc. I haven't used it in quite some time, so I don't particularly care. johannes
That's exactly what I'm afraid of. I'd really like to keep the long version AUTOVERSION strings the same, please. - Ted --
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 --
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
This is a bit OT, but one last reply. 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. --
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'? --
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) \
...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> 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 --
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 --
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 --
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 ...
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 --
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 --
Yeah, my patches build upon the base that you originally proposed. I like the `+' suffix for configs with CONFIG_LOCALVERSION_AUTO that aren't 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? --
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 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. 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 ...
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 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 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 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. --
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 That change seemed logical to me. And I did say my patch was on top of 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? --
You would prefer that CONFIG_LOCALVERSION overrides the `+' when 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 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, 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. ] --
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 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 --
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 --
But it would not be "2.6.30+-2-amd64"; it would become "2.6.30-2-amd64+", 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 "+" 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. --
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= The `+' is irrelevant at -rc releases, it wouldn't be added anyway! It's 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. --
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 ...
thanks David! Acked-by: Ingo Molnar <mingo@elte.hu> Ingo --
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. You forgot to change the $(localver-auto) here; and maybe also remove that leading space in this line. --
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 --
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
--
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? --
You shouldn't be using EXTRAVERSION for this purpose, you should be 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. --
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 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 ! --
If everyone using that tree wants the same version string for that kernel, use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make That's because you're using EXTRAVERSION which is also used upstream to You still have the tools available to do everything you once did. --
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 --
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 --
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. --
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. --
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 --
The `+' modifies the base kernel version, not the version string. Otherwise, it would be impossible to determine whether a "2.6.35-rc2-foo" 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. --
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 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 No! how? I couldn't find how please specify exact commands to use. Boaz --
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 --
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. --
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+ 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." My base "kernel version" is 2.6.35-rc2-my-tree. There cannot be any mistake As mentioned previously this is not an option I do not have git control 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 I tried that. Only with my patch it works. Hence the patch. 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 --
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? --
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 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. --
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 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. 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 --
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 --
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 ...
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 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 --
> ... 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 --
That's much better than what I had suggested - and it would work for 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 --
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 --
I agree with linus, I don't like that (+) simbol in the linux version, I prefer only numbers. Herlin. --
A general concern about adding the "+".
Anyone want to bet how many (init?) scripts there are in userspace that do
something like:
KVERS="$(uname -r | cut -d"-" -f1)"
case $KVERS in
2.6.*)
minor=$(echo $KVERS | cut -d"." -f3)
if [ $minor -lt 10 ]; then
# do something
fi ;;
esac
Note that the '[ $minor -lt 10 ]' will now produce an error because
'31+' is no longer a valid number:
bash: [: 31+: integer expression expected
A "-" has for ages been the standard separator between the kernel version
and any suffixes, certainly in Debian. Loads of scripts will assume that.
In an earlier mail I said that I would consider using the "+". This is
seriously making me have second thoughts, even for custom built kernels.
Here are some real life examples from my Debian stable system:
/etc/init.d/pcmciautils:
supported_kernel()
{
case $KERNEL_VERSION in
2.[012345].*|2.6.[0-9]|2.6.[0-9][!0-9]*) return 1 ;;
2.6.1[012]|2.6.1[012][!0-9]*) return 1 ;;
esac
return 0
}
Would have failed for e.g. a 2.6.12+ kernel.
/etc/init.d/umountnfs.sh:
KERNEL="$(uname -s)"
RELEASE="$(uname -r)"
case "${KERNEL}:${RELEASE}" in
Linux:[01].*|Linux:2.[01].*)
FLAGS=""
;;
Linux:2.[23].*|Linux:2.4.?|Linux:2.4.?-*|Linux:2.4.10|Linux:2.4.10-*)
FLAGS="-f"
;;
*)
FLAGS="-f -l"
;;
esac
Would have failed for e.g. a 2.4.7+ kernel.
Sure, these won't fail if we start adding the "+" now, but will the people
writing such tests in the future always remember to allow for the "+",
especially given that it will be relatively rare in a distro context?
Cheers,
FJP
--
That 'meaningful' was supposed to be a 'meaningless' of course.
The point really is that we have about 1 new version number per week, but
at the same time we have an average of one _thousand_ commits merged per
week. So at a glance, the Makefile version number doesn't mean very much.
But if the thousand commits we merged actually were nicely spread out in
between those version numbers, it would all work really beautifully. Sure,
the top-level version number would only give you a 1/1000 of the real
commit information, but hey, that's kind of what you'd want, isn't it? So
then the top-level Makefile version number would be meaningful and useful!
But that's not how it works. In fact, if we actually followed our own
release rules ("merge window is for merging code that was written before
the merge window even started"), no commits except for my merge commits
should actually have that last release in their Makefile at all!
Now, that's not actually true, because (a) people rebase and (b) even in
the absense of rebases I do merge with people like Andrew by email, so we
actually end up having statistics like these:
git rev-list v2.6.31..v2.6.32-rc1 |
while read a
do
git show $a:Makefile | grep SUBLEVEL.=
done | sort | uniq -c
resulting in
32 SUBLEVEL = 29
383 SUBLEVEL = 30
8795 SUBLEVEL = 31
1 SUBLEVEL = 32
which is actually a bit sad in itself (showing just _how_ many people
rebased their work on top of a release), but is still showing that we
actually had 32 new commits in there that were based on a 2.6.29 kernel
And what people are suggesting with a 2.6.32-rc0 would just lead to people
now rebasing their work NOT EVEN ON A RELEASE. They'd want to rebase it on
top of that made-up commit (2.6.32-rc0), so now from a development
standpoint that commit suddenly becomes more important than the release
itself.
Do you not see the insanity? We should have _less_ of this kind of
thinking, not more. At least rebasing ...IMO you're looking at this from the wrong side: the developer PoV. The request is made from a *user* PoV. Users very simply want to avoid that they accidentally install a merge window kernel over their stable kernel. IMO that makes sense. Developers are supposed to be able to take care of themselves; the mainline tree should aim to make things easy for users. I see the release versions purely as reference points. And -rc0 is obviously useless from that perspective, which is why it should be just a Makefile thing and not a tag. But -rc0 is IMO very useful to distinguish what kernels someone has installed. BTW, including the commit number in the version string has a major disadvantage: kernels will get installed *alongside* eachother instead of the newer kernel replacing the older one. Result is that /boot partitions fill up much more quickly. Cheers, FJP --
_People who build kernels from sources which differ from releases_ are supposed to take care of themselves. -- Stefan Richter -=====-==--= =-=- --==- http://arcgraph.de/sr/ --
Yes. If you compile a random development kernel, you'd better then not come and whine to developers about how you can't tell which version it is. Especially when we do have things like CONFIG_LOCALVERSION_AUTO exactly for this case. But it's possible that people really just weren't aware of that whole LOCALVERSION_AUTO thing. Linus --
I will say that I was not aware of it, and I've been using kernel.org kernels for many years. I'm glad to see it there. enabling it by default would probably be a very good thing. David Lang --
OK. I can agree with that too. It does take some time to learn to take care of oneself though. The point was that contributors start out as users; some will gradually become developers. And remember that developers also do often *ask* regular users to "try the current mainline", even during the merge window. Maybe that is something that is done too lightly? Cheers, FJP --
The distinction between "users" and "developers" doesn't make sense to Do they? Perhaps the "developers" know what experience and resources are available to the particular "user", or otherwise put into context what might be required for the discussed test. Anyway. Remember, you ultimately cannot remote-control what people have in their $(kernelrelease). You can only tell them that they can set the local version to an explicit or automatic value if a meaningful $(kernelrelease) is desired despite working with an unreleased source. -- Stefan Richter -=====-==--= =-=- --==- http://arcgraph.de/sr/ --
It's actually not quite so bad. If you take into account
Extraversion, the stats that you get look like this[1]:
4 29-rc2
28 29-rc8
331 30
4 30-rc2
48 30-rc5
3867 31
561 31-rc1
895 31-rc2
190 31-rc3
278 31-rc4
1245 31-rc5
521 31-rc6
515 31-rc7
387 31-rc8
336 31-rc9
1 32-rc2
That actually shows that well over half of the commit based off of
2.6.31 were actually based off of some 2.6.31-rc release, based on
something *before* 2.6.31 released.
Of the 3867 that were based on something between 2.6.31 and
2.6.31-rc1, that may be explained by people (like me) who will do a
test merge, and if the test merge has conflicts, prefer to resolve the
conflicts via a rebase and a re-run of the regression test suite, as
opposed to either (a) having the upstream maintainer (you) do handle
the merge, or (b) having two merges in the history; one merge by the
maintainer to resolve the merge conflict, and another by the upstream
maintainer when they pull in the topic branch.
Some (probably small percentage of the commits based on something
between 2.6.31 and 2.6.31-rc1 can probably be explained by on bug
fixes after an initial merge, but granted that's probably a pretty
small set.
- Ted
\[1] Generated using:
git rev-list v2.6.31..v2.6.32-rc1 |
while read a
do
git show $a:Makefile | head -4 > /tmp/foo
awk '/^SUBLEVEL/ {printf("%s", $3)}; /^EXTRAVERSION/ {print $3}' < /tmp/foo
done | sort | uniq -c
--
BTW, just out of yucks, after experimenting a bit with git log
--pretty=format:%P and git-describe, here are the top parents used to
base patch commits that were merged during the recent merge window:
5 v2.6.30
5 v2.6.31-git3
6 v2.6.31-git8
6 v2.6.31-git10
6 v2.6.31-git15
7 v2.6.31-git6
7 v2.6.31-git11
8 v2.6.31-git4
9 v2.6.31-git5
9 v2.6.31-git14
11 v2.6.31-git2
11 v2.6.31-git9
11 v2.6.31-git12
18 v2.6.31
- Ted
--
I'm a moron. Thanks. I wanted to do just a simple grep, and in the process Yup. Goodie. And I feel much better about our development environment now, since that is how it's supposed to work. Linus --
Not sure I'd like that.Actually pretty sure I'd hate it. It would completely break the clean mechanism I currently have (described in my previous post). Enabling it by default somehow would be fine with me, but "compulsory" is a step to far IMO. Users should always be allowed custom schemes. Cheers, FJP --
I do respect that - we shouldn't _force_ things if some people have special needs and do things differently and really need a very particular version number setup. 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). Linus --
Note that I was referring to adding on the full commit identification. I have a lot less problems with the "+" (or whatever we end up with). I would probably even use it, although it will mean that I effectively _always_ have the "+" because of local patches. But that is correct as 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. Cheers, FJP --
After sleeping on it and letting it percolate a bit I understand this argument better, and accept it. I'll continue to increase SUBLEVEL and add -rc0 for my own builds though, as IMHO it still makes perfect sense for versioning and managing installed kernel packages. The conclusion for me is: if anyone wants -rc0, simply apply it locally. I don't see myself ever using AUTOVERSION. The reason is that I don't want the files in /boot and dirs in /lib/modules/ to include the commit ID. For me the kernel *version* is what's defined in the Makefile (plus any localversion extentions). That's how I want it installed. The AUTOVERSION part is a *revision*: an update to the tagged version. (I don't expect you to agree with this.) So, unless it is made possible to include AUTOVERSION in the kernel and display it in dmesg and as part of the full 'uname -a' info *without* it becoming part of 'uname -r', it is not a usable option for me. Sorry. Cheers, FJP --
If this scheme is meant to be something on which people can rely on, everybody who commits to a tree from which Linus pulls from would have to base their branches onto those ...+ commits, always. -- Stefan Richter -=====-==--= =-=- --==- http://arcgraph.de/sr/ --
I think you misunderstood - the + would just be a shortcut for the long-form precise version string. Ingo --
Yep, 7 minutes later I would have seen your other post from which it became clear even to me that it's not about magic commits but a kbuild tweak. :-) -- Stefan Richter -=====-==--= =-=- --==- http://arcgraph.de/sr/ --
Well, thing is, it's not us who are confused in general, it's users who do reports with confusing versions. Yes, I agree that anything but a release warrants a proper commit ID, but that's exactly what I asked for when I wanted -rc0 here :-) IE. That the -only- kernel that is called "2.6.x" is the release, everything else has some kind of -rc in front of it, which allows me to bug the user for a commit ID and know right away that this isn't a Sure, when doing the stuff ourselves. Again, the problem is user reports. Being able to distinguish between a 2.6.x "release" kernel and anything else would be of value, at least to me. For anything else, I can say "heh, you've been compiling non-release stuff, you should be able to get me a git commit ID. Difference boils down to users falling into two categories: Those who compile non-release stuff, and should be able to figure out what the ID is or recompile with LOCAL_VERSION set propertly etc... and those who don't, didn't always compile the kernel themselves, and fortunately in it would be easy enough for you to push a change to the Makefile just I disagree. I understand the linearity problem. My point isn't about having the Makefile provide with any kind of precise "pointer" into that tree for non-release, but really only to differenciate a release from anything else. I know for somebody who uses git everyday, the concept of release even becomes a bit fuzzy, but there's a lot of folks out there who really don't see anything else :-) Cheers, --
Why are you arguing? CONFIG_LOCALVERSION_AUTO gives exactly that? Also, why do you think that "release" is any special? All the same things are true about "is it -rc1 or is it -rc1-351-g58e57fb? When it comes to a And your point is totally destroyed by any amount of thinking. Which you clearly didn't do. I repeat: there are tons of kernels that would not be based directly on that "-rc0" commit. You would confuse _those_ cases even more, because you would now think that they are somehow "release" kernels. And the fact is, NONE OF YOUR BLATHERING has in any way shown why people shouldn't just use CONFIG_LOCALVERSION_AUTO. I keep on returning to that, and harping on it, but the point is, WE ALREADY SOLVED THIS PROBLEM. Every single person who asks for a -rc0 tag is just being stupid. You already have a much superior solution. So don't ask me for something _stupid_, when you already have the smart thing! Linus --
On Wed, Oct 7, 2009 at 8:19 AM, Linus Torvalds Why don't you just have the kernel version Linux-commitid? why keep up the pretense that the 2.6.xx bit means anything outside of release? You could just have the tarball generation scripts make it into a 2.6.31 but for everyone else we never see it. Dave. --
The tarball generation scripts for the daily snapshots already set EXTRAVERSION to -git15, -git16, etc. So the problem seems to be localized to those users/developers who are smart enough to use git, and dumb enough not to set CONFIG_LOCALVERSION_AUTO. So big of a set this actually is, I can't say. Do we have any statistics about how many bug reporters make this mistake? - Ted --
Not -that- often but I did waste a considerable amount of time in each case when reported that "2.6.N" had a bug that in fact was due to somebody building some random git checkout. But yeah, I suppose I should from now and always ask precisely what kernel was used and/or enable CONFIG_LOCALVERSION_AUTO. Cheers, Ben. --
I admit -- I did not know about LOCALVERSION_AUTO, and many times wished -rc0 would be labeled as such. Now...perhaps LOCALVERSION_AUTO should not be option? Just hardwire it to Y? (But that still does not solve systems when someone, probably me, did rm -rf .git, for space and speed reasons). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
Why is LOCALVERSION_AUTO part of the config file? Shouldn't it be on the Makefile? Then it's easy for people to override it if they want. And it's also easy for packagers, for whatever wicked reasons. -- Felipe Contreras --
That's actually what I personally do 99% of the time. And, in fact, it's how CONFIG_LOCALVERSION_AUTO effectively works. It's very useful for doing things like gitk v$(uname -r).. which really does work (well, apart from the "-dirty" case when I've compiled a dirty kernel that has something that isn't committed). Try it. It's a great way to see "what do I have in my current tree that I'm not actually running". So with CONFIG_LOCALVERSION_AUTO, you can largely pretend that you really Agreed. However, it _does_ mean something for releases. And that is really how you should think of it. I update the kernel Makefile for releases, and nothing else. If you compile a non-release kernel, the version is meaningless - unless you have Well, about a year ago I actually considered generating the version entirely from the tags in the git tree, and do it entirely that way. The reason I didn't is that even if it only makes sense for releases, it is (a) tradition and (b) useful without (or across) SCM's and (c) human- readable. In fact, I tend to like seeing things like Linux version 2.6.32-rc2-00351-g58e57fb in my dmesg outputs, because it does mean something _outside_ of just the pure "git version" (the '58e57fb' part is sufficient as far as git is concerned). It does have a very human-readable component to it: it's 351 commits after 2.6.32-rc2. So I literally think that our current CONFIG_LOCALVERSION_AUTO includes the best of both worlds. It has the "uniquely identifying" part, but it also has a part that is human-readable and useful for that reason. Linus --
Btw, that doesn't mean that I'm married to the exact details of the syntax etc. I like CONFIG_LOCALVERSION_AUTO, but I can also see why Ingo would prefer a "+" there instead of a "-". And the zero-padding to five digits of the number of commits may make things line up nicely, and I think there was even some odd technical reason for it too (some package manager or other that was unhappy with "simple" numbers like "-1" and thought that they were a build number or something), but it's admittedly silly too. So I'm not trying to say that we could not change the details or perhaps improve on it. What I _am_ trying to say is that conceptually that whole CONFIG_LOCALVERSION_AUTO is absolutely the only sane way to do things. Whether we could expand on it or simplify it or paint it a different bike shed color, I don't care much about. So I'm not married to the exact details of our current LOCALVERSION_AUTO thing. But I _am_ 100% convinced that it's conceptually the right thing to do, unlike the other suggestions I have pooh-poohed in this thread. Linus --
I really like CONFIG_LOCALVERSION_AUTO the way it is, and changing it will break things. It probably wouldn't be that hard to fix things, although the fix probably would involve post-processing the version number to bring it back to using '-' for all of the spearators, so that '+' could be used for separating the packaging-specific version details. The one thing that I wish we *could* do is make CONFIG_LOCALVERSION_AUTO mandatory, or at least making it the strong default and forcing people to work to turn it off, since the problem really is with users smart enough to use git, but not quite smart enough to turn on CONFIG_LOCALVERSION_AUTO. - Ted --
There are also those who use git, but turn CONFIG_LOCALVERSION_AUTO off for a reason, because it just annoys them with zero gain. I don't do -rcX. I have one tree per installed kernel. When Linus pulls a release out of the oven, on that day, Makefile becomes rev++ for a new tree and stays that way until he declares the next one baked. Old tree stays frozen at rev until it becomes .stable. My repos are always frozen at where the installed kernel is at, so adding an extra version is just a work generating irritant. I'd like having git ID embedded in the kernel for idiot proofing, but I don't like it polluting my installs, so I live without it. -Mike --
as I understand it, if you only use the released kernel then CONFIG_LOCALVERSION_AUTO will make no difference to you. the kernel string only changes if you use a non-release kernel. David Lang --
As a total newbie, this took a few to see, but then once I connected the dots made complete sense. (i.g. the how many commits 00351 and commit number just my $2 (as for the "+" and "-" tough to say, I'm happy as is, Justin P. Mattock --
