All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: "Burton, Ross" <ross.burton@intel.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: Minutes: Yocto Project 1.4 M4 release readiness discussion
Date: Sat, 2 Mar 2013 01:14:00 +0100	[thread overview]
Message-ID: <20130302001400.GX3279@jama> (raw)
In-Reply-To: <CAJTo0LZYoqF++Sw+S1fbaeO-gAm6k9bXJ5gZr2CuTJb3sBvdYg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

On Fri, Mar 01, 2013 at 11:56:32PM +0000, Burton, Ross wrote:
> On 1 March 2013 23:32, Martin Jansa <martin.jansa@gmail.com> wrote:
> > Can you answer this
> > http://lists.linuxtogo.org/pipermail/openembedded-core/2013-February/036223.html
> > and how this solution helps with upgrade paths?
> 
> Having split packages can break the upgrade path - say your distro
> goes from sysvinit to sysvinit rescue + systemd main.  How does your
> foo-daemon package get the right init script package on upgrade?

By right RRECOMMENDS like meta-systemd did.
Plus simple way to exclude some at image creation time with
BAD_RECOMMENDATION or explicit entries pulled with packagegroup for each
type of image.

> I proposed a solution for distributions that care - inject the
> migration path dependencies though meta-systemd.  I still maintain
> that oe-core shouldn't have to bend over backwards to maintain
> compatibility with every recipe that migrates.  Obviously we don't
> want to deliberately break where we have a choice but equally so

http://lists.linuxtogo.org/pipermail/openembedded-core/2013-February/036222.html

> > Coding was contributed to meta-systemd which was working fine for both
> > use-cases. Maybe explaining hidden benefits of not splitted packages
> > would motivate some people..
> 
> The advantage of having init scripts in the daemon package is
> simplicity.  For the cost of two init scripts (what, 1K between them?)
> you remove lots of complexity, including the upgrade path breakage I
> described above.

There is no upgrade path breakage and complexity is in postinst scripts
which need to support both update-rc.d and systemctl calls.

Lets discuss this in that oe-core thread so that other people not subscribed 
to yocto ML can also comment.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

      reply	other threads:[~2013-03-02  0:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-01 20:01 Minutes: Yocto Project 1.4 M4 release readiness discussion Liu, Song
2013-03-01 21:53 ` Martin Jansa
2013-03-01 23:08   ` Burton, Ross
2013-03-01 23:32     ` Martin Jansa
2013-03-01 23:56       ` Burton, Ross
2013-03-02  0:14         ` Martin Jansa [this message]

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=20130302001400.GX3279@jama \
    --to=martin.jansa@gmail.com \
    --cc=ross.burton@intel.com \
    --cc=yocto@yoctoproject.org \
    /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.