* 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. 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] 2. Reduce the arch-specific patches to debian/ and arch/. 3. Make it possible to build the binary packages on as many architectures as possible without any manual interaction, and without applying any patches. I think we already have consensus for goal 1. I think we almost have consensus for goal 2. For goal 3, there are different opinions. But - would it be a problem if 2-3 architectures manage to reach goal 3, and the others not? It would still be a advantage in my opinion, but nobody of the maintainers who doesn't want is forced to implement it. And, let's please all work together for the common goals, because the common goals are the first ones to implement in any case - and are the more important goals. 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
