From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Koen Kooi <koen@dominion.thruhere.net>
Cc: Otavio Salvador <otavio@ossystems.com.br>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [RFC PATCH 0/9] hybrid systemd/sysvinit
Date: Tue, 12 Mar 2013 18:50:48 +0000 [thread overview]
Message-ID: <1363114248.9859.17.camel@ted> (raw)
In-Reply-To: <980599F4-DEED-41CF-B871-750758BD6D45@dominion.thruhere.net>
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
next prev parent reply other threads:[~2013-03-12 19:08 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-11 20:07 [RFC PATCH 0/9] hybrid systemd/sysvinit Ross Burton
2013-03-11 20:07 ` [PATCH 1/9] systemd: merge udev-systemd into udev Ross Burton
2013-03-11 20:07 ` [PATCH 2/9] busybox: add systemd enabling for syslog and klogd Ross Burton
2013-03-11 20:07 ` [PATCH 3/9] systemd: make xz support (compressed journal) optional Ross Burton
2013-03-11 20:07 ` [PATCH 4/9] default-providers: change udev selection logic Ross Burton
2013-03-11 20:07 ` [PATCH 5/9] update-rcd.bbclass: handle both sysvinit and systemd features being present Ross Burton
2013-03-12 7:12 ` Martin Jansa
2013-03-11 20:07 ` [PATCH 6/9] systemd: allow postinsts to run without systemd " Ross Burton
2013-03-12 10:36 ` Enrico Scholz
2013-03-19 11:23 ` Burton, Ross
2013-03-19 12:09 ` Enrico Scholz
2013-03-19 12:11 ` Burton, Ross
2013-03-19 13:00 ` Enrico Scholz
2013-03-19 11:39 ` Burton, Ross
2013-03-19 12:12 ` Enrico Scholz
2013-03-11 20:07 ` [PATCH 7/9] systemd: add udev init script for hybrid sysvinit/systemd usage Ross Burton
2013-03-11 20:07 ` [PATCH 8/9] update-rc.d/systemd: change communication variable name Ross Burton
2013-03-11 20:07 ` [PATCH 9/9] default-distrovars: don't add DISTRO_FEATURES_INITMAN to DISTRO_FEATURES Ross Burton
2013-03-11 21:37 ` [RFC PATCH 0/9] hybrid systemd/sysvinit Burton, Ross
2013-03-11 21:47 ` Otavio Salvador
2013-03-11 21:58 ` Burton, Ross
2013-03-11 22:49 ` Khem Raj
2013-03-11 23:21 ` Burton, Ross
2013-03-12 7:42 ` Koen Kooi
2013-03-12 20:18 ` Burton, Ross
2013-03-12 7:42 ` Koen Kooi
2013-03-12 18:50 ` Richard Purdie [this message]
2013-03-13 9:09 ` Koen Kooi
2013-03-13 19:18 ` Richard Purdie
2013-03-13 22:09 ` Martin Jansa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1363114248.9859.17.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=koen@dominion.thruhere.net \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio@ossystems.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox