[lkml]   [2009]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH, v2] kbuild: Improve version string logic

* David Rientjes <> wrote:

> On Wed, 14 Oct 2009, Ingo Molnar wrote:
> > > I don't think you want to do that because it would require the .config
> > > to be posted on bug reports, for example, to determine the setting of
> > > CONFIG_LOCALVERSION_AUTO before you can interpret the kernel version.
> > > In other words, you wouldn't know that "2.6.32-rc4" is actually 200
> > > commits beyond the actual release unless you also know that the
> > > .config has CONFIG_LOCALVERSION_AUTO="none".
> >
> > We've come a full circle ...
> >
> > That's the current !CONFIG_LOCALVERSION_AUTO status quo ... That was
> > being asked to be preserved for (unspecified) packaging reasons. So
> > your suggestion is to do away with that behavior altogether?
> >
> I don't think it's helpful to specify a version as "2.6.32-rc4" when
> in reality it has 200 commits beyond the release and I like the
> addition of `+' for !CONFIG_LOCALVERSION_AUTO if we're not at a tagged
> commit. That's what my two patches do so the only time you could get
> a "2.6.32-rc4" version string is for when it's the equivalent of
> (and you would actually get that regardless of whether you're using
> 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 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

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.



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