[OS-BUILD PATCHv3 0/0] scriptlets: clean up declared installation dependencies, stop calling kernel-install in chroot or container
From: Zbigniew Jędrzejewski-Szmek on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1617 NOTE: Truncated patchset due to missing public @redhat.com email address on your GitLab profile at https://gitlab.com/-/profile. Once that is fixed, close and reopen the merge request to retrigger sending the emails.
--- redhat/kernel.spec.template | 30 ++++++++++++++---------------- 1 files changed, 14 insertions(+), 16 deletions(-)
From: Zbigniew Jędrzejewski-Szmek on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1617#note_8460031...
I added a third commit now.
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1617#note_8465396...
@keszybz - thanks for the contribution. I feel like I am missing something obvious.
If I follow your assumption, that someone will install a kernel in a virt env or container that may not have systemd and/or access to /boot, then your changes make sense and I can see how it prevents the grub error messages you are seeing.
However, I am stuck on the assumption part. Is there any value in installing a kernel in those environments? The package puts everything under /lib/modules easily enough, you just loose the /boot and grub setup. Is that useful? It might be, but currently I am thinking all these changes do is prevent error messages when the developer does something not useful. And I could be ok with that, I think. I am probably missing something obvious. Thoughts?
From: Zbigniew Jędrzejewski-Szmek on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1617#note_8469175...
I don't have any immediate use case in mind. This is more a matter of general principle: dependencies should only be declared if the package genuinely needs the dependency to function. People tend to use packages in unusual and innovative ways and we shouldn't have dependencies for things which would *usually* be used. Less dependencies == more flexibility.
Some contrived cases: a qemu image where the kernel is used externally (`qemu -kernel -initrd …`), and then you only need the modules in the guest, so you don't want kernel-install. Such cases would *usually* involve systemd in the image, but maybe if you're building an single-executable appliance, you don't have systemd there.
So maybe you're building a container with a qemu and single application isolated in a VM, and you want the kernel for the qemu in the container, but no systemd and no boot loader.
Or maybe you're trying to convert Fedora to runit or back to sysvinit, so you want to drop dependencies on systemd as much as possible ;)
As I said, I don't have a good use case, but I think the general principle is reasonable.
From: Zbigniew Jędrzejewski-Szmek on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1617#note_8469183...
I forgot to add: if the third commit is too much, I'm fine with dropping it. This can always be revived later if some concrete use cases pops up.
From: Patrick Talbert on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1617#note_8664214...
@keszybz The `os-build` branch is rebased whenever there is an official release of the upstream kernel. This is expected to next happen this coming Monday, the 14th. So just be aware if this MR is not ready for merge by then that it will need to be rebased.
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1617#note_1267368...
Closing, no activity.
kernel@lists.fedoraproject.org
-
Don Zickus (via Email Bridge) -
Patrick Talbert (via Email Bridge)
-
Zbigniew Jędrzejewski-Szmek (via Email Bridge)