Use kernel version number rather than package release

Latest response

Use the kernel version number to indicate release rather than just package version.  The RHEL kernel is already an amalgam of multiple upstream releases and the version should help reflect that.  One way would be to ship RHEL7.0 on kernel 3.x and rebase 7.1 on 3.x.N patch release.  It may be possible to even include all local RH patches in a 3.x.N stable release.  It may also be palatable to clients to ship 3.y.N as a 7.x service pack release

Responses

I'm not sure what exactly you're asking for here; there seems to be two parts. First, you suggest what appears to be a 'kernel-rhel7-1.0' sort of naming - is that correct? What would be the use case for this?

 

Secondly, you suggest rebasing the kernel between releases; this would be a separate issue to the versioning, and brings with it other complications. Would you want this for hardware support? Bringing in additional bugfixes?

I clearly didn't explain very well.  What I was suggesting is the same naming scheme that is currently used, kernel-major.minor.patch-packagever but that instead of having all kernels be, for example, kernel-3.0.0-1 , -2, -3 that it might be possible to re-base on 3.0.1, 3.0.2 and allow the version number to change along with the package revision.  The kernel is already patched with bug fixes and hardware support, the fact that the version number doesn't change doesn't make the actual code changes less. 

 

For example in rhel6.1 the kernel (nominally version 2.6.32) received the ipv6 tproxy implementation which was merged with 2.6.37 so in a very real sense the rhel6.1 kernel isn't 2.6.32 anymore. So in the new kernel 3.x numbering scheme if rhel 7.0 shipped with 3.32.0 and patched it with 5 security releases during its lifetime bringing it to 3.32.5 then released rhel7.1 with 3.37.0 which it would then patch that might bring the actual version numbers more in line with what is actually happening with the code.

However, unless we start doing a full rebase of the kernel instead of selective  backports as currently done, updating the version number doesn't really make it any more accurate. In your example, we may have backported the IPv6 tproxy support, but we didn't backport other things that were in 2.6.37, so that would be just as misleading.

 

I understand there are reasons not to do a full rebase on full revisions, going from x.32.y to x.37.y but I think it would be good to re-evaluate those reasons.

 

In any event it should be do-able to re-base on patch releases such as x.32.y to x.32.z and update the version number accordingly. 

 

I mean, it's nearly as misleading to call the rhel6.1 kernel 2.6.32 as it is to call it 2.6.37 as it is neither of those things, the alien versions described in your first reply might actually make more sense.