[1/2] defaultsetup.conf: enable select init manager

Submitted by Kang Kai on July 4, 2019, 1:45 p.m. | Patch ID: 162774

Details

Message ID 20190704134520.16320-2-kai.kang@windriver.com
State Master Next
Commit 35c871653349b5597d3d17495de86937e27ac3d3
Headers show

Commit Message

Kang Kai July 4, 2019, 1:45 p.m.
From: Kai Kang <kai.kang@windriver.com>

Introduce a new variable INIT_MANAGER and create 3 init-manager-*.inc
files to configure init manager settings. Available values of
INIT_MANAGER are sysvinit, systemd and mdev-busybox. 'sysvinit' is set
by default for compatibility.

[YOCTO #13031]

Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
 meta/conf/distro/defaultsetup.conf                     | 3 +++
 meta/conf/distro/include/init-manager-mdev-busybox.inc | 7 +++++++
 meta/conf/distro/include/init-manager-systemd.inc      | 6 ++++++
 meta/conf/distro/include/init-manager-sysvinit.inc     | 6 ++++++
 4 files changed, 22 insertions(+)
 create mode 100644 meta/conf/distro/include/init-manager-mdev-busybox.inc
 create mode 100644 meta/conf/distro/include/init-manager-systemd.inc
 create mode 100644 meta/conf/distro/include/init-manager-sysvinit.inc

Patch hide | download patch | download mbox

diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/defaultsetup.conf
index 20e61232e9..057e2f761f 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -23,3 +23,6 @@  PACKAGE_CLASSES ?= "package_ipk"
 INHERIT_BLACKLIST = "blacklist"
 INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
 INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST}"
+
+INIT_MANAGER ??= "sysvinit"
+require conf/distro/include/init-manager-${INIT_MANAGER}.inc
diff --git a/meta/conf/distro/include/init-manager-mdev-busybox.inc b/meta/conf/distro/include/init-manager-mdev-busybox.inc
new file mode 100644
index 0000000000..b07d9de5b4
--- /dev/null
+++ b/meta/conf/distro/include/init-manager-mdev-busybox.inc
@@ -0,0 +1,7 @@ 
+# enable mdev/busybox for init
+DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " systemd sysvinit"
+VIRTUAL-RUNTIME_dev_manager = "busybox-mdev"
+VIRTUAL-RUNTIME_init_manager = "busybox"
+VIRTUAL-RUNTIME_initscripts = "initscripts"
+VIRTUAL-RUNTIME_keymaps = "keymaps"
+VIRTUAL-RUNTIME_login_manager = "busybox"
diff --git a/meta/conf/distro/include/init-manager-systemd.inc b/meta/conf/distro/include/init-manager-systemd.inc
new file mode 100644
index 0000000000..6542e29cfd
--- /dev/null
+++ 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"

Comments

Adrian Bunk July 6, 2019, 9:53 a.m.
On Thu, Jul 04, 2019 at 09:45:19PM +0800, kai.kang@windriver.com wrote:
> From: Kai Kang <kai.kang@windriver.com>
> 
> Introduce a new variable INIT_MANAGER and create 3 init-manager-*.inc
> files to configure init manager settings. Available values of
> INIT_MANAGER are sysvinit, systemd and mdev-busybox. 'sysvinit' is set
> by default for compatibility.
>...
> --- a/meta/conf/distro/defaultsetup.conf
> +++ b/meta/conf/distro/defaultsetup.conf
> @@ -23,3 +23,6 @@ PACKAGE_CLASSES ?= "package_ipk"
>  INHERIT_BLACKLIST = "blacklist"
>  INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
>  INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST}"
> +
> +INIT_MANAGER ??= "sysvinit"
> +require conf/distro/include/init-manager-${INIT_MANAGER}.inc
>...
> --- /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"

I am not sure whether this can be fixed better, but this does break 
existing configurations that use a non-default init system.

I just ran into a build issue with
  VIRTUAL-RUNTIME_init_manager = "systemd"
since this now resulted in both sysvinit and systemd being attempted to 
be installed to the image.

This was fixable in my configuration with
  -VIRTUAL-RUNTIME_init_manager = "systemd"
  +INIT_MANAGER = "systemd"

This at least needs to be properly documented as a breaking change.

cu
Adrian
Adrian Bunk July 6, 2019, 12:08 p.m.
On Sat, Jul 06, 2019 at 12:53:28PM +0300, Adrian Bunk wrote:
> On Thu, Jul 04, 2019 at 09:45:19PM +0800, kai.kang@windriver.com wrote:
> > From: Kai Kang <kai.kang@windriver.com>
> > 
> > Introduce a new variable INIT_MANAGER and create 3 init-manager-*.inc
> > files to configure init manager settings. Available values of
> > INIT_MANAGER are sysvinit, systemd and mdev-busybox. 'sysvinit' is set
> > by default for compatibility.
> >...
> > --- a/meta/conf/distro/defaultsetup.conf
> > +++ b/meta/conf/distro/defaultsetup.conf
> > @@ -23,3 +23,6 @@ PACKAGE_CLASSES ?= "package_ipk"
> >  INHERIT_BLACKLIST = "blacklist"
> >  INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
> >  INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST}"
> > +
> > +INIT_MANAGER ??= "sysvinit"
> > +require conf/distro/include/init-manager-${INIT_MANAGER}.inc
> >...
> > --- /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"
> 
> I am not sure whether this can be fixed better, but this does break 
> existing configurations that use a non-default init system.
> 
> I just ran into a build issue with
>   VIRTUAL-RUNTIME_init_manager = "systemd"
> since this now resulted in both sysvinit and systemd being attempted to 
> be installed to the image.
> 
> This was fixable in my configuration with
>   -VIRTUAL-RUNTIME_init_manager = "systemd"
>   +INIT_MANAGER = "systemd"
> 
> This at least needs to be properly documented as a breaking change.

Looking at master-next, this problem is actually fixed for me with
  meta: Improve handling of VIRTUAL-RUNTIME variables

cu
Adrian
Richard Purdie July 6, 2019, 12:31 p.m.
On Sat, 2019-07-06 at 12:53 +0300, Adrian Bunk wrote:
> On Thu, Jul 04, 2019 at 09:45:19PM +0800, kai.kang@windriver.com
> wrote:
> > From: Kai Kang <kai.kang@windriver.com>
> > 
> > Introduce a new variable INIT_MANAGER and create 3 init-manager-
> > *.inc
> > files to configure init manager settings. Available values of
> > INIT_MANAGER are sysvinit, systemd and mdev-busybox. 'sysvinit' is
> > set
> > by default for compatibility.
> > ...
> > --- a/meta/conf/distro/defaultsetup.conf
> > +++ b/meta/conf/distro/defaultsetup.conf
> > @@ -23,3 +23,6 @@ PACKAGE_CLASSES ?= "package_ipk"
> >  INHERIT_BLACKLIST = "blacklist"
> >  INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
> >  INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
> > ${INHERIT_BLACKLIST}"
> > +
> > +INIT_MANAGER ??= "sysvinit"
> > +require conf/distro/include/init-manager-${INIT_MANAGER}.inc
> > ...
> > --- /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"
> 
> I am not sure whether this can be fixed better, but this does break 
> existing configurations that use a non-default init system.
> 
> I just ran into a build issue with
>   VIRTUAL-RUNTIME_init_manager = "systemd"
> since this now resulted in both sysvinit and systemd being attempted
> to 
> be installed to the image.
> 
> This was fixable in my configuration with
>   -VIRTUAL-RUNTIME_init_manager = "systemd"
>   +INIT_MANAGER = "systemd"
> 
> This at least needs to be properly documented as a breaking change.

This change also didn't quite work out for some of our selftests. I've
a patch in master-next which tried to improve things and that fixed the
selftests.

The only other way we could do this is to default INIT_MANAGER to say
"unset" and have an empty file for that. That will of course break my
patch and need the defaults adding back into the recipe. Unless we put
those defaults into the unset version.

Not sure quite what we should do here...

Cheers,

Richard
Kang Kai July 8, 2019, 2:01 a.m.
On 2019/7/6 下午5:53, Adrian Bunk wrote:
> On Thu, Jul 04, 2019 at 09:45:19PM +0800, kai.kang@windriver.com wrote:
>> From: Kai Kang <kai.kang@windriver.com>
>>
>> Introduce a new variable INIT_MANAGER and create 3 init-manager-*.inc
>> files to configure init manager settings. Available values of
>> INIT_MANAGER are sysvinit, systemd and mdev-busybox. 'sysvinit' is set
>> by default for compatibility.
>> ...
>> --- a/meta/conf/distro/defaultsetup.conf
>> +++ b/meta/conf/distro/defaultsetup.conf
>> @@ -23,3 +23,6 @@ PACKAGE_CLASSES ?= "package_ipk"
>>   INHERIT_BLACKLIST = "blacklist"
>>   INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
>>   INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST}"
>> +
>> +INIT_MANAGER ??= "sysvinit"
>> +require conf/distro/include/init-manager-${INIT_MANAGER}.inc
>> ...
>> --- /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"
> I am not sure whether this can be fixed better, but this does break
> existing configurations that use a non-default init system.
>
> I just ran into a build issue with
>    VIRTUAL-RUNTIME_init_manager = "systemd"
> since this now resulted in both sysvinit and systemd being attempted to
> be installed to the image.

It is a little weird. NO sysvinit in DISTRO_FEATURES. I'll check what's 
wrong with it w/o the VIRTUAL-RUNTIME patch.

Regards,
Kai


>
> This was fixable in my configuration with
>    -VIRTUAL-RUNTIME_init_manager = "systemd"
>    +INIT_MANAGER = "systemd"
>
> This at least needs to be properly documented as a breaking change.
>
> cu
> Adrian
>
Kang Kai July 8, 2019, 2:13 a.m.
On 2019/7/8 上午10:01, Kang Kai wrote:
> On 2019/7/6 下午5:53, Adrian Bunk wrote:
>> On Thu, Jul 04, 2019 at 09:45:19PM +0800, kai.kang@windriver.com wrote:
>>> From: Kai Kang <kai.kang@windriver.com>
>>>
>>> Introduce a new variable INIT_MANAGER and create 3 init-manager-*.inc
>>> files to configure init manager settings. Available values of
>>> INIT_MANAGER are sysvinit, systemd and mdev-busybox. 'sysvinit' is set
>>> by default for compatibility.
>>> ...
>>> --- a/meta/conf/distro/defaultsetup.conf
>>> +++ b/meta/conf/distro/defaultsetup.conf
>>> @@ -23,3 +23,6 @@ PACKAGE_CLASSES ?= "package_ipk"
>>>   INHERIT_BLACKLIST = "blacklist"
>>>   INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
>>>   INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} 
>>> ${INHERIT_BLACKLIST}"
>>> +
>>> +INIT_MANAGER ??= "sysvinit"
>>> +require conf/distro/include/init-manager-${INIT_MANAGER}.inc
>>> ...
>>> --- /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"
>> I am not sure whether this can be fixed better, but this does break
>> existing configurations that use a non-default init system.
>>
>> I just ran into a build issue with
>>    VIRTUAL-RUNTIME_init_manager = "systemd"
>> since this now resulted in both sysvinit and systemd being attempted to
>> be installed to the image.
>
> It is a little weird. NO sysvinit in DISTRO_FEATURES. I'll check 
> what's wrong with it w/o the VIRTUAL-RUNTIME patch.


I misunderstood your config. It is a problem when user wants to set 
init_manager directly.  Thanks for your trying.

Regards,
Kai


>
> Regards,
> Kai
>
>
>>
>> This was fixable in my configuration with
>>    -VIRTUAL-RUNTIME_init_manager = "systemd"
>>    +INIT_MANAGER = "systemd"
>>
>> This at least needs to be properly documented as a breaking change.
>>
>> cu
>> Adrian
>>
>
Kang Kai July 8, 2019, 9:28 a.m.
On 2019/7/6 下午8:31, richard.purdie@linuxfoundation.org wrote:
> On Sat, 2019-07-06 at 12:53 +0300, Adrian Bunk wrote:
>> On Thu, Jul 04, 2019 at 09:45:19PM +0800, kai.kang@windriver.com
>> wrote:
>>> From: Kai Kang <kai.kang@windriver.com>
>>>
>>> Introduce a new variable INIT_MANAGER and create 3 init-manager-
>>> *.inc
>>> files to configure init manager settings. Available values of
>>> INIT_MANAGER are sysvinit, systemd and mdev-busybox. 'sysvinit' is
>>> set
>>> by default for compatibility.
>>> ...
>>> --- a/meta/conf/distro/defaultsetup.conf
>>> +++ b/meta/conf/distro/defaultsetup.conf
>>> @@ -23,3 +23,6 @@ PACKAGE_CLASSES ?= "package_ipk"
>>>   INHERIT_BLACKLIST = "blacklist"
>>>   INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
>>>   INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
>>> ${INHERIT_BLACKLIST}"
>>> +
>>> +INIT_MANAGER ??= "sysvinit"
>>> +require conf/distro/include/init-manager-${INIT_MANAGER}.inc
>>> ...
>>> --- /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"
>> I am not sure whether this can be fixed better, but this does break
>> existing configurations that use a non-default init system.
>>
>> I just ran into a build issue with
>>    VIRTUAL-RUNTIME_init_manager = "systemd"
>> since this now resulted in both sysvinit and systemd being attempted
>> to
>> be installed to the image.
>>
>> This was fixable in my configuration with
>>    -VIRTUAL-RUNTIME_init_manager = "systemd"
>>    +INIT_MANAGER = "systemd"
>>
>> This at least needs to be properly documented as a breaking change.
> This change also didn't quite work out for some of our selftests. I've
> a patch in master-next which tried to improve things and that fixed the
> selftests.
>
> The only other way we could do this is to default INIT_MANAGER to say
> "unset" and have an empty file for that. That will of course break my
> patch and need the defaults adding back into the recipe. Unless we put
> those defaults into the unset version.

How about keep a empty INIT_MANAGER by default, and check if 
INIT_MANAGER is set, then overwrite other configs such as
VIRTUAL-RUNTIME_init_manager whether is from user config or predefined 
value from config files or recipes? It could be done
in a anonymous function.

Regards,
Kai


>
> Not sure quite what we should do here...
>
> Cheers,
>
> Richard
>
>
>
Qi.Chen@windriver.com July 8, 2019, 10:01 a.m.
On 07/06/2019 08:31 PM, richard.purdie@linuxfoundation.org wrote:
> On Sat, 2019-07-06 at 12:53 +0300, Adrian Bunk wrote:
>> On Thu, Jul 04, 2019 at 09:45:19PM +0800, kai.kang@windriver.com
>> wrote:
>>> From: Kai Kang <kai.kang@windriver.com>
>>>
>>> Introduce a new variable INIT_MANAGER and create 3 init-manager-
>>> *.inc
>>> files to configure init manager settings. Available values of
>>> INIT_MANAGER are sysvinit, systemd and mdev-busybox. 'sysvinit' is
>>> set
>>> by default for compatibility.
>>> ...
>>> --- a/meta/conf/distro/defaultsetup.conf
>>> +++ b/meta/conf/distro/defaultsetup.conf
>>> @@ -23,3 +23,6 @@ PACKAGE_CLASSES ?= "package_ipk"
>>>   INHERIT_BLACKLIST = "blacklist"
>>>   INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
>>>   INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
>>> ${INHERIT_BLACKLIST}"
>>> +
>>> +INIT_MANAGER ??= "sysvinit"
>>> +require conf/distro/include/init-manager-${INIT_MANAGER}.inc
>>> ...
>>> --- /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"
>> I am not sure whether this can be fixed better, but this does break
>> existing configurations that use a non-default init system.
>>
>> I just ran into a build issue with
>>    VIRTUAL-RUNTIME_init_manager = "systemd"
>> since this now resulted in both sysvinit and systemd being attempted
>> to
>> be installed to the image.
>>
>> This was fixable in my configuration with
>>    -VIRTUAL-RUNTIME_init_manager = "systemd"
>>    +INIT_MANAGER = "systemd"
>>
>> This at least needs to be properly documented as a breaking change.
> This change also didn't quite work out for some of our selftests. I've
> a patch in master-next which tried to improve things and that fixed the
> selftests.
>
> The only other way we could do this is to default INIT_MANAGER to say
> "unset" and have an empty file for that. That will of course break my
> patch and need the defaults adding back into the recipe. Unless we put
> those defaults into the unset version.
>
> Not sure quite what we should do here...
>
> Cheers,
>
> Richard
>
>
I'm also concerned about the '=' assignment. Before this patch, the 
VIRTUAL-RUNTIME_xxx are using '?='. Not sure if this would cause 
potential problem for users.
Also, if we are setting default values of VIRTUAL-RUNTIME_xxx in conf 
files, should we clean them up from recipes like packagegroup-core-boot?

Best Regards,
Chen Qi
Ross Burton July 19, 2019, 9:35 p.m.
On Thu, 4 Jul 2019 at 15:40, <kai.kang@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?

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.

Ross
Richard Purdie July 19, 2019, 10:28 p.m.
On Fri, 2019-07-19 at 22:35 +0100, Burton, Ross wrote:
> On Thu, 4 Jul 2019 at 15:40, <kai.kang@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?

We're still missing one or two init system setup variants, 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.

> 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
Kang Kai July 22, 2019, 1:37 a.m.
On 2019/7/20 上午6:28, richard.purdie@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@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
>
>
Anuj Mittal July 22, 2019, 11:26 p.m.
On Mon, 2019-07-22 at 09:37 +0800, Kang Kai wrote:
> 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.

Not sure if these have been reported but there are some failures in
runtime tests which look related to this change:

https://autobuilder.yoctoproject.org/typhoon/#/builders/38/builds/855/steps/8/logs/step1c

https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/852/steps/8/logs/step1c

https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/856/steps/8/logs/step2c

Thanks,

Anuj