* Steve Langasek ([EMAIL PROTECTED]) [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
