On Thu, Mar 24, 2005 at 03:30:01PM -0500, Andres Salomon wrote: > (ignoring -release followup-to, since it affects -kernel and -boot as well) Sorry, mailer misfire, I guess. > On Thu, 24 Mar 2005 03:24:53 -0800, Steve Langasek wrote: > > 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. 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. > > 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. 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. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature