Bug#607368: Please decide how kernel ABI should be managed
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
How are the symbols that those OOT modules use communicated to the
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
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
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_