Re: creating kernel udebs from kernel-source
Hi Fabio,
Thanks for feeding changes back to d-k. No one else in Ubuntu has
bothered to do that thus far...
On Mon, 29 Nov 2004 08:35:03 +0100, Fabio Massimo Di
Nitto wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi everybody,
> ~ right last week i have been asked to merge the linux-kernel-di-*
> packages
> directly into the kernel-source (that in Ubuntu we call linux-source)
> so that
> all the different binary packages are built from one and only one source.
> Basically killing kernel-image packages (that was done a few months back)
> and now linux-kernel-di-*
>
Killing kernel-image packages is something that we've been planning
post-sarge (if I hadn't gotten caught up doing other stuff, I would've
started w/ 2.6.9 last week). The goals are:
a) Kill all the separate image packages, so that instead of requiring a
psuedo-package in the BTS (w/ no versioning support), we can view all bugs
for a specific kernel version (since they all come from the same source
package).
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.
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. Kernel config handling will be unified (probably
something similar to what the powerpc images do), so that there's not a
bunch of out-of-sync config options between different archs. I would
eventually like to use a cdbs-like build system for the kernel stuff, but
that's highly dependent upon cdbs gaining some necessary functionality
that it doesn't currently have (and allowing this to be implemented in a
clean fashion).
> The resulting diff of the merge (based on
our linux-source) can be found
> here:
>
> http://people.ubuntulinux.org/patches/kernel_udebs_from_kernel_source.diff
>
Patch saved on my hard drive for posterity. :)
Reply to: