packaging init systems in a more autoools style way.

packaging init systems in a more autoools style way.

[Owen Synge]

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.

------

We are currently following policy (1)

I propose we follow policy (3) because (1) makes many distribution
specific conditionals and requires duplication for each platform for all
files not installed with "make install".

-----

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.

-----

For a transition period between following policy (1) to policy (3)

phase (1)

I would expect we would add a conditional to ceph.spec for suse to add
to the configure step:

	--with-init-systemd

And when other distributions want to move to a full systemd flavour they
also add a similar conditional.

phase (2)

We add a new configure level conditional:

	--with-init-sysv

All sysV init installs are removed from from the spec file and added to
the "make install" process.

phase (3)

Distributions with more than one init system, or init systems that can
emulate sysVinit, can build packages with either init system and so
migration can be tested.

-----

Does anyone object to this plan?
Does anyone agree with this plan?
Does anyone see difficulties with the plan?

Best regards

Owen


-- 
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
21284 (AG
Nürnberg)

Maxfeldstraße 5

90409 Nürnberg

Germany
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: packaging init systems in a more autoools style way.

[Ken Dreyer]

On 06/03/2015 09:32 AM, Owen Synge wrote:
> 3) We add autotools an conditional for each init system, and only
> install with make install enabled init systems scripts/config.

This plan (3) sounds great to me.

- Ken

Re: packaging init systems in a more autoools style way.

[Sage Weil]

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.
> 
> ------
> 
> We are currently following policy (1)
> 
> I propose we follow policy (3) because (1) makes many distribution
> specific conditionals and requires duplication for each platform for all
> files not installed with "make install".
> 
> -----
> 
> 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!

> For a transition period between following policy (1) to policy (3)
> 
> phase (1)
> 
> I would expect we would add a conditional to ceph.spec for suse to add
> to the configure step:
> 
> 	--with-init-systemd
> 
> And when other distributions want to move to a full systemd flavour they
> also add a similar conditional.
> 
> phase (2)
> 
> We add a new configure level conditional:
> 
> 	--with-init-sysv
> 
> All sysV init installs are removed from from the spec file and added to
> the "make install" process.
> 
> phase (3)
> 
> Distributions with more than one init system, or init systems that can
> emulate sysVinit, can build packages with either init system and so
> migration can be tested.
> 
> -----
> 
> Does anyone object to this plan?
> Does anyone agree with this plan?
> Does anyone see difficulties with the plan?

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.)

Ken and I talked a bit about this yesterday and he convinced me that 
catering to multiple init systems w/in a single distro (e.g., by letting 
sysvinit and systemd files coexist) is not worth our time.  This has the 
nice benefit of letting us sunset the 
/var/lib/ceph/*/*/{sysvinit,upstart,systemd} files.

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

Re: packaging init systems in a more autoools style way.

[Owen Synge]

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

Re: packaging init systems in a more autoools style way.

[Sage Weil]

On Wed, 3 Jun 2015, Owen Synge wrote:
> > 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.

Sounds good to me.  It could (should?) even error out if no init system is 
specified?  Otherwise someone will likely be in for a surprise.

sage

Re: packaging init systems in a more autoools style way.

[Ken Dreyer]

On 06/03/2015 02:45 PM, Sage Weil wrote:
> Sounds good to me.  It could (should?) even error out if no init
system is
> specified?  Otherwise someone will likely be in for a surprise.

I was picturing that we'd just autodetect based on OS version (eg Ubuntu
15.04 should default to --with-init=systemd). It's one less thing to get
wrong during the build process.

What do you think?

- Ken

Re: packaging init systems in a more autoools style way.

[Gregory Farnum]

On Wed, Jun 3, 2015 at 2:36 PM, Ken Dreyer <kdreyer@redhat.com> wrote:
> On 06/03/2015 02:45 PM, Sage Weil wrote:
>> Sounds good to me.  It could (should?) even error out if no init
> system is
>> specified?  Otherwise someone will likely be in for a surprise.
>
> I was picturing that we'd just autodetect based on OS version (eg Ubuntu
> 15.04 should default to --with-init=systemd). It's one less thing to get
> wrong during the build process.
>
> What do you think?

Debian users will get very angry at us. ;)
We could maybe autodetect if they don't specify one?
-Greg

Re: packaging init systems in a more autoools style way.

[Sage Weil]

On Wed, 3 Jun 2015, Ken Dreyer wrote:
> On 06/03/2015 02:45 PM, Sage Weil wrote:
> > Sounds good to me.  It could (should?) even error out if no init
> system is
> > specified?  Otherwise someone will likely be in for a surprise.
> 
> I was picturing that we'd just autodetect based on OS version (eg Ubuntu
> 15.04 should default to --with-init=systemd). It's one less thing to get
> wrong during the build process.
> 
> What do you think?

./configure ... --with-init=`src/ceph-detect-init` ?

sage

Re: packaging init systems in a more autoools style way.

[Ken Dreyer]

On 06/03/2015 03:38 PM, Sage Weil wrote:
> On Wed, 3 Jun 2015, Ken Dreyer wrote:
>> On 06/03/2015 02:45 PM, Sage Weil wrote:
>>> Sounds good to me.  It could (should?) even error out if no init
>> system is
>>> specified?  Otherwise someone will likely be in for a surprise.
>>
>> I was picturing that we'd just autodetect based on OS version (eg Ubuntu
>> 15.04 should default to --with-init=systemd). It's one less thing to get
>> wrong during the build process.
>>
>> What do you think?
> 
> ./configure ... --with-init=`src/ceph-detect-init` ?
> 
> sage
> 

I should have been clearer. I was thinking that we'd call that
detect-init script inside ./configure itself , unless the user specifies
--with-init=foo .

- Ken

Re: packaging init systems in a more autoools style way.

[Ken Dreyer]

On 06/03/2015 03:38 PM, Gregory Farnum wrote:
> We could maybe autodetect if they don't specify one?

Sorry, yes, that's what I meant; my last email was unclear.

- Ken

Re: packaging init systems in a more autoools style way.

[Sage Weil]

On Wed, 3 Jun 2015, Ken Dreyer wrote:
> On 06/03/2015 03:38 PM, Sage Weil wrote:
> > On Wed, 3 Jun 2015, Ken Dreyer wrote:
> >> On 06/03/2015 02:45 PM, Sage Weil wrote:
> >>> Sounds good to me.  It could (should?) even error out if no init
> >> system is
> >>> specified?  Otherwise someone will likely be in for a surprise.
> >>
> >> I was picturing that we'd just autodetect based on OS version (eg Ubuntu
> >> 15.04 should default to --with-init=systemd). It's one less thing to get
> >> wrong during the build process.
> >>
> >> What do you think?
> > 
> > ./configure ... --with-init=`src/ceph-detect-init` ?
> > 
> > sage
> > 
> 
> I should have been clearer. I was thinking that we'd call that
> detect-init script inside ./configure itself , unless the user specifies
> --with-init=foo .

Works for me, as long as there is only 1 piece of code (ceph-detect-init) 
that does the detection!

sage

Re: packaging init systems in a more autoools style way.

[Alex Elsayed]

Owen Synge wrote:

<snip>

> If I underwstand right you favor the user interface as:
> 
> --with-init=systemd
> --with-init=sysv
> --with-init=upstart
> --with-init=bsd

Please do be sure to make --with-init=systemd respect the
--with-systemdsystemunitdir=PATH option, as some distros rely on that to 
properly place the unit files. (It's a near-universal feature in autoconf-
based packages that use systemd; rsyslog and dbus are examples)