lkml.org 
[lkml]   [2009]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH, v2] kbuild: Improve version string logic
On Thu, 15 Oct 2009, Frans Pop wrote:

> That is fine for custom kernels. I still maintain that it is hopelessly
> wrong for distro kernels.
>
> Distro kernels generally have their own naming schemes.
> Debian uses: 2.6.30-2-amd64 (<version>-<ABI>-<flavor>)
> Fedora uses: 2.6.30.5-43.fc11.i586
>
> And those kernel versions implicitly already contain the information that
> they are not vanilla kernels. So a "+" suffix is totally redundant.
>

And that's why I suggested, in addition to my patch, that we allow "make
LOCALVERSION=" to override the `+' suffix for kernels compiled without
CONFIG_LOCALVERSION_AUTO. In your examples, they would pass
LOCALVERSION=-2-amd64 or LOCALVERSION=-43.fc11.i586, respectively, to
make.

> My main argument is that if they build kernels from an SCM, which is quite
> likely, they should not suddenly get a "+" appended to those versions.
> And IMO they should also not have to patch the Makefile to avoid it.
> If this change is made, it should be made in such a way that old version
> naming schemes are still possible.
>

They are, with my suggestion to allow make LOCALVERSION= to override the
`+'. The question I posed directly to you was this: how does adding a
unique string passed by the user for a more descriptive kernel version
interact poorly with certain packaging requirements? You've given two
examples that are _perfect_ use cases for my suggestion.

> > We could easily go with my suggestion of allowing "make LOCALVERSION="
> > to override all additions to the kernel version when
> > CONFIG_LOCALVERSION_AUTO is disabled. For such configurations, kernels
> > would be built with this variable to specify how it's different from the
> > vanilla version and would suppress the `+'.
>
> Using LOCALVERSION= for that would be wrong as it is on a different level
> from AUTOVERSION. They should be independent. However, that basic approach
> of using an environment variable is certainly an option.
>

Now I'm confused, because currently LOCALVERSION= can only be used when
CONFIG_LOCALVERSION_AUTO is defined; in other words, it's completely
dependent on it. My patch changes that and seems to be your desire as
well?

> So I propose the following patch on top of the patch proposed by David.
> It offers a clean out for users who explicitly do not want *any* SCM-based
> suffix added to their kernel version, and is IMO both 1) obvious enough
> for expert users and 2) obscure enough that regular users are unlikely to
> abuse it. Is that acceptable?
>

No, it actually makes things much worse because now instead of forcing the
user to post his .config to determine the setting of
CONFIG_LOCALVERSION_AUTO to intepret the version string, it forces them to
recall what their KBUILD_NO_LOCALVERSION_EXTRA environment variable
happened to be at the time of build.


\
 
 \ /
  Last update: 2009-10-15 09:41    [W:0.105 / U:8.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site