Bug#727708: Thoughts/Summary on the init-system

2014-02-14 Thread Andreas Barth
* Andreas Metzler (ametz...@bebt.de) [140119 19:18]:
 could you provide a little bit of background why you consider both
 Systemd on Linux, openrc/sysv-rc on non-Linux and Upstart
 everywhere viable long-term but not systemd on Linux  and upstart on
 !Linux?


Because upstart won't survive Debians decision for systemd. And that
shouldn't come as a surprise because maintenance costs for
upstart-compatible packages are much higher when Debian moves the
packages away from sysv-style init scripts.


Andi


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140214201728.gg16...@mails.so.argh.org



Bug#727708: Thoughts/Summary on the init-system

2014-01-19 Thread Andreas Barth
Hi together,

first of all, sorry for being so late to this party.

I'll start with describing a few facts, observations and thoughts, and come
to my conclusions at the end of this mail. I don't write references at
places where I believe had already sufficient coverage by others and/or are
more or less not really doubted. I also didn't write at all possible
required locations as far as reasonable or similar - I assume and expect
that we all try to integrate our system as good as reasonably possible
without wasting too much time for details nobody cares about, and I didn't
want to write it at all places again and again. (And just because something
is technically possible doesn't mean it is reasonable possible, and if I
write possible below it refers to reasonable possible, and same with
similar words.) Also I try to not repeat too much of what had already been
written by others, especially in other summaries.


What are we speaking about? There are three different things: The
pid1-provider, means: what is init in the terms of the linux command line
(current default: sysvinit).  Then the runlevel-manager (current default:
sysv-rc). And then a daemon which could start and stop other services
(which is always provided by the pid1-provider, but there are other in
Debian, and as long as they could be used at the same time together, I
don't think there is any conflict, and so no reason for a decision).

Also, as discussion has shown, we speak about what is default in Debian
(please note that this could be more than one overall, so it might be
defaults in Debian). Then, what is required to be supported (at least
what is default anywhere on a architecture in testing). And then what else
are maintainers supposed to support on an higher than wishlist level.


State of the different init systems: First of all, I think that all three
contenders are better than our current state.  Systemd and upstart are way
better, openrc still is a major improvement about sysv-rc. So all three are
in the game for me.


I however don't believe that we could realistically support all three
(four) equally good at the same time. It might had worked if somebody would
have found a clever meta-format that could be autoconverted by debhelper in
almost all cases, but as none is there yet I doubt it's realistic. It might
work that we support two of them at the same time, but even that is a bit
painful for us (and there should probably be some autotesting then as
suggested by Anthony recently).



So, what could realistically work:

On the linux ports, all would work. On the kbsd ports I believe that both
upstart and openrc could be working, but none is yet. For hurd, at least
openrc could and probably also upstart.

Porting systemd to kbsd or hurd is not realistic from what I understood
(unless they basically clone the linux cgroups feature), but a parallel
implementation of programm with similar configuration files would be
possible (but I don't believe in that, especially for the long-term
maintenance[1]). Porting upstart seems to be possible, but has the CLA-issue
which makes flowing patches back to upstream harder (and therefor I would
recommend Canonical to not use this policy for upstart), so we would have
to carry extra patches within Debian (which however doesn't look as painful
as a parallel implementation of systemd).  Openrc looks like it could work
in the upstream way everywhere, but needs a bit of porting.

I don't believe that it would work long-term if we use systemd on Linux and
upstart on !Linux. 

[1] Having a parallel implementation of systemd for kbsd would mean that we
also need to take care that e.g. logind is useable without systemd. Which
however means that we'll have the same work required to use non-systemd as
default on Linux plus some additional work for the systemd-mimikri. Doesn't
sound too attractive to me.



All of that together boils down to these options for the default
pid1-provider / runlevel manager (perhaps after some more porting in this
cycle):
1. Systemd on Linux, openrc/sysv-rc on non-Linux
2. Upstart everywhere
(3. openrc/sysv-rc everywhere - as both systemd and upstart are better, I don't
think this ends high enough on my priority list; see below for details)


What does required to be supported mean? Basically the same as always -
the basic functionality needs to be good useable, and everything else
reasonable supportable as well. And any required to be supported provider
needs to be supported at least to the same amount as any other. This
doesn't mean that functionality needs to re-invented just because it is
technically possible. To take an example from a recent irc conversation, I
don't think it's sensible to expect people to do multi-instance setup in
sysv-rc just because it is technically possible (but extremly painful) and
it is done in (systemd or upstart), but on the other hand, if systemd would
be the default and sysv-rc not anymore and someone does multi-instance in
sysv-rc I would expect 

Bug#727708: Thoughts/Summary on the init-system

2014-01-19 Thread Andreas Metzler
On 2014-01-19 Andreas Barth a...@ayous.org wrote:
[...]
 On the linux ports, all would work. On the kbsd ports I believe that both
 upstart and openrc could be working, but none is yet. For hurd, at least
 openrc could and probably also upstart.
 
 Porting systemd to kbsd or hurd is not realistic from what I understood
[...]
 I don't believe that it would work long-term if we use systemd on Linux and
 upstart on !Linux. 
[...]
 All of that together boils down to these options for the default
 pid1-provider / runlevel manager (perhaps after some more porting in this
 cycle):
 1. Systemd on Linux, openrc/sysv-rc on non-Linux
 2. Upstart everywhere
 (3. openrc/sysv-rc everywhere - as both systemd and upstart are
 better, I don't think this ends high enough on my priority list; see
 below for details)
[...]
 Now, putting that all together, from the options above systemd for Linux,
 openrc/sysv-rc for !linux or upstart everywhere I prefer the upstart
 choice. Reasons for this see many details above, supporting all the
 required features, not as invasive in the debian system, saving us to
 integrate more than one init system reasonably well etc.
[...]

Hello,

could you provide a little bit of background why you consider both
Systemd on Linux, openrc/sysv-rc on non-Linux and Upstart
everywhere viable long-term but not systemd on Linux  and upstart on
!Linux?

thanks, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140119181526.gj3...@downhill.g.la



Bug#727708: Thoughts/Summary on the init-system

2014-01-19 Thread Cameron Norman
On Sun, Jan 19, 2014 at 10:27 AM, Steven Chamberlain 
ste...@pyro.eu.org wrote:

On 19/01/14 18:15, Andreas Metzler wrote:

 could you provide a little bit of background why you consider both
 Systemd on Linux, openrc/sysv-rc on non-Linux and Upstart
 everywhere viable long-term but not systemd on Linux  and upstart 
on

 !Linux?


As a porter, I'd slightly prefer we switch to OpenRC on GNU/kFreeBSD.
But, if Upstart were chosen as the default on Debian GNU/Linux, that
might be sufficient to change my mind;  we could stay more closely in
sync with the Linux ports and avoid so much duplication of effort that
way.  So, I would agree exactly with what Andi said.



I suspect that init job/service/script/thingy writers would prefer a 
systemd-OpenRC combo as well, because they are both dependency based 
and the logic of the thingy can be more easily transferred to the 
other format.


Best,
--
Cameron Norman