Modular Kernel Packaging for Cloud

[Josh Boyer]

On Wed, Mar 05, 2014 at 11:33:57AM -0600, Justin M. Forbes wrote:
> 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.

Yeah, this is the biggest downside to auto-generated Provides for
modules.  I haven't had time to flip the switch and see how much it
impacts things yet.  If it results in any form of noticable impact we
need to think long and hard about whether it's actually worth doing.

josh