[OS-BUILD PATCHv3 0/0] scriptlets: clean up declared installation dependencies, stop calling kernel-install in chroot or container

[Zbigniew Jędrzejewski-Szmek (via Email Bridge)]

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(-)

[Zbigniew Jędrzejewski-Szmek (via Email Bridge)]

From: Zbigniew Jędrzejewski-Szmek on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1617#note_8460...

I added a third commit now.

[Don Zickus (via Email Bridge)]

From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1617#note_8465...

@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?

[Zbigniew Jędrzejewski-Szmek (via Email Bridge)]

From: Zbigniew Jędrzejewski-Szmek on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1617#note_8469...

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.

[Zbigniew Jędrzejewski-Szmek (via Email Bridge)]

From: Zbigniew Jędrzejewski-Szmek on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1617#note_8469...

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.

[Patrick Talbert (via Email Bridge)]

From: Patrick Talbert on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1617#note_8664...

@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.

[Don Zickus (via Email Bridge)]

From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1617#note_1267...

Closing, no activity.