Re: creating kernel udebs from kernel-source

[Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>]

Andres Salomon wrote:
[snip]
> b) Get archs autobuilt, so that they don't lag behind.  They may not boot,
> but they'll at least compile.  Given the way that kernel development
> upstream is happening, the development process will look something like
> this: 1) release k-s 2.6.10-1, upload i386 images, 2) autobuilders for all
> other archs attempt to build arch-specific images, 3) many fail; the
> kernel is therefore kept out of etch, 4) k-s 2.6.10-3 is uploaded (after
> -2 fixes some build failures as well), 5) autobuilders successfully build
> for all archs, 6) testers report bugs for archs that don't work;
> obviously, an arch-specific RC bug will keep a kernel out of etch, 7)
> after developers fix arch-specific bugs, k-s 2.6.10-4 is uploaded and
> autobuilt, 8) k-s 2.6.10, now that it builds and runs on all (used) archs,
> flows into etch.
> Of course, there's a good chance there may be some arch breakage on a
> rarely used arch, and the package gets into etch w/ the breakage; however,
> I'd rather see that than the arch sticking w/ a kernel version that's a
> year old, has known security holes, but boots.

This "Hooray, it compiles!" approach is unlikly to ever produce an
useful kenrel for architectures not maintained in mainline.

> 3) Simplify packaging.  Dump the kernel-tree-X crap, etc.  The cons of
> this are that one will no longer be allowed to build against an older,
> known-working k-s.

Which means those architectures will still need a source package they
can build-depend on, generated from the -image source. This is a minimal
workload reduction for the kernel team but an increase for the security
team.


Thiemo