Re: [Buildroot] [PATCH 0/3] portable services: another use case of BR

[Arnout Vandecappelle <arnout@mind.be>]

On 22/08/2022 23:24, Yann E. MORIN wrote:
> François, all,
> 
> On 2022-08-21 23:17 +0200, Yann E. MORIN spake thusly:
>> On 2022-02-21 05:30 +0100, Francois Perrad spake thusly:
>>> This series allows to build a rootfs suitable for portable services with systemd.
>>>
>>> A new value of "Init system" is introduced : BR2_INIT_PORTABLE.
>>> BR2_INIT_PORTABLE is like BR2_INIT_NONE, but with all FOO_INSTALL_INIT_SYSTEMD executed.
>>>
>>> A new type of skeleton is required : BR2_PACKAGE_SKELETON_INIT_PORTABLE.
>>>
>>> see https://systemd.io/PORTABLE_SERVICES/
>>
>> I don't see anything that can't be already managed with existing
>> configuration options.
> 
> Ah, I missed one thing: this allows installing systemd units bundled in
> Buildroot, without using systemd as a init system.

  In a portable service, /sbin/init is not used anyway, so the init system is 
irrelevant.

  The only real difference is that systemd and its dependencies are not 
installed to the target, which reduces size a little.

> This is flawed, IMO, because a lot of packages now install their own
> units as part of their install procedure, so without systemd enabled,
> those packages wold not install their units.
> 
> So, in practice, to be really usefull, this would still need systemd to
> be enabled, and we're back to the situation where this series only
> brings a few defaults as policy.

  Yeah, to be fully useful, we should probably replace all conditions on 
BR2_INIT_SYSTEMD (and many on BR2_PACKAGE_SYSTEMD) with something else... In 
addition, packages that actually require libsystemd (e.g. clamav) would need to 
select BR2_PACKAGE_SYSTEMD - and if you use any of those, the advantage is lost 
again.

  So, although the use case exists, I don't think the difference is important 
enough to bother, and this series addresses only a small part of the problem 
space. So I agree with Yann.

  Regards,
  Arnout


> 
> So, I'm still not convinced about it.
> 
> Regards,
> Yann E. MORIN.
> 
>> All that this new so-called init system does, is change some defaults to
>> match a specific use-case. We had similar stuff back in the day (e.g. an
>> option to define a router, one to define something else, and so on), and
>> we removed all of them.
>>
>> Granted, portable services are slightly different, but still all that
>> this series eventually does is change some defaults; it does not even
>> enforce the settings so they are not even required.
>>
>> Even the new skeleton case can already be handled by providing a custom
>> skeleton, and it is a trivial one, so even that is not needed.
>>
>> If you want to build a portable service, just build a system with
>> systemd and the rest of the settings set as required for that use-case.
>>
>> So, my position is to reject this new pseudo-init system.
>>
>> Regards,
>> Yann E. MORIN.
>>
>>> Francois Perrad (3):
>>>    package/skeleton-init-portable: new skeleton
>>>    portable: new init system
>>>    portable: tweak some default values
>>>
>>>   DEVELOPERS                                    |  1 +
>>>   fs/squashfs/Config.in                         |  1 +
>>>   package/Config.in                             |  1 +
>>>   package/ifupdown-scripts/Config.in            |  2 +-
>>>   package/pkg-generic.mk                        |  2 ++
>>>   package/skeleton-init-portable/Config.in      |  7 ++++++
>>>   .../skeleton-init-portable.mk                 | 23 +++++++++++++++++++
>>>   system/Config.in                              | 18 +++++++++++----
>>>   8 files changed, 50 insertions(+), 5 deletions(-)
>>>   create mode 100644 package/skeleton-init-portable/Config.in
>>>   create mode 100644 package/skeleton-init-portable/skeleton-init-portable.mk
>>>
>>> -- 
>>> 2.32.0
>>>
>>> _______________________________________________
>>> buildroot mailing list
>>> buildroot@buildroot.org
>>> https://lists.buildroot.org/mailman/listinfo/buildroot
>>
>> -- 
>> .-----------------.--------------------.------------------.--------------------.
>> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
>> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
>> | +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
>> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
>> '------------------------------^-------^------------------^--------------------'
>> _______________________________________________
>> buildroot mailing list
>> buildroot@buildroot.org
>> https://lists.buildroot.org/mailman/listinfo/buildroot
> 
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot