[Buildroot] [PATCH v2 1/1] boot/systemd-boot: new package

[James Hilliard]

On Sat, Dec 15, 2018 at 4:00 AM Yann E. MORIN <yann.morin.1998 at free.fr> wrote:
>
> James, All,
>
> On 2018-12-15 03:43 -0700, James Hilliard spake thusly:
> > On Sat, Dec 15, 2018 at 3:27 AM Yann E. MORIN <yann.morin.1998 at free.fr> wrote:
> > > On 2018-12-15 02:12 -0700, James Hilliard spake thusly:
> [--SNIP--]
> > > > I did it this way so that it's clear that systemd-boot can be built
> > > > without a systemd init system.
> > >
> > > There, _that_ is the reason for all this complexity.
> > >
> > > So, let me suggest two alternative options that avoid all this mess:
> > >
> > >  1- make systemd-boot available only for systemd-based init,
> > >
> > >  2- just do a systemd-boot package (in boot/) that is a whole package on
> > >     its own, and just happens to build just the systemd-boot part of
> > >     systemd.
> > >
> > > I would very much favour the first option, because it is very simple, as
> > > it just requires a *few* tweaks in the existing sytemd.mk, i.e.
> > > basically:
> > >
> > >     ifeq ($()BR2_PACKAGES_SYSTEMD_BOOT,y)
> > >     SYSTEMD_CONF_OPTS += \
> > >         -Defi=true \
> > >         -Dgnu-efi=true \
> > >         -Dcc-efi=blabla \
> > >         [...]
> > >     else
> > >     SYSTEMD_CONF_OPTS += -Defi=false -Dgnu-efi=false
> > >     endif
> > it would also need the SYSTEMD_INSTALL_IMAGES_CMDS part.
>
> Yes, obviously my code snippet was there just as a seed for a proper,
> complete change...
>
> > > Also, I wonder if it ever makes sense to provide systemd-boot to
> > > non-systemd init systems to begin with.
> > I think it does,
>
> Yes, Peter provided a good use-case, indeed.
>
> > systemd-boot is even designed to boot operating
> > systems without systemd, including windows.
>
> Aha, you almost got me there, I almost thought you were serious (in the
> Buildroot context, I mean). ;-)
Heh, was just making a point that it wasn't dependent on a systemd userspace.
>
> > > Baring that, option 2 is pretty simple as well. It's a separate package
> > > that just happens to share its source code with another one, like we
> > > have with mesa3d and mesa3d-headers (just as an example).
> > I tried that approach first in my v1 patch, I abandoned it since
>
> Yet, I think we should really go that route.
>
> > systemd-boot needed to be built at the same time as the userspace
> > tools for systems that have a systemd init system for the integration
> > to work properly.
>
> OK, so we need to think it a bit, then. Is it the boot part that needs
> the userland part, of the userland that needs the boot part, of they
> both need to know each other?
Mostly userland that needs to know the boot part, the boot part itself
doesn't really care what OS it is booting.
>
> One option I can think of quickly, is that we could have a systemd-boot
> package that is only available when systemd is not enabled, and an option
> in systemd to install the boot part when systemd is enabled.
I was trying to avoid having fully separate packages since that would
create a lot of maintenance overhead keeping both up to date as well.
Is there something wrong with having a fake boot package that
configures the appropriate options in the primary systemd package?
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'