Re: a kernel plan for sarge and beyond ... (Was Re: ABI-changing kernel security fixes for sarge)
* Steve Langasek (vorlon@debian.org) [050325 02:05]:
> On Thu, Mar 24, 2005 at 03:30:01PM -0500, Andres Salomon wrote:
> > That is irritating, but less so than rebooting and discovering you need to
> > run `module-assistant auto-install <foo>` to compile a module for an ABI
> > change (and if the machine requires the third party module to boot and get
> > online, fun ensues). That said, if we could get a solution to long NEW
> > processing times, then doing both in tandem (ABINAMEs + recompile hooks
> > upon ABI and major kernel upgrades) is a possibility.
> I don't believe long NEW processing times are seriously an issue here; the
> ftp team is very responsive to needs for quick processing of
> release-relevant kernel packages. The problem, AFAICT, is that it currently
> takes so many *iterations* of NEW processing to get everything updated for a
> kernel ABI change, including kernel-image packages for 11 architectures that
> arrive in NEW over a span of weeks, plus whatever module binary packages
> there are.
If we coordinate enough, we can bring it down to 4 times NEW processing.
If we're willing to build off packages that are in NEW, we can bring it
even down to 1 NEW processing for all packages. That should be
acceptable.
> Any time you rebuild your kernel binary modules, there's a non-zero chance
> that the rebuilt version will not work correctly even though it built
> successfully. If you aren't going to track ABI changes, then you have no
> backup kernel to use in this case (because you've overwritten the old one
> with a binary-incompatible one) that would let you roll back the change in
> the event that one of the modules that broke rendered your system
> unbootable.
>
> It's a standard part of my system administration practices to keep a
> previous kernel version around that I can roll back to when upgrading to a
> new version; this approach would seem to make that more awkward.
That tells me that we should consider any kernel changes as an
ABI-change.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Reply to: