Re: Bug#607368: Please decide how kernel ABI should be managed
Don Armstrong <firstname.lastname@example.org> wrote:
> 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
You are correct.
> 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
I have 30 beta-testers that are affected by this issue on the
workstations they have started using for their everyday work. Although
it's still a beta phase, at this point, these workstations are to be
considered "in production" given the users have basically made the
Full deployment involves over a thousand workstations.
> worked around by using DKMS or similar with prebuilt binaries and
> requiring exact kernel version dependencies?
DKMS is useless if the ABI number doesn't change, in its current
form. If DKMS was changed to rebuild all modules when the kernel package
is upgraded, we'd still have issues with on-disk modules not matching
the running kernel ABI until the machine is rebooted. This can sometimes
take two or three weeks if a long-running computation is running on the
We switched to DKMS to reduce the maintenance cost associated with
prebuilt binaries. We'd rather not come back to that if we can help
it. It also adds a delay to kernel updates that we'd rather avoid.
As to using strict dependencies... it makes all of the above even
And I'll ask again: what's the point of the kernel ABI number if we have
to use strict dependencies? Seriously?
We need a kernel ABI numbering we can rely on.
Julien BLACHE <email@example.com> | Debian, because code matters more
Debian & GNU/Linux Developer | <http://www.debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169