Modular Kernel Packaging for Cloud

[Justin M. Forbes]

On Wed, 2014-03-05 at 10:59 -0500, Josh Boyer wrote:
> On Wed, Mar 5, 2014 at 10:51 AM, Bruno Wolff III <bruno at wolff.to> wrote:
> > On Wed, Mar 05, 2014 at 10:08:04 -0500,
> >   Josh Boyer <jwboyer at fedoraproject.org> wrote:
> >>
> >>
> >> So you agree multi-tiered subpackages is a bad idea, but then you
> >> propose a netfilter specific subpackage?  ... Probably not.  They'll
> >> likely just be in kernel-core.
> >
> >
> > Couldn't the planned module provides allow something like this to work
> > without worry much about which modules are in which packages? netfilter
> > could juts require the modules it needs and it would pull in and extra
> > kernel module packages that are needed.
> 
> Possibly.  But it's not just the installed system to be taken into
> account.  Every additional subpackage and list is something that needs
> to be maintained and further complicates the kernel.spec file.  It
> adds to testing all the combinations of kernel packages and
> subpackages being installed (or not) and upgraded, etc.  For the sake
> of the kernel maintainers, keeping it limited is probably a good idea.

This can also have unforseen consequences.  Coming from conary, where we
had rich dependencies stored in the repository, if you start putting
module provides and depends metadata into the repositories for every
single module, the CPU time and network traffic required to even do a
simple update can grow excessively. I am not saying that there is no
solution to the problem, but I wouldn't count on it near term.

Justin