Re: NMU: kernel

[Sven Luther <sven.luther@wanadoo.fr>]

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