Message-ID: <alpine.DEB.1.00.0910151324481.17578@chino.kir.corp.google.com>
Date:	Thu, 15 Oct 2009 13:38:11 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Frans Pop <elendil@...net.nl>
cc:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dirk Hohndel <hohndel@...radead.org>,
	Len Brown <lenb@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH, v2] kbuild: Improve version string logic

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. ]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists