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
Attachment:
pgp9iWcIVk71l.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
