[RFC PATCH] Add modules-extra subpackage

[Josh Boyer]

On Sat, Nov 19, 2011 at 1:33 PM, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> Hi!
>
> On 18.11.2011 15:52, Josh Boyer wrote:
>> Below is the first swag at a kernel-modules-extra package.
>
> A little bit of background and reasons for this move would be nice. I
> assume it was mentioned somewhere already, but seems I missed it.

There are a couple of reasons I can think of.

1) There is a bunch of cruft that is rarely used.  We were actually
kind of split on whether or not to just disable things like AFFS/BFS,
etc or to create a subpackage.  The subpackage route won because we
didn't want to disable something and then require some kind of
popularity context/bugzilla ME TOO-fest for requesting it to be
re-enabled.  Maybe we were just chicken.

2) Following along with the above, all of that cruft is something of a
security exposure.  We've had cases where esoteric modules get
auto-loaded by the system due to inadvertent errors, and some of these
modules seem to have a bad history with security (like sctp).
Stuffing them into a subpackage doesn't lessen the individual module
security issues, but it reduces the attack surface of a default
install by a little.

3) Bloat.  Now, you might look at the scratch build and say "the
example list only moved 3MB worth of modules and that isn't much".
You would be right.  But that is just an example build.  If we aren't
going to disable them (see 1) then moving them to something that isn't
installed by default will at least save a bit of disk space.  Disk
might be cheap, but at least then you could use that extra 3MB to
store more Justin Bieber pictures, or KDE configuration settings, or
whatever floats your boat.

> Anyway, two minor comments:
>
>> [...]
>>  kernel.spec    |   69 ++++++++++++++++++++++-
>> [...]
>> diff --git a/kernel.spec b/kernel.spec
>> index b72afb3..9eadbb1 100644
>> --- a/kernel.spec
>> +++ b/kernel.spec
>> [...]
>> +# This macro creates a kernel-<subpackage>-modules-extra package.
>> +#    %%kernel_modules-extra_package <subpackage> <pretty-name>
>> +#
>> +%define kernel_modules-extra_package() \
>> +%package %{?1:%{1}-}modules-extra\
>> +Summary: Extra kernel modules to match the %{?2:%{2} }kernel\
>> +Group: System Environment/Kernel\
>> +Provides: kernel%{?1:-%{1}}-modules-extra-%{_target_cpu} = %{version}-%{release}\
>> +Provides: kernel-modules-extra-%{_target_cpu} = %{version}-%{release}%{?1:.%{1}}\
>> +Provides: kernel-modules-extra = %{version}-%{release}%{?1:.%{1}}\
>> +Provides: kernel-modules-extra-uname-r = %{KVERREL}%{?1:.%{1}}\
>
> Do we really need all of those provides? Yes, they are derived from the
> provides in the main package, but I wonder if we still need all of those
> there and if it's worth adding similar ones to this new subpackage.
> Maybe trimming the list of provides in the main package in the long term
> might be something to think about. In addition:

Good point.  Copy and paste was easy, but I agree it might be worth
looking at why all of this is listed for Provides.

>> +Requires: kernel%{?1:-%{1}}-%{_target_cpu} = %{version}-%{release}%{?1:.%{1}}\
>
> Just FYI: Kmod2 packages in some popular add on repo depend on the
> kernel they were build for with this:
>
> kernel-uname-r = 3.1.1-2.fc16.x86_64
>
> That seems to work well afaics. I think there was a reason back years
> ago why we settled for this strategy and did not use the requires you
> chose -- but I can't recall it and maybe it's not relevant any more
> these days anyway (and maybe my mind comes up with the reason seconds
> after sending this mail...).

I can add both Requires methods, or switch.  I just picked one to make
sure it wasn't free-floating for the scratch build.  If you remember
the reason for the other (which looks like something dkms or kmod
would use at install time) then let me know.

Thanks for taking the time to look it over!

josh