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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200910151642.05276.elendil@planet.nl>
Date:	Thu, 15 Oct 2009 16:42:03 +0200
From:	Frans Pop <elendil@...net.nl>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	David Rientjes <rientjes@...gle.com>,
	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 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.
--
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/