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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.