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". So your proposal would trade the issue from one side, for an issue from the other side. 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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
