On Thu, Jul 03, 2008 at 10:50:35AM -0400, Jarod Wilson wrote: > Red Hat suggests building once for each flavor/arch combo and being done > with it. As long as the required kernel symbols are present, they'll > keep working. You make the kernel module deps on the necessary kernel > symbols, which are provided by the kernel package. For example, the > packages provided here... > > http://rhn.redhat.com/errata/RHBA-2007-0654.html > > ...are designed to work with any version-release of a given arch/flavor > RHEL5 kernel. > > But then maybe you already knew that, and don't like that scheme much... > :) I'd love it if it would work :) > But that's what's recommended to all ISV's who build kernel modules > for RHEL5, and so far, its worked out great. Of course, if some out > of tree driver requires a symbol not on the whitelist (i.e., not in > the kernel's Provides:), you lose, but... My experience is that there is no guaranteed kernel ABI nor API by RHEL. Otherwise the kmdl builds would not start to fail between say the 53 series and the 92 ones. On every quarterly update I have to fix several kmdl packages for RHEL due to backports. Usually with RHEL4/5 these are wireless updates. Also at the very least I know of a glibc ABI discrepancy that was fixed in 62, so I'm quite sure that there is no such stable ABI yet, and since upstream will never provide one, it is very difficult for a vendor to provide one (unless in deep maintenance mode where only severe bugfixes/security issues, but no enhancements are addressed). But speaking of policies I meant more the "you are required to update withing XYZ days of an update to have Red Hat support etc.". If a kernel is not anymore supported by Red Hat or CentOS then no kmdl should be built for it. -- Axel.Thimm at ATrpms.net