On Sat, Nov 19, 2011 at 1:33 PM, Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> 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 _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel