modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)

[David Malcolm]

On Wed, 2012-10-17 at 11:38 -0700, Jesse Keating 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).
> >
> > 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.
Random worry about this:  would this work OK with yum's "keep the last 3
kernels around" functionality?