[systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Neal Gompa]

On Wed, Apr 27, 2022 at 11:26 AM Dan Nicholson <dbn at endlessos.org> wrote:
>
> On Wed, Apr 27, 2022 at 9:10 AM Neal Gompa <ngompa13 at gmail.com> wrote:
> >
> > Note that it means Fedora CI, pull requests from contributors, and
> > releng auto-rebuilds will no longer work. Maintainers basically
> > sign-on to do all of those things manually and have to be responsive
> > for doing it. You will get FTBFS tickets every cycle because of it,
> > for example.
>
> Asking systemd folks to change their development process because of
> limitations in Fedora/Koji seems like a big ask, don't you think?

Honestly, that never factors in for me, because then I'd never ask
anything of anyone. :)

But no, it doesn't sound unreasonable to me, because I reasonably
expect the parts that make up the EFI boot manager code to be somewhat
separate from the rest of the codebase in the first place. It targets
a different build environment and has to be built differently from the
rest of systemd anyway. So to me, it's not a "big ask" as you put it.

But I'm also not demanding anything. I'm *asking*. If you don't want
to do it, then that's fine. I only very occasionally help out with
systemd in Fedora, and mostly deal with systemd in other distributions
(CentOS Stream, etc.). I used to help with dracut and systemd
maintenance in Mageia, so I'm familiar with the source structures. And
I've contributed to systemd before, as well.

I don't help more with systemd in Fedora because the packaging is
pretty difficult for me to understand. If I did, I'd probably help out
more.

> Having implemented UEFI secure boot signing for Endless, I can concur
> it is a PITA. However, there are certainly ways to make it work that
> have no effect on upstream. Our Endless system is pretty hacky, but
> Debian's is pretty well thought out. What both have in common is that
> the signer generates a separate package so that the normal build flow
> isn't affected. In the case of systemd, there would be both an
> unsigned and signed version of the sd-boot EFI program in separate
> packages.
>
> I'm sure it would require work to fix, but this seems like more of a
> Koji problem than a systemd problem. I also feel like Lennart's
> suggestion that sd-boot get split out as a separate source package but
> using the same tarball is completely reasonable if your signing system
> is too onerous to use.
>

It's definitely problems with both. I agree that a chunk of this is
Koji's problem. I spent two years doing research on this topic because
I was working on kernel, kmod, and bootloader builds and discovered
how terrible it is and how nobody wants to improve it. My saltiness
about the whole affair is pretty evident in the Fedora discussion
about discontinuing BIOS support (and was even in an LWN article,
apparently!).

The Open Build Service is the only build system I know of that avoids
this problem by totally removing the packager's ability to control
builds *entirely*. They don't get to choose how the Release field
works, they don't get to choose when builds are made, and they don't
get to choose when builds are released. That's all entirely under the
control of the build system, which does its own decision-making by
constantly tracking the repoclosure state of the repository. Since no
humans are involved, everyone is equally happy and unhappy. :)

But I also strongly believe that it was a mistake to merge gummiboot
into the systemd source tree because it creates all kinds of problems
for distro maintenance, as I've already said earlier. It also
discourages making the sd-boot code tighter and simpler since your
primary focus is reuse across the tree rather than strictly separating
the functional domains.





--
真実はいつも一つ！/ Always, there's only one truth!