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