Re: http://debian.linuxwiki.de/DebianKernel_2fPlan

[dann frazier <dannf@dannf.org>]

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.