On 2019/7/20 上午6:28, richard.pur...@linuxfoundation.org wrote:
On Fri, 2019-07-19 at 22:35 +0100, Burton, Ross wrote:
On Thu, 4 Jul 2019 at 15:40, <kai.k...@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

--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to