On Thu, 2020-02-06 at 14:13 -0500, Josh Boyer wrote: > On Thu, Feb 6, 2020 at 1:56 PM Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> wrote: > > Hello kernel maintainers, hello Fedora developers, > > > > I'm looking into the split of kernel packages. The split into > > subpackages > > seems interesting, but there are many dependencies between the > > packages, > > so it is usual to end up with all of them installed. > > > > E.g. for a simple VM, by design, kernel-core contains a basic set > > of > > modules that should be enough to boot. I see that in a standard > > libvirt guest, the only modules from kernel-modules that are loaded > > are for sound hardware and "usbnet", all which I'd be fine without. > > > > Another example: we'd like to explore building an initramfs > > directly > > from rpms, without dracut, only systemd and a standard packages to > > bring up the hardware. Some modules need to be installed, so the > > kernel can load the from the initramfs, but the kernel itself > > should > > not, since it is provided "externally" by the boot loader. > > > > But: > > the basic modules are in one rpm with kernel-core > > kernel-core Requires linux-firmware (which is 240MB) > > kernel-modules Requires kernel-uname-r, which is provided by > > kernel-core > > kernel Requires kernel-core-uname-r, kernel-modules-uname-r > > > > Would it be possible to make some changes: > > > > - split out the modules from kernel-core package into a new > > subpackage > > kernel-basic-modules, kernel-core can Recommend or Require it > > There has to be a *really* good benefit to do this, and I haven't > seen > one described. The more splitting we do, the more management both on > the client machines and for the kernel maintainers themselves. The > way modules are filtered is terrible (I wrote it, so I can say that) > and requires people to keep it updated as the upstream kernel changes > module dependencies. > The way modules are filtered is indeed difficult and requires a lot of human care and attention, but perhaps this is a good opportunity to rethink how it works a bit. I'm obviously not crazy about advocating for something that makes my job harder, but I'm willing to entertain doing some work so I can later not do any work in that area again. Furthermore, this particular issue is on my radar anyway due to my last run-in with it. All that to say that I *hope* we can improve how we divvy up modules enough that it won't be a blocker for this proposal (and kernel maintainers will live in a land filled with sunshine and rainbows). > Can you describe in more detail why you need something smaller than > kernel-core? I'm not understanding your usecase. > > > - remove the Requires on kernel-core (or change to Recommends) from > > kernel-modules, so it can be installed standalone > > That makes no sense. The modules are unusable without the main > vmlinux binary. Why would we do that and risk people making their > machines unbootable? > > > - move the Requires:linux-firmware (or change to Recommends) from > > kernel-core, > > have kernel Requires:linux-firmware > > > > I think this would be useful for playing with various minimization > > scenarios. > > This one might be feasible. We did the split before Recommends > support was present. It's often been requested for the VM case. I > do > still have concerns that it can lead to unbootable physical machines, > but if dnf defaults to installing Recommended packages that might be > possible. > > josh > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
