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

[Josh Boyer]

On Thu, Oct 18, 2012 at 11:15 AM, Matthew Miller
<mattdm at fedoraproject.org> wrote:
> On Thu, Oct 18, 2012 at 10:44:58AM -0400, Josh Boyer wrote:
>> > I'm open to this idea, but I think it's nicer if one can go from the reduced
>> > selection to the full just by adding in the right package, not changing or
>> > removing things. Unlike PAE or etc., I don't think we'd actually build
>> > anything differently (would we?).
>> Of course we would.  The entire point is to reduce the size, and the
>> only way to reduce the size is to build it with different config
>> options.  And we're not talking about going from kernel-virtguest to
>> kernel by installing kernel-everythingnotinvirtguest.  That's still
>> going down the "split the kernel up into a bunch of subpackages" route
>> which just creates more work for the maintainers.
>
> We already have kernel-modules-extra. I think the idea would be to add
> kernel-modules-virt and kernel-modules-normal to that, at most. (Or, put the
> virt modules in kernel, and just add one more subpackage,
> kernel-modules-normal.) There's already code in the spec file for dealing
> with modules-extra, so it's mostly a matter of extending that slightly --
> not doing something entirely new, *and* not going down the alarmist slope of
> a horde of subpackages.

I'm aware of what the idea is.  I'm saying it's not as simple as it
sounds.

modules-extra is a pain.  The only reason it still exists is because it
is filled with modules that hardly anyone uses.  Extending the idea to
deal with modules that a large number of people use is a headache
because then you have lists to maintain and move around even more than
we already do.  Automating it isn't as simple as it sounds because the
module dependencies change from kernel to kernel and you wind up getting
things shifted because some module you had in one package depends on
another going into a different package, etc.

modules-extra started as a middle ground between leaving little used
drivers in the main package and not building them at all.  If I had to
do it over, I'd just not build them at all.

Now another kernel flavor, like kernel-virtguest, with different config
options is _not_ new.  It's much easier to add, much easier to maintain
and is how we've done things pretty much forever.  I realize it isn't
necessarily the utopia you're looking for, but we live in reality not
utopia.  It's achievable and fairly maintainable.

>> At the moment though, all of this is just talk anyway.  If something
>> like this is to happen, someone actually has to do work.
>
> Start with an idea, discuss it, come up with a plan, find resources for that
> plan, and then implement. Sometimes things happen the other way around, but
> only when we happen to be lucky, and it often has consequences like extra
> ongoing work with no support. So, just talk is an important place to start.

OK.  So here's a more blunt response.

I'm really against splitting the modules up into more subpackages,
regardless of how many it is.  I will not spend any time looking at how
to do that.  I won't spend time discussing further plans to do something
I don't feel is maintainable.  If you find someone willing to, great.
Post patches to the kernel list and we'll review them.  But I'm telling
you now that it will be an uphill battle.

This is not me being stubborn, or cranky, or an a-hole.  This is me
trying to save time for all involved, both in the planning phase and in
the long term maintenance of any solution.

josh