On Wed, Oct 17, 2012 at 2:38 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On 10/17/2012 11:32 AM, Chris Adams wrote:
>
> I would think the only "sane" way would be to just change the packaing,
> not actually build multiple kernels (or even multiple packages with
> kernels).
We already build multiple kernels. All from the same source, but still
multiple kernels with different config options. E.g. PAE, debug, etc.
> For example, a "kernel-minimal" that has the kernel and
the "core"
> modules loaded in most installs (e.g. filesystems like ext4 and NFS, dm,
> network support like ipv6 and iptables, and virtio-type drivers), a
> "kernel-common" that has the rest of the current contents of
"kernel"
> (and probably obsoletes "kernel"), and then the current
> "kernel-modules-extras".
>
> There will always be requests to move modules from -common to -minimal,
> and it shouldn't be a big fight (I would bet most requests would be
> pretty obvious). That already exists some for -modules-extras.
You'd want to do it something like that.
kernel-minimal as you say but with a Provides: kernel, kernel-common as you
say.
I'd introduce a third metapackage just "kernel" that requires both of
those
and implicitly Provides: kernel. Most people would just get the "kernel"
metapackage when a transaction asks for something to provide "kernel", but
if you explicitly ask for kernel-minimal you'd get just the minimal.
This would all be done from one kernel spec and built out at the same time.
We've got a lot of new infrastructure coming for kernel builds and we don't
want to make things even more complicated by having to do multiple rpm build
runs.
All of this can probably already be done with a new 'flavor' in the
existing kernel.spec. I really wouldn't do the common/minimal split
though. It just makes it more complicated for not a whole lot of gain.
The idea that Dave, Justin, and Kevin all had simlutaneously about
doing a 'kernel-virtguest' might be worthwhile if someone wants to
spend time poking at a config, etc.
josh