Quantal meta package review [RFC]
Leann Ogasawara
leann.ogasawara at canonical.com
Fri May 18 17:11:19 UTC 2012
On 05/18/2012 08:49 AM, Tim Gardner wrote:
> Quantal kernel flavour and meta package carnage
>
> Pursuant to UDS blueprints, the kernel team has collapsed multiple 12.04
> x86 flavours into one 12.10 flavour, e.g. generic. We've modified kernel
> packaging for x86 such that it is delivered in 2 packages. This is to
> accommodate the needs of virtual instances where the smallest possible
> kernel package is desired.
>
> The general relationship rules for kernel meta packages are thus:
>
> linux-headers-<flavour> - depends on the kernel headers package.
> linux-image-<flavour> - depends on the kernel and extras binary packages.
> linux-<flavour> - depends on linux-image-<flavour> and
> linux-headers-<flavour>.
>
> The exception is linux-image-virtual which only depends on the kernel
> binary package and not the extras package. Linux-image-extra-virtual
> depends on both kernel and extras packages.
>
> Note the dependency of linux-<flavour> on the appropriate headers
> package. This is now common across all architectures.
All of the above looks good to me. Just a few comments inlined below...
> The interesting Quantal kernel meta packages are as follows:
>
> [i386 amd64] linux → linux-generic
> [i386 amd64] linux-image → linux-image-generic
>
> [i386 amd64] linux-headers-generic → linux-headers-ABI-generic
> [i386 amd64] linux-image-generic → linux-image-ABI-generic,
> linux-image-extra-ABI-generic
> [i386 amd64] linux-generic → linux-image-generic, linux-headers-generic
>
> [i386 amd64] linux-headers-server → linux-headers-generic
> [i386 amd64] linux-image-server → linux-image-generic
> [i386 amd64] linux-server → linux-image-server, linux-headers-server
>
> [i386 amd64] linux-headers-virtual → linux-headers-generic
> [i386 amd64] linux-image-virtual → linux-image-ABI-generic
> [i386 amd64] linux-image-extra-virtual → linux-image-virtual,
> linux-image-extra-ABI-generic
This could be simplified to linux-image-extra-virtual →
linux-image-generic in which case do we really need to have a
linux-image-extra-virtual meta package? Seems unnecessary to me or does
this resolve an upgrade path from Precise?
> [i386 amd64] linux-virtual → linux-image-virtual, linux-headers-virtual
>
> [armel armhf] linux-headers-omap → linux-headers-ABI-omap
> [armel armhf] linux-image-omap → linux-image-ABI-omap
> [armel armhf] linux-omap → linux-image-omap, linux-headers-omap
>
> [powerpc] linux-headers-powerpc64-smp → linux-headers-ABI-powerpc64-smp
> [powerpc] linux-image-powerpc64-smp → linux-image-ABI-powerpc64-smp
> [powerpc] linux-powerpc64-smp → linux-image-powerpc64-smp,
> linux-headers-powerpc64-smp
>
> [powerpc] linux-headers-powerpc → linux-headers-powerpc-smp
> [powerpc] linux-image-powerpc → linux-image-powerpc-smp
> [powerpc] linux-powerpc → linux-powerpc-smp, linux-headers-powerpc
Since we dropped the non-smp powerpc flavor in Precise, I think we
should just drop the linux-powerpc, linux-image-powerpc, and
linux-headers-powerpc meta packages from Quantal and have them reaped
from the archive just like we'll do for generic-pae. It doesn't seem
necessary to carry them if they just re-direct to the powerpc-smp
flavor. I believe I already transitioned the non-smp powerpc flavor in
Precise to the powerpc-smp flavor so the upgrade path should already be
in place:
commit 19a10a6c255f5adcc313be3268d75f426187fcfd
Author: Leann Ogasawara <leann.ogasawara at canonical.com>
Date: Mon Mar 26 07:20:47 2012 -0700
UBUNTU: Point powerpc meta to powerpc-smp meta
Doing so will allow us to completely remove the non-smp powerpc flavor
in P+1
Signed-off-by: Leann Ogasawara <leann.ogasawara at canonical.com>
> [powerpc] linux-headers-powerpc-smp → linux-headers-ABI-powerpc-smp
> [powerpc] linux-image-powerpc-smp → linux-image-ABI-powerpc-smp
> [powerpc] linux-powerpc-smp → linux-image-powerpc-smp,
> linux-headers-powerpc-smp
Everything else looks fine. I assume we'll implement this only after we
re-instate the i386 generic flavor.
Thanks,
Leann
More information about the kernel-team
mailing list