On Sun, 2010-12-26 at 15:55 -0800, Don Armstrong wrote: > On Sun, 26 Dec 2010, Ben Hutchings wrote: > > On Sun, 2010-12-26 at 12:23 -0800, Don Armstrong wrote: > > > or possibly by using Breaks: for all of the affected out-of-tree > > > modules where the change wasn't wide-spread enough to bump the ABI > > > number. > > > > No. Firstly, if we know that an ABI change would break an OOT module > > then we try to avoid making that change. > > Ok. And am I correct in assuming that if the ABI change would break an > OOT module, you would normally change the ABI number? In the time I've been involved in the kernel team, I haven't yet seen a case where a bug fix required an ABI change that I knew would break an OOT module. I understand that in the past the kernel team has deferred such bug fixes and eventually applied such deferred changes as a batch while changing the ABI number, after coordinating with affected people (such as the d-i and CD teams). > Which OOT modules are important enough to result in ABI number > changes? We don't have a formal policy but I think we consider OOT modules that (1) appear to be used in production and (2) have published source code for at least the part that directly uses kernel symbols. Anything distributed by Debian should meet those qualifications, but users such as Julien also care about modules from other sources. I normally use Google Code Search to check for OOT modules using symbols that have changed ABI and which I think might be ignorable. > How are the symbols that those OOT modules use communicated to the > kernel team? They aren't. > What does the kernel maintainer team feel should be done by the > maintainer in this case to ensure continuity of upgrades and rebuilds > of the OOT modules? [...] We recommend that OOT module package makes use of DKMS. DKMS includes hook scripts to trigger rebuilding OOT modules automatically for each new kernel ABI version, if the end user or administrator installs the module source and the appropriate linux-headers package. In a more tightly controlled environment where such packages should not be installed on production servers, the administrator must rebuild modules elsewhere and deploy them along with the kernel upgrade. DKMS provides various means for this. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part