Re: [OE-core] [PATCH v2 2/2] systemd: split modules into packages
* Bottazzini, Bruno bruno.bottazz...@intel.com [150302 21:22]: The problem is understanding that although systemd is a single repository it contains multiple services and daemons in it that can run even without the core PID1, udev or the many helpers used to configure the system such as resolved, timedated, localed... All of these components are runtime independent, we can install or remove them and they should not create problems. Even Ubuntu is shipping with some of these daemons even if systemd is not used (yet). If they were different GIT repos then it would be clear that they are separate daemons, but as they are all in a single repository people can make a confusion about it. I see that in the master branch it has already the version 219. I look forward to your updated patch. This is something I've been thinking about doing for a while, and it feels more and more necessary, as the systemd repo grows with more tools. Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 2/2] systemd: split modules into packages
Hello Randy, On Sex, 2015-02-06 at 10:45 -0800, Randy Witt wrote: On 02/04/2015 09:04 AM, Bruno Bottazzini wrote: It wil be able to choose what systemd module to be installed. The final result may get smaller, if the user wanted to. By default it will install the whole systemd which may be big. --- meta/recipes-core/systemd/systemd_218.bb | 1059 ++ 1 file changed, 914 insertions(+), 145 deletions(-) This patch will push a lot of maintenance work onto the Yocto systemd maintainer every time there is an upgrade. It's also easy to miss dependencies because of the inter-dependencies that can exist between services. This is not a problem, we can give this maintenance. For items such as systemd-cgls and the tools, a change like this would be maintainable since those items are self-contained. But yanking out the services into separate packages means the maintainer will have to inspect them on each upgrade to make sure they still work. Would it be sufficient to use PACKAGECONFIG for each of the items that can be disabled via configure? That way the granularity configuration is done by the systemd maintainers rather than the Yocto maintainer. With PACKAGECONFIG, we may not get everything for free as some data files will be installed regardless as well as some components from systemd cannot be disabled by their build system but we can run without them, for instance we can run without journald. The problem is understanding that although systemd is a single repository it contains multiple services and daemons in it that can run even without the core PID1, udev or the many helpers used to configure the system such as resolved, timedated, localed... All of these components are runtime independent, we can install or remove them and they should not create problems. Even Ubuntu is shipping with some of these daemons even if systemd is not used (yet). If they were different GIT repos then it would be clear that they are separate daemons, but as they are all in a single repository people can make a confusion about it. I see that in the master branch it has already the version 219. I will make a split packages for the newest version that was just released. Best Regards, Bruno Bottazzini -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 2/2] systemd: split modules into packages
On 02/04/2015 09:04 AM, Bruno Bottazzini wrote: It wil be able to choose what systemd module to be installed. The final result may get smaller, if the user wanted to. By default it will install the whole systemd which may be big. --- meta/recipes-core/systemd/systemd_218.bb | 1059 ++ 1 file changed, 914 insertions(+), 145 deletions(-) This patch will push a lot of maintenance work onto the Yocto systemd maintainer every time there is an upgrade. It's also easy to miss dependencies because of the inter-dependencies that can exist between services. For items such as systemd-cgls and the tools, a change like this would be maintainable since those items are self-contained. But yanking out the services into separate packages means the maintainer will have to inspect them on each upgrade to make sure they still work. Would it be sufficient to use PACKAGECONFIG for each of the items that can be disabled via configure? That way the granularity configuration is done by the systemd maintainers rather than the Yocto maintainer. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 2/2] systemd: split modules into packages
It wil be able to choose what systemd module to be installed.
The final result may get smaller, if the user wanted to.
By default it will install the whole systemd which may be big.
---
meta/recipes-core/systemd/systemd_218.bb | 1059 ++
1 file changed, 914 insertions(+), 145 deletions(-)
diff --git a/meta/recipes-core/systemd/systemd_218.bb
b/meta/recipes-core/systemd/systemd_218.bb
index 87d9fe8..ef8de44 100644
--- a/meta/recipes-core/systemd/systemd_218.bb
+++ b/meta/recipes-core/systemd/systemd_218.bb
@@ -6,8 +6,6 @@ LIC_FILES_CHKSUM =
file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \
file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c \
file://LICENSE.MIT;md5=544799d0b492f119fa04641d1b8868ed
-PROVIDES = udev
-
PE = 1
DEPENDS = kmod docbook-sgml-dtd-4.1-native intltool-native gperf-native acl
readline dbus libcap libcgroup glib-2.0 qemu-native util-linux
@@ -16,7 +14,7 @@ DEPENDS += ${@bb.utils.contains('DISTRO_FEATURES', 'pam',
'libpam', '', d)}
SECTION = base/shell
-inherit gtk-doc useradd pkgconfig autotools perlnative update-rc.d
update-alternatives qemu systemd ptest gettext
+inherit gtk-doc pkgconfig autotools perlnative update-rc.d update-alternatives
qemu systemd ptest gettext
SRCREV = 820aced6f6067a6b7c57b7d36e44f64378870cbf
@@ -165,7 +163,6 @@ rootprefix ?= ${base_prefix}
rootlibdir ?= ${base_libdir}
rootlibexecdir = ${rootprefix}/lib
-# The gtk+ tools should get built as a separate recipe e.g. systemd-tools
EXTRA_OECONF = --with-rootprefix=${rootprefix} \
--with-rootlibdir=${rootlibdir} \
${@bb.utils.contains('DISTRO_FEATURES', 'pam',
'--enable-pam', '--disable-pam', d)} \
@@ -267,169 +264,789 @@ do_install_ptest () {
python populate_packages_prepend (){
systemdlibdir = d.getVar(rootlibdir, True)
-do_split_packages(d, systemdlibdir, '^lib(.*)\.so\.*', 'lib%s', 'Systemd
%s library', extra_depends='', allow_links=True)
+do_split_packages(d, systemdlibdir, '^lib(udev|gudev|systemd|nss)\.so\.*',
'lib%s', 'Systemd %s library', extra_depends='', allow_links=True)
}
PACKAGES_DYNAMIC += ^lib(udev|gudev|systemd|nss).*
-PACKAGES =+ ${PN}-gui ${PN}-vconsole-setup ${PN}-initramfs ${PN}-analyze
${PN}-kernel-install \
- ${PN}-rpm-macros ${PN}-binfmt ${PN}-pam ${PN}-zsh libgudev
+
+# Base Packages
+
+
+PACKAGES =+ ${PN}-generators-filesystems
+SUMMARY_${PN}-generators-filesystems = systemd's generator for filesystem
services based on fstab and GPT
+RDEPENDS_${PN}-generators-filesystems = ${PN}-services-fsck
+FILES_${PN}-generators-filesystems = \
+${rootlibexecdir}/systemd/system-generators/systemd-fstab-generator \
+${rootlibexecdir}/systemd/system-generators/systemd-gpt-auto-generator
\
+${rootlibexecdir}/systemd/systemd-remount-fs \
+
${systemd_unitdir}/system/local-fs.target.wants/systemd-remount-fs.service \
+${systemd_unitdir}/system/systemd-remount-fs.service \
+
-SYSTEMD_PACKAGES = ${PN}-binfmt
-SYSTEMD_SERVICE_${PN}-binfmt = systemd-binfmt.service
+PACKAGES =+ ${PN}-generators-getty
+SUMMARY_${PN}-generators-getty = systemd's generator TTY services
+RDEPENDS_${PN}-generators-getty = ${PN}-services-getty
+FILES_${PN}-generators-getty = \
+${rootlibexecdir}/systemd/system-generators/systemd-getty-generator \
+
-USERADD_PACKAGES = ${PN}
-USERADD_PARAM_${PN} += --system systemd-journal-gateway
-GROUPADD_PARAM_${PN} = -r lock; -r systemd-journal
+PACKAGES =+ ${PN}-tools
+SUMMARY_${PN}-tools = systemd command line tools (cgls, delta, run,
analyze...)
+RRECOMMENDS_${PN}-tools = ${PN}-services-base
+FILES_${PN}-tools = \
+${base_bindir}/systemd-machine-id-setup \
+${bindir}/busctl \
+${bindir}/coredumpctl \
+${bindir}/systemd-analyze \
+${bindir}/systemd-cat \
+${bindir}/systemd-cgls \
+${bindir}/systemd-cgtop \
+${bindir}/systemd-delta \
+${bindir}/systemd-detect-virt \
+${bindir}/systemd-path \
+${bindir}/systemd-run \
+${rootlibexecdir}/systemd/systemd-ac-power \
+${rootlibexecdir}/systemd/systemd-activate \
+${rootlibexecdir}/systemd/systemd-reply-password \
+${rootprefix}/bin/systemd-escape \
+${rootprefix}/bin/systemd-notify \
+
-FILES_${PN}-analyze = ${bindir}/systemd-analyze
+
+# Services Packages
+
-FILES_${PN}-initramfs = /init
-RDEPENDS_${PN}-initramfs = ${PN}
+PACKAGES =+ ${PN}-services-ask-password
+SUMMARY_${PN}-services-ask-password = systemd's service and tool to query the
user for a system password
