[OE-core] [oe-core][PATCH 1/2] defaultsetup.conf: enable select init manager

[Kang Kai]

On 2019/7/20 上午6:28, richard.purdie at linuxfoundation.org wrote:
> On Fri, 2019-07-19 at 22:35 +0100, Burton, Ross wrote:
>> On Thu, 4 Jul 2019 at 15:40, <kai.kang at windriver.com> wrote:
>>> +++ b/meta/conf/distro/include/init-manager-systemd.inc
>>> @@ -0,0 +1,6 @@
>>> +# Use systemd for system initialization
>>> +DISTRO_FEATURES_append = " systemd"
>>> +DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " sysvinit"
>>> +VIRTUAL-RUNTIME_init_manager = "systemd"
>>> +VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
>>> +VIRTUAL-RUNTIME_login_manager = "shadow-base"
>>> diff --git a/meta/conf/distro/include/init-manager-sysvinit.inc
>>> b/meta/conf/distro/include/init-manager-sysvinit.inc
>>> new file mode 100644
>>> index 0000000000..7725b30e1e
>>> --- /dev/null
>>> +++ b/meta/conf/distro/include/init-manager-sysvinit.inc
>>> @@ -0,0 +1,6 @@
>>> +# Use sysvinit for system initialization
>>> +DISTRO_FEATURES_append = " sysvinit"
>>> +DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " systemd"
>>> +VIRTUAL-RUNTIME_init_manager = "sysvinit"
>>> +VIRTUAL-RUNTIME_initscripts = "initscripts"
>>> +VIRTUAL-RUNTIME_login_manager = "busybox"
>> Back when I integrated systemd into oe-core one of the use cases was
>> a single distro that builds a main image using systemd, and a
>> rescue/update image using sysv/busybox.  How is this possible with
>> this system?


Hi Richard,

> We're still missing one or two init system setup variants,

What kind of missing variants do you mean?


> I was
> planning to add those and convert our autobuilder tests over to use
> them rather than the fragements that are currently coded into
> autobuilder-helper.


I just run oe-selftest -a with this patch after you updated the patch in 
oe-core. But I met some (>15) errors

ERROR: Unable to start bitbake server (None)

But I think it should not be related with init manager changes and will 
change a build machine to test.
Do you have test it again in autobuilder and any failure found? Thanks.

Regards,
Kai


>
>> Personally, I'd prefer to see the DISTRO_FEATURE wrangling left out
>> of those files, and let the user ensure the right features are set.
>> After all, systemd will refuse to build unless the systemd feature is
>> enabled.
> With the addition of the "none" default, users aren't being forced to
> use them so that can do something custom or use a precanned default
> which I think gives the best of both worlds?
>
> Cheers,
>
> Richard
>
>

-- 
Kai Kang