Messages in this thread | | | Date | Thu, 15 Oct 2009 00:37:08 -0700 (PDT) | From | David Rientjes <> | Subject | Re: [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.
| |