Andreas Barth wrote: > * Thiemo Seufer ([EMAIL PROTECTED]) [040524 17:25]: > > With a single kernel package, you'd have to wait with a new i386 release > > until the user of one of the more obscure mips subarchitectures gave it > > a try on his box. That's simply not practical. > > > > Btw, so far nobody explained why a single kernel package should be > > beneficial. In the ideal case, the arch-specific one contains only > > the debian/ directory and the kernel config files. It's nearly zero > > effort to keep it that way, and it allows much more leeway to handle > > less ideal cases. > > Reducing the size of the arch-patches and also namespace they touch to > debian and arch would certainly be a good thing.
Sure. > However, a kernel source package that is able to build binary packages > on more than one platform would make the management of the security > updates for the security team easier - at least to what the security > team says itself, and I trust them. A single kernel _source_ package, right. This works already well for generic security issues, and with a better integrated 2.6 kernel, there are good chances it will work for most arch-specific issues as well. On the other hand, if a security issue affects only $RANDOM architecture, we should be able to handle it without bothering millions of debian users with a competely nonsensical kernel update. > For me, the goals are (with priority 1, 2, 3): > 1. Reduce the number of kernel-source-*-packages in sarge to 1 or at > maximum 2 (for each of 2.2/2.4/2.6).[1] Agreed. > 2. Reduce the arch-specific patches to debian/ and arch/. Plus some arch-specific drivers. A worthwile goal, but probably not fully reachable all the time. > 3. Make it possible to build the binary packages on as many > architectures as possible without any manual interaction, and > without applying any patches. Huh? A kernel package which fails to autobuild is broken. Thiemo
