[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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' [1]...

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

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:


[1] http://lkml.org/lkml/2009/10/15/103

Reply to: