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? Which OOT modules are important enough to result in ABI number changes? How are the symbols that those OOT modules use communicated to the kernel 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? > > A slightly wilder alternative, is to Provides: > > linux-kernel-abi-2.6.32-vmware-5 or something for out-of-tree > > modules which aren't going to be covered by the main ABI, but are > > important enough to require compatibility. > > I refuse to support any specific OOT module in this way unless paid > to do so. I expect that other kernel team members will tell you the > same. I personally don't think a Provides: solution is going to be feasible for technical reasons, and coordination reasons. Lets restrict ourselves to discussing the technical reasons why a solution is infeasible, rather than possible monetary impetus required to implement them. Don Armstrong -- No matter how many instances of white swans we may have observed, this does not justify the conclusion that all swans are white. -- Sir Karl Popper _Logic of Scientific Discovery_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
