From: Owen Synge <osynge@suse.com>
To: Sage Weil <sage@newdream.net>
Cc: ceph-devel@vger.kernel.org
Subject: Re: packaging init systems in a more autoools style way.
Date: Wed, 03 Jun 2015 22:33:04 +0200 [thread overview]
Message-ID: <556F6480.1090901@suse.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1506030919460.9814@cobra.newdream.net>
On 06/03/2015 06:26 PM, Sage Weil wrote:
> On Wed, 3 Jun 2015, Owen Synge wrote:
>> Dear ceph-devel,
>>
>> Linux has more than one init systems.
>>
>> We in SUSE are in the process of up streaming our spec files, and all
>> our releases are systemd based.
>>
>> Ceph seems more tested with sysVinit upstream.
>>
>> We have 3 basic options for doing this in a packaged upstream system.
>>
>> 1) We dont install init scripts/config as part of "make install" and
>> "install all the init components via conditionals in the spec file.
>>
>> 2) We install all init scripts/config for all flavours of init using
>> make install and delete unwanted init systems via conditionals in the
>> spec file.
>>
>> 3) We add autotools an conditional for each init system, and only
>> install with make install enabled init systems scripts/config.
<snip/>
>>
>> Their are many ways to follow policy 3 so I would propose that when no
>> init system is followed, policy (1) and policy (3) should appear identical.
>>
>> -----
>
> Let's do it!
Great :)
<snip/>
> I'm hoping that phase 3 can be avoided entirely. The upgrade/conversion
> path (at least for upstream packages) will be firefly -> infernalis; I'm
> don't think it will be that useful to build infernalis packages that do
> sysvinit for systemd distros. (Maybe this situation gets more
> complicated if we backport this transition to hammer or downstream does
> the same, but even then the transition will be an upgrade one.)
Agreed,
<snip/>
> Also, I think we should do 1 and 2 basically at the same time. I don't
> think it's worth spending any effort trying to make things behave with
> just 1 (and not 2).
>
> Am I talking sense? I can never tell with this stuff. :)
>
> sage
I think you speak sense,
If I underwstand right you favor the user interface as:
--with-init=systemd
--with-init=sysv
--with-init=upstart
--with-init=bsd
This is wiser when you start adding up all the possible init systems
that can exist.
Owen
next prev parent reply other threads:[~2015-06-03 20:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 15:32 packaging init systems in a more autoools style way Owen Synge
2015-06-03 16:21 ` Ken Dreyer
2015-06-03 16:26 ` Sage Weil
2015-06-03 20:33 ` Owen Synge [this message]
2015-06-03 20:45 ` Sage Weil
2015-06-03 21:36 ` Ken Dreyer
2015-06-03 21:38 ` Gregory Farnum
2015-06-03 21:41 ` Ken Dreyer
2015-06-03 21:38 ` Sage Weil
2015-06-03 21:40 ` Ken Dreyer
2015-06-03 21:42 ` Sage Weil
2015-06-06 10:37 ` Alex Elsayed
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=556F6480.1090901@suse.com \
--to=osynge@suse.com \
--cc=ceph-devel@vger.kernel.org \
--cc=sage@newdream.net \
/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.