On Thu, Mar 24, 2005 at 04:31:24AM -0500, Andres Salomon wrote: > > Now, for this to be fully efficient, there is still a little change that > > needs done to d-i. Support for the kernel meta-packages for all arches. > > A common kernel-official or whatever package will be created, including > > all the kernel-latest or whatever fixes, and base-installer will > > exclusively install those packages (altough at lower priority it could > > propose to bypass them or something), since this is needed to make > > abi-breaking arches kernel security uploads transparent to the user > > doing an apt-get upgrade. > > Ok, this is my proposal, i am waiting for feedback, and i hope those > > that put me in your blacklist would reconsider and still follow up on > > this proposal. > One of the things not mentioned was ABI stuff. I implemented an > ABI-check-during-build for ubuntu, but I don't feel that's a long term > solution; really, I don't care for our current ABI handling at all. I > don't want to deal w/ package renames, nor do I want to deal w/ toolchain > breakage fucking our ABI, and other misc things that might happen. I > had intended to brainstorm w/ fabbione and other people at the next > ubuntu conference regarding this, but I'll mention my thoughts now, as > well. > We can assume, if the user is keeping up on kernel upgrades, that they > either have a kernel build environment installed, or have a central > machine that does builds for them. If they're not keeping up on > kernel upgrades.. Well, they should be, unless they're completely > disconnected from the internet or something. There is always some manual > work involved during an ABI-changing upgrade; every upgrade means a > rebuild of third party modules on some machine. > 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. 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 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 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. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature