On Mon, May 24, 2004 at 02:56:36PM +0200, Michael Banck wrote: > On Mon, May 24, 2004 at 09:17:38AM +0200, Jens Schmalzing wrote: > > Christoph Hellwig writes: > > > > > What's the problem with a single source package again? > > > > A new upload will trigger the autobuilders and result in new > > kernel-image packages for all architectures, even if the change only > > affects a single architecture. This means that kernel packages that > > have not been tested at all on some platforms will be let into > > unstable. > > I don't believe this is an issue. It would be trivial to exempt the > kernel from being autobuilt, on a buildd-by-buildd basis[1]. > > This way, one could skip 'known-bad' versions for a specific > architecture and/or have the arch maintainers upload the packages > manually. > > Probably harder would be to tune testing to let only specific arches of > one kernel version into testing, as I believe packages propagate to > testing by source packages. > > One possibilty would be to manually push kernel images into testing once > their respective arch maintainer as declared them stable (as has been > done for debian-installer until recently). Other possibilities would > probably include hacking the testing scripts to special-case kernels. > > That's just pointing out my technical POV, without commenting on the > social 'multiple-vs-single-source-package' problem.
And who would make the releases ? This is ok for the d-i case, where the packages are rather small, and there is no big problem having many people upload mutliple package versions in the same day, but for kernel packages it will probably be a bother. And consider that the linux-kernel-di common package did in the end still be split per arch, for technical reasons though, but this allowed more flexibility in the uploads. It would say that the two postitions are not antagonistic, that you could still have a single kernel-source package, but still maintain the per arch (and even per subarch) patches. The ideal would be to have all the per arch and subarch patches merged into the global kernel-source package, leaving empty or almost so per arch patches, but still keeping the flexibility and quickness of response to the per arch maintainers to do tests or add patches that are not clean enough to go into the common package or whatever. But still, the migration of the per arch patches into the common kernel-source package would be a good thing, and one which is not contradictory with the above situation. Also, notice that the kernel-source package contains today the debian kernel, and that the patches need to be removed from it in order to obtain the pristine upstream source, which i find rather a nice thing. Friendly, Sven Luther
