Bug#607368: Please decide how kernel ABI should be managed
Ben Hutchings <ben@decadent.org.uk> writes:
> Do pay attention. We were discussing the implications of changing our
> current practice of trying to avoid ABI bumps during freeze and stable
> updates. We would then probably change the uname release (the ABI
> identifier) in each version of the package.
This is certainly becoming more appealing with DKMS, but with my Stanford
sysadmin hat on, I have to admit that we'd find it rather annoying if the
ABI changed in stable. I think that may be a good way to go in unstable
and testing up to the release, but it would be very nice to not do that
after the release.
With hundreds of servers, we'd rather not install compilers and DKMS on
every one of them, and with lots of machines, the loss of reproducibility
from separately compiling the modules on every system is an increasingly
large drawback. We currently build internal packages (from the *-source
packages provided by Debian) for those external modules that we use so
that we can deploy the same thing everywhere, and having to rebuild
modules for every kernel update and deploy those new builds with the
kernel update would be fairly annoying. With that system, we know for
sure that if the module mysteriously fails on one system but not on
others, it's not because it's a weird build or has some other compilation
issue.
In fact, we know almost exactly how annoying it would be, since Red Hat
has this policy, and it's been a major pain. The handling of the kernel
versioning in stable is currently one of the major selling points for
Debian over Red Hat for us. The very few times an ABI change was forced
in Debian stable due to some security issue, we had to put a fair bit of
work into making sure that everything was upgraded properly everywhere to
the new ABI.
(So thank you very much for all the work that you put into maintaining the
ABI!)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: