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@wolff.to wrote:
On Wed, Mar 05, 2014 at 10:08:04 -0500, Josh Boyer jwboyer@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