Re: creating kernel udebs from kernel-source
On Mon, Nov 29, 2004 at 10:54:32PM +0100, Thiemo Seufer wrote:
> 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.
I disagree, the arches in question simply have to include their own patches in
the kernel-source package, and work more closely with the debian-kernel team,
that's all. I was not in favor of this in the start, but after consideration,
i beleive it is a good approach. We only need support on per arch patch
application in the main kernel-source package, and better coordination of the
non-mainline kernels with the rest of the debian-kernel team, and some release
management of kernel package which takes in account that the slower arches may
take ages to build kernels. (it will probably take around 6-12 hours on the
powerpc autobuilders for example :).
Friendly,
Sven Luther
Reply to: