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

[Neal Gompa]

On Wed, Apr 27, 2022 at 1:07 PM Neal Gompa <ngompa13 at gmail.com> wrote:
>
> On Wed, Apr 27, 2022 at 12:19 PM Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
> >
> > 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.
> >
>
> Yes, well he was asking me why I bothered to ask, and I answered. That
> doesn't have a bearing on what reality turned out to be.
>
> > Since the signing is automatic once configured, I can't grok what
> > savings people foresee by doing separate builds.
> >
>
> That's the point: correct signing is *not* automatic. It's *manual*
> and done by *you* doing the build. Automatic signing is independent of
> who does it, this is not that.
>

Another option that preserves the single source tree thing and
probably will make Lennart happy is splitting this process in two:
1. systemd keeps building systemd-boot, but it gets split out as a
subpackage (systemd-boot-unsigned-%efi_arch as noarch)
2. A new systemd-boot-signed source package BRs all
systemd-boot-unsigned-$EFIARCH packages and signs them. It then
produces "systemd-boot-$EFIARCH" subpackages that are signed that
people can use.

That second package gets specifically marked to not get autobuilt,
doesn't have a disttag, and basically goes through the entire
exception path that shim uses today.

I think this matches what Michael Biebl was talking about for Debian
that died on the vine.


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