On Wed, Jun 02, 2004 at 12:14:58PM +0200, Christoph Hellwig wrote: > > linux-kernel-KVERS-ARCH(-SUBVERS) (plus extras, see below) > > remov the -kernel, linux is the kernel, and upstream tarballs are > linux-$version, too. > > remove the -arch, it'll be .$arch.deb anyway, rather add a -flavour.
This creates a source package conflict, since presumably each architecture still has its own source package - but I see that you disagree with this presumption below... > > > * architecture support patches hard to apply unless the main kernel-source > > package is "pristine" > > as mentioned a few times architecture packages should be part of the > main kernel-source to avoid a big maintaince mess I believe its a greater maintenance mess to attempt to keep them united. I can be more confident that upstream's ia64 arch patch will apply reasonably well to a kernel-source tree, like what we have today, than if we try to merge all of these architectures into a single mainline tree. And, I'd prefer to let upstream kernel maintainers deal with the best way to perform these merges when they believe it is ready. There's also the infrastructure load that has been brought up on this list. If we share a kernel-source tree (no arch packages), then each upload requires a build on all architectures, and the corresponding storage space on our mirror system. This would add an unnecessary barrier to entry for me to fix a few bugs in my package & do an upload: <!ia64-1> argh! the ia64 maintainer guy did another upload to remove a known-useless module; there goes the change my package will get buildd'd today... <!ia64-2> *sigh* - guess that means i get to download another 30MB & reboot for a zero change update... I don't believe the security team gains anything by merging trees; in fact, I think its a disservice. Imagine the case of an s390-specific exploit - having to build on 11 arches to deal with that surely won't save them any time. And then, imagine that a cross-arch patch fails to compile on hppa - getting that FTBFS failure resolved will delay package availability for all others. >From my conversations with Joey, the problem with today's scheme is that they >can't just patch one source tree & do rebuilds, since everyone is on different kernel revisions and some (ia64 in woody, for example), don't even use a kernel-source package. Whether they're transporting a single kernel-source package between arches during this period or rebuilding kernel-image packages doesn't sound like the time critical issue.