[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:48:04AM -0400, Neal Gompa wrote:
> On Wed, Apr 27, 2022 at 11:46 AM Luca Boccassi <bluca at debian.org> wrote:
> >
> > On Wed, 2022-04-27 at 11:26 -0400, Neal Gompa wrote:
> > > On Wed, Apr 27, 2022 at 11:13 AM Zbigniew Jędrzejewski-Szmek
> > > <zbyszek at in.waw.pl> wrote:
> > > >
> > > > On Wed, Apr 27, 2022 at 09:31:10AM -0400, Neal Gompa wrote:
> > > > > On Wed, Apr 27, 2022 at 7:41 AM Lennart Poettering
> > > > > > > Realistically, I think if we want to make movement on making
> > > > > > > systemd-boot fully supported in Fedora, the systemd-boot boot manager
> > > > > > > code itself should be split out into its own repository with its own
> > > > > > > release cadence, while bootctl(1) and related infrastructure remains
> > > > > > > in the systemd source tree and evolves to be able to manage arbitrary
> > > > > > > BLS-conformant boot managers.
> > > > > >
> > > > > > Why though? I don't follow? as long as we provide you with a tarball
> > > > > > you can build your stuff from it shouldn't really matter if there's
> > > > > > more stuff in it you are not immediately interested in.
> > > > > >
> > > > > > I mean, if you like I could do a "cp systemd-251.tar.gz
> > > > > > systemd-boot-251.tar.gz" for you if you want two tarballs instead of
> > > > > > one, but I don't see the point?
> > > > > >
> > > > >
> > > > > As I illustrated in another email[5], decoupling the lifecycle of the
> > > > > EFI boot manager code from the rest of systemd would be ideal to not
> > > > > make the constraints around building sd-boot with secure boot support
> > > > > painful.
> > > > >
> > > > > [5]: https://lists.freedesktop.org/archives/systemd-devel/2022-April/047801.html
> > > >
> > > > Apart from the constraint who can build official packages, is there
> > > > anything else? If it's just that, that doesn't seem onerous.
> > >
> > > It also 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.
> > >
> > > Koji doesn't conceptually know the difference because there is no
> > > namespacing for builders, only who is approved to build.
> > >
> > > (In contrast, in the Open Build Service like what Luca Boccassi was
> > > talking about, packagers don't control the builds at all, so OBS only
> > > has to trust itself to sign it, so everything works properly.)
> >
> > You could simply have a separate source RPM, no? That should be pretty
> > simple, and limit the impact on team maintenance of the main source
> > package?

>From what I can see, it'd be strictly more work for the maintainers (*).
I keep asking, but I'm not getting any answers! There's some supposed
benefits, but apart from vague handwaving, I don't see anything.

(*) Two packages two build instead of one. It's not a huge difference, but
from experience, it's confusing to contributors and annoying for maintainers
to remember to duplicate the work.

> Yep. I was hoping we could have the upstream sources split too, but if
> we can't, then that's definitely the preferred way to go.

Again, [citation needed] for why this would be of benefit.

Zbsyzek