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