On Tue, Apr 01, 2014 at 12:50:33PM -0400, Josh Boyer wrote: > This creates kernel-core and kernel-drivers subpackages. The kernel package > remains as a meta-package the requires both of the subpackages. This allows > most installs to continue on as-is with upgrades working. > > The contents of the kernel-core and kernel-drivers subpackages are determined > at build time through the filter-modules.sh script. This script "removes" > pre-defined subsystems and modules and generates a filelist for the %files > section of each subpackage. The contents of each are per-arch, with arch > override files taken into account. This allows us to make the split useful > for varying arches. I think there needs to be a little bit more documentation surrounding this. If one simply cracks open a filter-$arch.sh file, they really don't get any clue how these two variables are used, where things listed end up, etc. A blurb in each of them explaining "files added to these lists are excluded from kernel-core and stashed in kernel-drivers" (assuming I even got that much right from a quick read) would be useful. Somewhere down the road, I'm sure someone other than yourself will need to make a change to one of those lists. I'm pretty familiar with the kernel spec myself, and without some trial and error, poking at builds, I can't say for certain I actually understand exactly what ends up where. Now, as for reusability... No clue if this is something that would be desired down the road in Red Hat Enterprise Linux (RHEL). Making this a toggle-able (e.g. --with split) option would be potentially nifty, but with all the macro crud, a hideous mess to implement. I can see this being potentially useful in the RHEL case too though -- people installing virt appliances, barebones servers, etc., might like the disk space savings not having tons of useless drivers installed too. I think we can make the case that its a good idea to split things up this way, and worst-case, its not horrendously hard to gut things back to the way they are now. Some questions: 1) Is there a default destination for any "new" driver that shows up in the tree? I assume that will partly depend on where it ends up in the file system hierarchy, but maybe it is something that needs to be monitored to prevent sudden and unexpected bloat to -core (i.e., new subsystem gets enabled by way of some kconfig option, all winds up in -core, increasing its size significantly). 2) What criteria are being used to determine what goes into core? The Fedora feature page says core is "a minimum(-ish) set of drivers to only just be able to run in virtualized environments", which I hadn't read yet when I suggested maybe RHEL barebones servers would use this. I think I'd like to see a bit larger core than just-enough-for-virt myself. To me, what anaconda needs to install a system and get it on the network to receive updates maybe better describes what I'd consider core than just-enough-for-virt does. No clue how bit the delta is there though. HTH, -- Jarod Wilson jarod@xxxxxxxxxx _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
