> I'd like to put a old but still valid discussion on the table again > where a solution never was found: Pre-release kernel versioning. Yes, please, and the solution is to handle the kernel rpm just like any other prerelease package. There is no reason not to adhear with the guidelines while at the same time easing life on oot modules. Sure, 2.6.35-rc1 is neither 2.6.34, nor 2.6.35, but the rc1 is typically already that much close to the final release API-wise that you will have lot less build failures and required patchwork. > kernel-2.6.22-1.3200.fc7.rc2.git15 Or even better since the extra version parts are supposed to come before the disttag: kernel-2.6.22-1.rc2.git15.fc7 If the next package contains an upstream change (rc2.git16, rc3 etc) then continue with 2.6.22-1.rc..., if it is a golden release, just go 2.6.22-2.fc7, and if it is a patch/specfile change only, then also upper the buildid. -- Axel.Thimm at ATrpms.net
Attachment:
pgpeupGCMcvbV.pgp
Description: PGP signature
_______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list
