Openembedded Core Discussions
 help / color / mirror / Atom feed
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




  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