| Submitter | Ross Burton |
|---|---|
| Date | March 11, 2013, 8:07 p.m. |
| Message ID | <cover.1363031776.git.ross.burton@intel.com> |
| Download | mbox |
| Permalink | /patch/45981/ |
| State | New |
| Headers | show |
Pull-request
git://git.yoctoproject.org/poky-contrib ross/systemdComments
On 11 March 2013 13:07, Ross Burton <ross.burton@intel.com> wrote: > This series allows you to have both sysvinit and systemd in DISTRO_FEATURES. > Packages will be built with both init scripts, and some daemons will be linking > to libsystemd-daemon so that will be pulled in to sysvinit images. Regarding the upgrade path, Richard/Paul/myself discussed this over lunch and proposed that oe-core could gain an include file for distro configuration that basically injects the backward compatibility dependencies. So for meta-systemd, it would inject replaces/provides/conflicts for each of the packages in meta-systemd. This would isolate the dependencies into a single location, and be opt-in for distros that previously shipped meta-systemd. Hopefully the implementation of this is obvious, and patches to implement this are welcome. Ross
On Mon, Mar 11, 2013 at 6:37 PM, Burton, Ross <ross.burton@intel.com> wrote: > On 11 March 2013 13:07, Ross Burton <ross.burton@intel.com> wrote: >> This series allows you to have both sysvinit and systemd in DISTRO_FEATURES. >> Packages will be built with both init scripts, and some daemons will be linking >> to libsystemd-daemon so that will be pulled in to sysvinit images. > > Regarding the upgrade path, Richard/Paul/myself discussed this over > lunch and proposed that oe-core could gain an include file for distro > configuration that basically injects the backward compatibility > dependencies. So for meta-systemd, it would inject > replaces/provides/conflicts for each of the packages in meta-systemd. > This would isolate the dependencies into a single location, and be > opt-in for distros that previously shipped meta-systemd. Hopefully > the implementation of this is obvious, and patches to implement this > are welcome. I personally prefer to still use meta-oe systemd class and keep the possibility to product images with choosen init system. I think Martin will also prefer it.
Hi, On 11 March 2013 14:47, Otavio Salvador <otavio@ossystems.com.br> wrote: > I personally prefer to still use meta-oe systemd class and keep the > possibility to product images with choosen init system. I think Martin > will also prefer it. I'd love Martin to speak for himself in this thread. The big difference between meta-systemd and this series is that if you enable both, you'll get a few service files in the sysvinit images and probably libsystemd-daemon. In total we're talking about a 50K increase here which is for practical purposes negligible. Are you objecting to the redundant service files (which you could remove in a image construction hook, along with anything else that can be wiped when you need to save every byte), or something else? Ross
On Mar 11, 2013, at 2:47 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: > On Mon, Mar 11, 2013 at 6:37 PM, Burton, Ross <ross.burton@intel.com> wrote: >> On 11 March 2013 13:07, Ross Burton <ross.burton@intel.com> wrote: >>> This series allows you to have both sysvinit and systemd in DISTRO_FEATURES. >>> Packages will be built with both init scripts, and some daemons will be linking >>> to libsystemd-daemon so that will be pulled in to sysvinit images. >> >> Regarding the upgrade path, Richard/Paul/myself discussed this over >> lunch and proposed that oe-core could gain an include file for distro >> configuration that basically injects the backward compatibility >> dependencies. So for meta-systemd, it would inject >> replaces/provides/conflicts for each of the packages in meta-systemd. >> This would isolate the dependencies into a single location, and be >> opt-in for distros that previously shipped meta-systemd. Hopefully >> the implementation of this is obvious, and patches to implement this >> are welcome. > > I personally prefer to still use meta-oe systemd class and keep the > possibility to product images with choosen init system. I think Martin > will also prefer it. using different init manager is a separate problem than what Ross tried to address here isn't it ? I personally don't have a use case where I would upgrade live from 1.3 to 1.4 so for me I could easily accept a different solution for 1.4 > > -- > Otavio Salvador O.S. Systems > E-mail: otavio@ossystems.com.br http://www.ossystems.com.br > Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On 11 March 2013 15:49, Khem Raj <raj.khem@gmail.com> wrote:
> using different init manager is a separate problem than what Ross tried to address here isn't it ?
This series lets you do DISTRO_FEATURES="systemd sysvinit" and it will
build support for both in the packages, and then based on
DISTRO_FEATURES_INITMAN it will build different images.
Ross
Op 11 mrt. 2013, om 23:49 heeft Khem Raj <raj.khem@gmail.com> het volgende geschreven: > > On Mar 11, 2013, at 2:47 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: > >> On Mon, Mar 11, 2013 at 6:37 PM, Burton, Ross <ross.burton@intel.com> wrote: >>> On 11 March 2013 13:07, Ross Burton <ross.burton@intel.com> wrote: >>>> This series allows you to have both sysvinit and systemd in DISTRO_FEATURES. >>>> Packages will be built with both init scripts, and some daemons will be linking >>>> to libsystemd-daemon so that will be pulled in to sysvinit images. >>> >>> Regarding the upgrade path, Richard/Paul/myself discussed this over >>> lunch and proposed that oe-core could gain an include file for distro >>> configuration that basically injects the backward compatibility >>> dependencies. So for meta-systemd, it would inject >>> replaces/provides/conflicts for each of the packages in meta-systemd. >>> This would isolate the dependencies into a single location, and be >>> opt-in for distros that previously shipped meta-systemd. Hopefully >>> the implementation of this is obvious, and patches to implement this >>> are welcome. >> >> I personally prefer to still use meta-oe systemd class and keep the >> possibility to product images with choosen init system. I think Martin >> will also prefer it. > > using different init manager is a separate problem than what Ross tried to address here isn't it ? > I personally don't have a use case where I would upgrade live from 1.3 to 1.4 so > for me I could easily accept a different solution for 1.4 Upgrading between 1.3 and 1.4 is already impossible for non-systemd related reasons. But that shouldn't be a reason to break upgrade paths for other things, so I'd very much like to see some attention to this for 1.5.
Op 12 mrt. 2013, om 00:21 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven: > On 11 March 2013 15:49, Khem Raj <raj.khem@gmail.com> wrote: >> using different init manager is a separate problem than what Ross tried to address here isn't it ? > > This series lets you do DISTRO_FEATURES="systemd sysvinit" and it will > build support for both in the packages, and then based on > DISTRO_FEATURES_INITMAN it will build different images. Isn't DISTRO_FEATURES_INITMAN more like an IMAGE_FEATURE now?
On Tue, 2013-03-12 at 08:42 +0100, Koen Kooi wrote: > Op 11 mrt. 2013, om 23:49 heeft Khem Raj <raj.khem@gmail.com> het volgende geschreven: > > > > > On Mar 11, 2013, at 2:47 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: > > > >> On Mon, Mar 11, 2013 at 6:37 PM, Burton, Ross <ross.burton@intel.com> wrote: > >>> On 11 March 2013 13:07, Ross Burton <ross.burton@intel.com> wrote: > >>>> This series allows you to have both sysvinit and systemd in DISTRO_FEATURES. > >>>> Packages will be built with both init scripts, and some daemons will be linking > >>>> to libsystemd-daemon so that will be pulled in to sysvinit images. > >>> > >>> Regarding the upgrade path, Richard/Paul/myself discussed this over > >>> lunch and proposed that oe-core could gain an include file for distro > >>> configuration that basically injects the backward compatibility > >>> dependencies. So for meta-systemd, it would inject > >>> replaces/provides/conflicts for each of the packages in meta-systemd. > >>> This would isolate the dependencies into a single location, and be > >>> opt-in for distros that previously shipped meta-systemd. Hopefully > >>> the implementation of this is obvious, and patches to implement this > >>> are welcome. > >> > >> I personally prefer to still use meta-oe systemd class and keep the > >> possibility to product images with choosen init system. I think Martin > >> will also prefer it. > > > > using different init manager is a separate problem than what Ross tried to address here isn't it ? > > I personally don't have a use case where I would upgrade live from 1.3 to 1.4 so > > for me I could easily accept a different solution for 1.4 > > Upgrading between 1.3 and 1.4 is already impossible for non-systemd > related reasons. Which reasons? Cheers, Richard
On 12 March 2013 00:42, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Isn't DISTRO_FEATURES_INITMAN more like an IMAGE_FEATURE now?
In a sense - it populates a distro feature though a backfill and is
used when constructing an image, so if you explicitly set
DISTRO_FEATURES to include both then swapping this will change the
image.
As I said, it should probably be renamed. Any suggestions?
Ross
Op 12 mrt. 2013, om 19:50 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven: > On Tue, 2013-03-12 at 08:42 +0100, Koen Kooi wrote: >> Op 11 mrt. 2013, om 23:49 heeft Khem Raj <raj.khem@gmail.com> het volgende geschreven: >> >>> >>> On Mar 11, 2013, at 2:47 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: >>> >>>> On Mon, Mar 11, 2013 at 6:37 PM, Burton, Ross <ross.burton@intel.com> wrote: >>>>> On 11 March 2013 13:07, Ross Burton <ross.burton@intel.com> wrote: >>>>>> This series allows you to have both sysvinit and systemd in DISTRO_FEATURES. >>>>>> Packages will be built with both init scripts, and some daemons will be linking >>>>>> to libsystemd-daemon so that will be pulled in to sysvinit images. >>>>> >>>>> Regarding the upgrade path, Richard/Paul/myself discussed this over >>>>> lunch and proposed that oe-core could gain an include file for distro >>>>> configuration that basically injects the backward compatibility >>>>> dependencies. So for meta-systemd, it would inject >>>>> replaces/provides/conflicts for each of the packages in meta-systemd. >>>>> This would isolate the dependencies into a single location, and be >>>>> opt-in for distros that previously shipped meta-systemd. Hopefully >>>>> the implementation of this is obvious, and patches to implement this >>>>> are welcome. >>>> >>>> I personally prefer to still use meta-oe systemd class and keep the >>>> possibility to product images with choosen init system. I think Martin >>>> will also prefer it. >>> >>> using different init manager is a separate problem than what Ross tried to address here isn't it ? >>> I personally don't have a use case where I would upgrade live from 1.3 to 1.4 so >>> for me I could easily accept a different solution for 1.4 >> >> Upgrading between 1.3 and 1.4 is already impossible for non-systemd >> related reasons. > > Which reasons? Warning, handwaving ahead: Renamed packages, differently split packages et cetera.
On Wed, 2013-03-13 at 10:09 +0100, Koen Kooi wrote: > Op 12 mrt. 2013, om 19:50 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven: > > On Tue, 2013-03-12 at 08:42 +0100, Koen Kooi wrote: > >> Op 11 mrt. 2013, om 23:49 heeft Khem Raj <raj.khem@gmail.com> het volgende geschreven: > >> Upgrading between 1.3 and 1.4 is already impossible for non-systemd > >> related reasons. > > > > Which reasons? > > Warning, handwaving ahead: Renamed packages, differently split packages et cetera. I thought we'd put Conflicts/Provides and other pieces in place to try and avoid this? If there are issues, I'm open to patches which help address the problems. Cheers, Richard
On Wed, Mar 13, 2013 at 07:18:39PM +0000, Richard Purdie wrote: > On Wed, 2013-03-13 at 10:09 +0100, Koen Kooi wrote: > > Op 12 mrt. 2013, om 19:50 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven: > > > On Tue, 2013-03-12 at 08:42 +0100, Koen Kooi wrote: > > >> Op 11 mrt. 2013, om 23:49 heeft Khem Raj <raj.khem@gmail.com> het volgende geschreven: > > >> Upgrading between 1.3 and 1.4 is already impossible for non-systemd > > >> related reasons. > > > > > > Which reasons? > > > > Warning, handwaving ahead: Renamed packages, differently split packages et cetera. > > I thought we'd put Conflicts/Provides and other pieces in place to try > and avoid this? If there are issues, I'm open to patches which help > address the problems. I try to report such issues as soon as they are introduced to developer who introduced them, but quite often those emails got no reply and issue is forgotten. I know I should report them in bugzilla, but I usually use oe-commits list to find what changed since my last successful opkg upgrade and it's faster to just reply there then to create new bug report. Most of those issues would be detected by developers if they build with buildhistory enabled and do upgrade on target device.
Hi, This series allows you to have both sysvinit and systemd in DISTRO_FEATURES. Packages will be built with both init scripts, and some daemons will be linking to libsystemd-daemon so that will be pulled in to sysvinit images. The init manager used at image construction time is DISTRO_FEATURES_INITMAN (maybe this should be renamed) and that value is also backfilled into DISTRO_FEATURES. The key change is that systemd.bbclass only recommends systemd, and will check that there's a systemctl binary before calling it - this allows packages built like this to be installed on a systemd-free image. This is very much a RFC, I've done some basic testing but between illness and having to prepare for a presentation at this conference I've not been able to test it as much as I'd hoped. Review and testing very much appreciated. Some metrics: adding the systemd feature but still using sysvinit when building the image results in just libsystemd-daemon and the service files being added to the image, with a negliable size increase. Ross The following changes since commit 1fd5b960dd36458b7b829f9094df18cd8b5ac201: systemd: remove libsystemd-daemon linkage in libudev (2013-03-11 10:59:54 -0700) are available in the git repository at: git://git.yoctoproject.org/poky-contrib ross/systemd for you to fetch changes up to ba7c15ae47ace8a15d97b4c58d2aa5b2ebb4c47a: default-distrovars: don't add DISTRO_FEATURES_INITMAN to DISTRO_FEATURES (2013-03-11 12:17:49 -0700) ---------------------------------------------------------------- Radu Moisan (1): busybox: add systemd enabling for syslog and klogd Ross Burton (8): systemd: merge udev-systemd into udev systemd: make xz support (compressed journal) optional default-providers: change udev selection logic update-rcd.bbclass: handle both sysvinit and systemd features being present systemd: allow postinsts to run without systemd being present systemd: add udev init script for hybrid sysvinit/systemd usage update-rc.d/systemd: change communication variable name default-distrovars: don't add DISTRO_FEATURES_INITMAN to DISTRO_FEATURES meta/classes/systemd.bbclass | 37 ++++--- meta/classes/update-rc.d.bbclass | 7 +- meta/conf/distro/include/default-distrovars.inc | 2 +- meta/conf/distro/include/default-providers.inc | 2 +- meta/recipes-core/busybox/busybox.inc | 17 +++- meta/recipes-core/busybox/busybox_1.20.2.bb | 2 + .../busybox/files/busybox-klogd.service.in | 8 ++ .../busybox/files/busybox-syslog.service.in | 13 +++ .../packagegroups/packagegroup-core-boot.bb | 4 +- meta/recipes-core/systemd/systemd/init | 101 ++++++++++++++++++++ meta/recipes-core/systemd/systemd_197.bb | 26 +++-- 11 files changed, 184 insertions(+), 35 deletions(-) create mode 100644 meta/recipes-core/busybox/files/busybox-klogd.service.in create mode 100644 meta/recipes-core/busybox/files/busybox-syslog.service.in create mode 100644 meta/recipes-core/systemd/systemd/init Radu Moisan (1): busybox: add systemd enabling for syslog and klogd Ross Burton (8): systemd: merge udev-systemd into udev systemd: make xz support (compressed journal) optional default-providers: change udev selection logic update-rcd.bbclass: handle both sysvinit and systemd features being present systemd: allow postinsts to run without systemd being present systemd: add udev init script for hybrid sysvinit/systemd usage update-rc.d/systemd: change communication variable name default-distrovars: don't add DISTRO_FEATURES_INITMAN to DISTRO_FEATURES meta/classes/systemd.bbclass | 37 ++++--- meta/classes/update-rc.d.bbclass | 7 +- meta/conf/distro/include/default-distrovars.inc | 2 +- meta/conf/distro/include/default-providers.inc | 2 +- meta/recipes-core/busybox/busybox.inc | 17 +++- meta/recipes-core/busybox/busybox_1.20.2.bb | 2 + .../busybox/files/busybox-klogd.service.in | 8 ++ .../busybox/files/busybox-syslog.service.in | 13 +++ .../packagegroups/packagegroup-core-boot.bb | 4 +- meta/recipes-core/systemd/systemd/init | 101 ++++++++++++++++++++ meta/recipes-core/systemd/systemd_197.bb | 26 +++-- 11 files changed, 184 insertions(+), 35 deletions(-) create mode 100644 meta/recipes-core/busybox/files/busybox-klogd.service.in create mode 100644 meta/recipes-core/busybox/files/busybox-syslog.service.in create mode 100644 meta/recipes-core/systemd/systemd/init