On Mon, 27 Dec 2010, Ben Hutchings wrote: > On Sun, 2010-12-26 at 15:55 -0800, Don Armstrong wrote: > > 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.
So in this case, if it was clear that the change would have broken an OOT module, the kernel team would normally either postpone the change, or change the ABI number. > 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. Ok. For some reason, I hadn't originally noticed that this was concerning an OOT module which Debian itself didn't actually distribute. [Julien: I'm correct in that, right?] But that's probably fine. > > How are the symbols that those OOT modules use communicated to the > > kernel team? > > They aren't. Would putting the onus on OOT maintainers to maintain such a list be of benefit to the kernel maintainer team? > > 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. Makes sense. What about this case? What should Julien do? Julien: Are you currently shipping a kernel in production which would be affected by this change if we don't change the ABI number? Or does this only affect cases where you are testing squeeze? Could it be worked around by using DKMS or similar with prebuilt binaries and requiring exact kernel version dependencies? Don Armstrong -- I don't care how poor and inefficient a little country is; they like to run their own business. I know men that would make my wife a better husband than I am; but, darn it, I'm not going to give her to 'em. -- The Best of Will Rogers http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
