Re: [PATCH, v2] kbuild: Improve version string logic

[Frans Pop <elendil@planet.nl>]

On Thursday 15 October 2009, Ingo Molnar wrote:
> > 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.
>
> It's not "totally redundant" _AT ALL_.
>
> "2.6.30+-2-amd64" tells us that not only do we have the usual per distro

But it would not be "2.6.30+-2-amd64"; it would become "2.6.30-2-amd64+", 
which IMO sucks.

> 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.

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 "+" 
does not add any meaningful information.

> Besides, distros building on kernels inbetween -rc's is very rare.

True. Which is why we shouldn't be adding the "+".

> 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.

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.