On Mon, May 24, 2004 at 06:13:35PM +0200, 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. > > 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.
Bah, i don't really believe so, not sure though if my experience is reproducable on other arches. Mostly the per arch patch doesn't intersect with the security fixes, and so you only have to get access to the security kernel-source package, and rebuild the kernel-image package with it, importing the changelog entries (but making sure to remove the bug closers). Since the security packages are not autobuilt anyway, i don't see how you could much simplify this. A much worse problem is that sometime there are multitude of kernel-source packages around, some who even are missing, and that the security fix needs to be applied to all of those. Friendly, Sven Luther
