On Tue, 2011-01-04 at 17:23 -0800, Russ Allbery wrote: > 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. However, the upstream policy for stable updates does not support this. > 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. This is why DKMS has the facility to build packages for installation elsewhere. > 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. [...] Note that Red Hat does maintain the ABI for most functions, even though it change the uname release. If you package OOT modules using the 'KMP' macros for RPM, binary modules will be sym-linked into a 'weak-updates' subdirectory for a newer kernel if their symbol dependencies are still met. We could try to implement something like that in Debian. 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