On Thu, Feb 6, 2020 at 2:40 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Thu, Feb 06, 2020 at 02:13:25PM -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. > > > Can you describe in more detail why you need something smaller than > > kernel-core? I'm not understanding your usecase. > > The initramfs built from rpms was described above. I don't understand the description of the initramfs build from rpms as described above. Can you be more verbose with the usecase of that, how it would work, what hardware it would target, etc? > A different example: a VM is booted with 'qemu -kernel foo'. Then > we vmlinuz binary is not necessary in the guest, just the modules. > > > > - 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? > > See above, there are cases where the modules are usable without vmlinuz > being _installed_. People who just want to have the safe thing, should > install kernel.rpm and have it pull in all the dependencies. The split > into subpackages is for power users. Hm. I see. So you're really asking for the vmlinuz to be packaged all by itself. josh > (Proposed changes don't fundamentally change anything: it was already > possible to uninstall kernel-modules and kernel-firmware, just keeping > kernel-core, and make the machine 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. > Cool, that'd be a good start, since the firmware package is so large. > Yes, dnf does install Recommends by default. > > Zbyszek > _______________________________________________ > 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
