Upstream plans to add a "+" suffix to kernel versions
On lkml there's a discussion about unconditionally adding a "+" to the
kernel version if it is being built from a version control system and
there are commits after the last tagged release.
So, during the merge window you would no longer get '2.6.31', but
This is mostly targeted at users building custom kernels, but main
arguments are about how it affects distro kernels. Ingo Molnar would for
example not mind seeing '2.6.31+-2-amd64' ...
My input in the discussion has mainly been to try to get the proposed
change include backwards compatibility in the sense that if someone really
does not want the "+" because it messes up his existing kernel version
naming scheme, he should be able to disable it without needing to patch
I'm not sure if this change will actually affect official kernel builds or
not, but even if it does not I think it would be good if the Debian kernel
team could offer an opinion on the proposal.
Besides the possible impact on packaging there is also a risk I thought of
today that adding a "+" will break userspace, especially in Debian where
we've always had a "-" as separator between the kernel minor and any
suffixes. For details see: http://lkml.org/lkml/2009/10/15/210.
Avoiding the "+" will of course be possible for official Debian kernels,
even if by patching the Makefile, but there are also users running custom
built kernels on Debian.
The (long) discussion started here: http://lkml.org/lkml/2009/10/5/407.
My main arguments and counter proposal (although I have quite a few other
mails in that thread too): http://lkml.org/lkml/2009/10/14/507
Current proposed patch: http://lkml.org/lkml/2009/10/15/62
The full thread is probably easier to read here: