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

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 27, 2022 at 11:40:36AM -0400, Neal Gompa wrote:
> 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.

Once more (this has already been written *independently* by Lennart
and me, but let's say it once again): THE USERSPACE AND EFI-SPACE
PARTS SHARE CODE, the configuration system and the build system. So if
we split them, we'd probably want to update them in tandem anyway, and
it's just easier to do it, then to try to figure out if the sd-boot parts
didn't change and we can skip the update.

Since the signing is automatic once configured, I can't grok what
savings people foresee by doing separate builds.

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

There are downsides, but there are also benefits:
1. code sharing (it's not a lot, but even some is better than nothing,
   and the amount is growing).

2. when implementing features that have a "producer side" and a
   "consumer side", e.g. as with the random-seed integration in the bootloader
   and pid1 and bootctl, it's *much* easier if all parts of the code can
   be implemented and viewed and tested together. Splitting things into
   separate projects adds overhead. This overhead is not too great, so
   it's always a question of balance, but so far the integration of sd-boot
   with systemds has generally made the the development of both sides easier.
   Also, with any boot menu stuff, we want to have functional equivalency for
   sd-boot and bootctl, and that also is much easier if it's just one repo,
   even if the implementations are separate.

3. one project is less work than two projects.

Zbyszek