kernel versioning

[Axel Thimm]

Hi,

upstream kernels that are release candidates or git sub-rcs etc. are
versioned in FC/RHEL based on the previous stable kernel release,
e.g. FC5's 2.6.16-rc5-git9 kernel is released as 2.6.15.

I generally think that's a good idea (e.g. it *is* 2.6.15 with patches
towards 2.6.16 and not yet 2.6.16, and the user is not confused that
he's already running 2.6.16).

But tons of kernel module projects check on the version of the kernel
and trigger different code bits. These projects depend on the
versioning to decide whether some features exist or not.

This results to funny external Fedora-patches to these projects that
only last a kernel release and are troublesome to maintain. The
typical user has to hunt down these issues, upstream needs a Fedora
system or someone willing to do the check on his system, and the
package maintainer needs to revise his packages upon any kernel
release.

So there is a wish to keep the versioning in the top level Makefile as
vanilla ships it. That way the checks will be more accurate and
users/upstream/packagers will have less to worry about, less
Fedora-only patching and so on.

The downside of this is that uname -r will give a different kernel
version than rpm's version, e.g. 2.6.16-xxx vs 2.6.15-yyy. If the
rpm's version is adapted to the kernel's then we have the issues on
epoching (which is solvable in ugly way) and that of the user's
thinking they already run 2.6.16 which they don't yet (at least not
the released version).

Any thoughts on how to make everyone happy? :)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060310/b734d540/attachment.sig>