On Sat, 2010-12-18 at 09:26 +0100, Julien BLACHE wrote: > reopen 607368 > submitter 607368 ! > thanks > > Hi, > > I am sorry that I have to reopen this bug, but first this is about more > than just smp_ops and second the outcome isn't satisfactory. > > Whether a symbol is exported for a specific purpose or for general > usage, whether you like it or not, every symbol that is exported is part > of the ABI. If it changes, the ABI changes and it changes for everybody, > regardless of whether they're supposed to be using that symbol or not. No distribution promises that all exported symbols will be unchanged. Some distributions provide a list all exported symbols which can be depended on not to change. We haven't done that but we do consider where symbols are used before deciding a change can be ignored. (As an example, there are several sets of drivers for related hardware in which one core module exports symbols to the specific driver modules. Those exports should in no way be depended on by OOT modules.) > We would not accept that behaviour from a shared library, I don't see > any reason why we would accept it from the kernel. This is not true; for example, the interface between libc and NSS is not stable. > As it stands, the kernel ABI number has just been rendered useless; I > can no longer trust it nor rely on it. Every kernel revision will have > to be tested to make sure all modules are still compatible with the new > ABI, given the ABI will change silently without bumping the ABI number. > > Unsuspecting users will have their setup break upon reboot after > updating their kernel packages without any obvious clue as to what > caused the breakage. > > This is a big deal as it puts a big question mark where the kernel ABI > number used to be. This is a problem for users, admins, ISV, vendors > higher up the chain, everybody. It's no longer possible to offer > certified modules for Debian kernels given the kernel ABI number cannot > be relied upon anymore. If someone claims to certify something about future Debian kernels without talking to the kernel team, they are a fraud. > Out of tree modules exist and you can't just ignore them; in some > environments they are necessary to make things work and you won't have a > way around that. Example? > So I am asking you to reconsider your position and go back to strictly > maintaining the kernel ABI number. This situation is a big step backward > for the Debian kernel packages and I hope it'll be fixed soon. 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