All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steffen Sledz <sledz@dresearch-fe.de>
To: openembedded-devel@lists.openembedded.org
Cc: Michael Lauer <mickey@vanille-media.de>
Subject: Re: guidelines for upstart in oe?
Date: Fri, 16 Sep 2011 18:15:07 +0200	[thread overview]
Message-ID: <4E73760B.6020605@dresearch-fe.de> (raw)
In-Reply-To: <1316187165.3510.37.camel@phil-desktop>

On 16.09.2011 17:32, Phil Blundell wrote:
> On Fri, 2011-09-16 at 17:29 +0200, Steffen Sledz wrote:
>> On 14.09.2011 17:31, Steffen Sledz wrote:
>>> If i remember right there are some first experiments with using upstart as an sysvinit replacement in some oe based distros.
>>>
>>> Do some guidelines or suggestions exist to make an application recipes upstart ready?
>>>
>>> Nowadays a recipe for a common service contains INITSCRIPT_NAME & Co and installs an init script for sysvinit.
>>>
>>> How should such a recipe be modified to be able to install the application in a native upstart image (without sysvinit compatible runlevels)?
>>
>> Let me put it in concrete terms.
>>
>> Is it possible to write a bb recipe in a way like this?
>>
>> ---------------------->snip<-------------------------
>> ...
>> IF IMAGE USES UPSTART AS INIT THEN
>>
> 
> Fundamentally no, since there is no way to know at the time the recipe
> is evaluated what images it will go into.
> 
> It would be possible to ship both sets of scripts and then have a
> postprocessing step to remove the ones that you don't need.  Or you
> could make upstart vs sysvinit be a DISTRO_FEATURE.  Or, in at least
> some cases, we could probably stop shipping the scripts as discrete
> files altogether and replace them with some symbolic representation from
> which the necessary scripts could be constructed dynamically at install
> time.

I'm not sure if there exist upstart based oe distros/images. But it seems that there are some systemd based ones (recipes/images/angstrom-systemd-image.bb).

Do they have a similar problem? How do these handle the sysvinit config vs. systemd config for the different services?

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058



  reply	other threads:[~2011-09-16 16:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-14 15:31 guidelines for upstart in oe? Steffen Sledz
2011-09-16 15:29 ` Steffen Sledz
2011-09-16 15:32   ` Phil Blundell
2011-09-16 16:15     ` Steffen Sledz [this message]
2011-09-16 20:33       ` Steffen Sledz
2011-09-19  8:06       ` Anders Darander
2011-09-19  9:11         ` Steffen Sledz
2011-09-19  9:12         ` Systemd sysv compat mode, was: " Koen Kooi
2011-09-17  6:24     ` Steffen Sledz
2011-09-19  8:34       ` Phil Blundell
2011-09-16 15:35   ` Koen Kooi

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=4E73760B.6020605@dresearch-fe.de \
    --to=sledz@dresearch-fe.de \
    --cc=mickey@vanille-media.de \
    --cc=openembedded-devel@lists.openembedded.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.