kernel versioning

Axel Thimm Axel.Thimm at ATrpms.net
Fri Mar 10 10:23:46 UTC 2006


On Fri, Mar 10, 2006 at 11:12:42AM +0100, Arjan van de Ven wrote:
> On Fri, 2006-03-10 at 09:44 +0100, Axel Thimm wrote:
> > 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.
> 
> 
> there is no good solution ;(
> because even if it said 2.6.16... that's not enough. the api is still
> changing and you'd get patches like "fedora claims 2.6.16 but it's not,
> so now we need to back down one level".

But in practice most external kernel module projects will work, and if
it should break it breaks exactly like against upstream kernel
sources, so Fedora isn't the guilty part of this chain. You can toss
the ball back to the kernel project.

> So your proposal would trade the issue from one side, for an issue from
> the other side.

Well, for one I'm not making any proposal, I'm just presenting this
issue for discussion. But I do think that not changing the SUBLEVEL
would be better. It's upstream after all, and modern Fedora Core has
upstream written all over it.

> Depending on where in the release cycle the exact cut is, either can
> be worse (eg the earlier the cut the more accurate 2.6.15 would be,
> the later the cut the more accurate 2.6.16)
> 
> So all in all... I think this is just an evil that external modules need
> to live with as price for being external; it's effectively just the same
> price they pay for the non-stable kernel API in general.

From a marketing POV, a Fedora user tries to build kernel project
foo. He fails against the Fedora kernel and upstream advises to try
vanilla or some other distribution. He succeeds and the Fedora kernel
get's the blaim. That happens all the time.
-- 
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/e85c9b8b/attachment.sig>


More information about the fedora-devel-list mailing list