[Buildroot] [PATCH] package/openrc: new init package OpenRC (0.38.3)

[Arnout Vandecappelle]

On 06/03/2019 18:36, Yann E. MORIN wrote:
> Arnout, Michał, All,
> 
> On 2019-03-06 10:58 +0100, Arnout Vandecappelle spake thusly:
[snip]
>>  Instead of doing a custom install, I prefer to just do the default install and
>> remove things are not needed / wanted.
> 
> I usually prefer to whitelist rather than blacklist. I.e .I prefer a
> selective install, rather than a selective removal.
> 
> Otherwise, when we bump the version, and a new tool is installed, we can
> very easily miss it and leave it installed. While when we selectively
> install, we can't leave cruft on the target, but we will notice easily
> that something is missing.

 That knife cuts both ways: when you do custom install, you can easily miss
something new that is required. It's almost never a problem if too much gets
installed, while a missing shared library tends to be troublesome.

 Remember that we have seen this issue several times with the qt5 packages.


> Of course, the alternative is to go full-blown, which I also find
> acceptable. We can then trim down in followup patches.

 It's not a matter of trimming down, really, because it's just a few KB. It's a
matter of avoiding warnings on the console.


>>> - Invoke "install" for each file? There are quite of them.
> 
> OTOH, there are probalby quite a bunch of files to remove too, no?

 I don't know, of course, but I would expect it to be just one or two.

[snip]
>>  Maybe we should introduce a global config + variable to control this, i.e. the
>> NAME and PRETTY_NAME in /etc/os-release.
> 
> I amundecided on that one... Would you also offer a way to change the
> version, to match that of the product? IMHO, people that are concerned
> with having their names in there can just generate os-release from a
> post-build script, so that they can get the version out of their VCS for
> example.

 You can still do that with a BR2_BRANDING config variable, e.g. by setting it
to "ExampleCo $(shell get-version)"


>>>> I think this should be a sub-option of the openrc package, not the 'init'
>>>> part.
>>  I actually disagree that the various init packages depend on PID1 coming from
>> that particular package. There could be use cases to have a different init
>> system (usually _NONE) and still have the init executable there.
> 
> But then, what package is responsible for install /sbin/init ?

 Same as always: if several packages install the same file, we have to resolve
the conflict. Nowadays we do that by adding a dependency and either avoiding
installation if it's already there (busybox) or overwriting it (most other cases).

 /sbin/init is currently the big exception to that.


> If you allow to enable busybox' init, sysvinit, and systemd (and later,
> OpenRC) simultaneously, they will all compete to provide /sbin/init,
> with the latest winning over the others...
> 
> (Actually 'None' should really read as 'Custom', because there better be
> an kind of init system, or 'first'application' to start.)

 Not at all. I've used Buildroot to create chroot environment, to create a
toolchain, ...

 Actually, I would like to have an option like BR2_SYSTEM_NONE that just
disables everything (no init, no shell, no passwd, no skeleton except for the
minimal bin,lib,sbin dir/symlink, no busybox, ...). I just never got around to
implement that.


 Regards,
 Arnout