Re: a kernel plan for sarge and beyond ... (Was Re: ABI-changing kernel security fixes for sarge)
(ignoring -release followup-to, since it affects -kernel and -boot as well)
On Thu, 24 Mar 2005 03:24:53 -0800, Steve Langasek wrote:
> On Thu, Mar 24, 2005 at 04:31:24AM -0500, Andres Salomon wrote:
[...]
>> My idea is to do away w/ ABI considerations, and instead compile modules
>> in the kernel's postinst. This would happen for every kernel upgrade, iff
>> there are third party modules registered w/ the system. The way this
>> might look is:
>
>> - hostap-source installs /usr/src/modules/hostap.tar.bz2, and depends upon
>> gcc, make, bzip2, and module-assistant.
>> - kernel-image-2.6.10-686 (pre-?)depends upon kernel-headers-2.6.10-686.
>> - During k-i-2.6.10-686's preinst, for each module tarball in
>> /usr/src/modules, untar and build using module-assistant. If any build
>> fails, abort the upgrade/install. If all builds succeed, proceed with the
>> upgrade/install
>> - During k-i-2.6.10-686's postinst, for each module tarball in
>> /usr/src/modules, install the appropriate module package (built in
>> preinst).
>
> A pre-dependency on kernel-headers doesn't seem to guarantee that gcc,
> module-assistant, or any of the module-source packages are in a usable
> state. Currently nothing depends on kernel-images, so re-running the
> dist-upgrade should be enough to fix this case without hitting nasty dep
> loops, but even that seems much more awkward than I'd like.
Indeed, we'd need to figure out a better dependency solution; I wouldn't
expect users to have to dist-upgrade twice if gcc/modass/etc aren't usable.
>
> Is it your intention that in such a system, the core kernel-image packages
> would no longer declare abinames at all? That would mean either gratuitous
That is correct. The goal is to drop package renaming.
> recompiles on every revision of a kernel-image package, which is slightly
> irritating; or failing to provide a smooth downgrade path in the event of an
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.
> ABI change that coincides with a silently broken module, which is truly
> ugly. The idea of automatically recompiling modules sounds good to me,
> but I still think it needs to be coupled with kernel ABI tracking to
> avoid the risk of slagging the user's initrd.
How would the initrd get slagged? It would need to be regenerated, of
course, during the upgrade to pull in newly built modules.
Reply to: