Bug#727708: Thoughts on Init System Debate

[Don Armstrong]

On Sun, 19 Jan 2014, Steve Langasek wrote:
> I'm not sure I understand. Do you mean you think the systemd landscape
> may change in the future, making it possible to port systemd to other
> kernels; or do you mean that you "would like to see" a single
> supported init system, but are willing to sacrifice this desire for a
> greater good of keeping Debian portable to other kernels?

The latter. I want to see a single supported init system, and I hope it
will happen some day, but I'm OK with sacrificing it for the time being.

> With infinite resources and infinite will to match systemd
> feature-for-feature on Hurd and FreeBSD, it would obviously be
> possible to deliver the same experience on all architectures using
> systemd. But we shouldn't kid ourselves by treating this as a *likely*
> outcome.

Right, I don't believe it is likely either. I was just taking a moment
to describe what an ideal world would look like.

-- 
Don Armstrong  http://www.donarmstrong.com

It can sometimes happen that a scholar, his task completed, discovers
that he has no one to thank. Never mind. He will invent some debts.
Research without indebtedness is suspect, and somebody must always,
somehow, be thanked.
 -- Umberto Eco "How to Write an Introduction"


-- 
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/20140121212522.gd12...@rzlab.ucr.edu

Bug#727708: Thoughts on Init System Debate

[Don Armstrong]

On Sun, 19 Jan 2014, Steve Langasek wrote:
> As you say that planned features or development could sway your
> opinion: are there particular features that you have in mind, here?
> For instance, correcting upstart's socket-based activation interface
> is on the upstart roadmap in the jessie timeframe.

These particular changes would make my decision even more difficult, but
wouldn't change it.

More major changes, like adding features to eliminate the need for
non-descriptive shell fragments, and moving to a primarily dependency
based model from an event one would completely reduce the technically
superior position that systemd has, in my opinion.

-- 
Don Armstrong  http://www.donarmstrong.com

A Bill of Rights that means what the majority wants it to mean is worthless. 
 -- U.S. Supreme Court Justice Antonin Scalia


-- 
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/20140121212154.gc12...@rzlab.ucr.edu

Bug#727708: On diversity

[Ian Jackson]

(Thorsten: your message went to debian-ctte@lists when it should have
gone to the bug report.  Can you try to make whatever cause that not
do that again please ?

Philipp: therefore, your message also went to the list directly and
not via the bug.)

Philipp Kern writes ("Re: Bug#727708: On diversity"):
> On 2014-01-21 19:04, Thorsten Glaser wrote:
> >>  [systemd-portability] Maintainers should be aware systemd relies
> >> heavily on cgroups and potentially other Linux-only features, and thus
> > This is also heavy on kernel configs, FWIW. But the question here
> > is: will maintainers please set the Architecture field of their
> > source packages *not* to “all” but only to those it’ll build/work
> > on?
> 
> They should not. If you require systemd at runtime, build-depend on it 
> and you will not be scheduled on other architectures. Of course we push 
> this more and more which makes accurate statistics of what's 
> legitimately excluded on an architecture to calculate coverage a bit 
> harder. But it is still possible, especially if we have highly visible 
> nodes like systemd in the graph.


--
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/21214.49493.817269.315...@chiark.greenend.org.uk

Re: Bug#727708: On diversity

[Philipp Kern]

On 2014-01-21 19:04, Thorsten Glaser wrote:

 [systemd-portability] Maintainers should be aware systemd relies
heavily on cgroups and potentially other Linux-only features, and thus

This is also heavy on kernel configs, FWIW. But the question here
is: will maintainers please set the Architecture field of their
source packages *not* to “all” but only to those it’ll build/work
on?


They should not. If you require systemd at runtime, build-depend on it 
and you will not be scheduled on other architectures. Of course we push 
this more and more which makes accurate statistics of what's 
legitimately excluded on an architecture to calculate coverage a bit 
harder. But it is still possible, especially if we have highly visible 
nodes like systemd in the graph.


Kind regards
Philipp Kern


--
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/ae3cfbafe25945c821dc06b7d1e44...@hub.kern.lc

Re: Bug#727708: On diversity

[Thorsten Glaser]

Anthony Towns dixit:

>  [default-init] Having examined the features and bugs of the various
>init systems packaged for Debian, the default init system for jessie
>for Linux architectures shall be {OpenRC | systemd | upstart |

Please do not forget sysv-rc here.

>determined by a GR}.

>  [systemd-portability] Maintainers should be aware systemd relies
>heavily on cgroups and potentially other Linux-only features, and thus

This is also heavy on kernel configs, FWIW. But the question here
is: will maintainers please set the Architecture field of their
source packages *not* to “all” but only to those it’ll build/work
on?

bye,
//mirabilos
-- 
 Warum ist MirWebseite eigentlich so cool?   weil ich
ich sie geschrieben habe   Hast du sie geschrieben oder geforkt?
 geschrieben, from scratch   Ach, deshalb finde ich
auch so selten Bugs dadrin. Irgendwie hast du Recht.


--
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/pine.bsm.4.64l.1401211801540.19...@herc.mirbsd.org

Bug#727708: On diversity

[Anthony Towns]

On 20 January 2014 14:29, Russ Allbery  wrote:
> Steve Langasek  writes:
>> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
>> For my part I think this is generally a good idea, but I have the
>> impression that at least Russ would be strongly opposed to this because
>> it's too prescriptive.  Probably not much sense in fleshing out such a
>> resolution if there's not a consensus for it.
> I think this is all great work to do.  I'm just dubious about enforcing it
> with a technical committee decision.  This is the sort of thing that I was
> expecting to need to do on the Policy front once we have a decision.  I
> think that's the right forum for drilling into the details.

So I wondered what it might look like to say the same thing in a
minimally prescriptive way. Not even going to try guessing if this is
anywhere sufficient as far as Russ is concerned -- I'm not claiming to
know where Russ might draw the line on that topic. I've also added
some minimal tech ctte-esque boiler plate; I'm sure Ian could do
better.

---
The tech ctte determines as follows:

  [non-essential-init] In order to allow Debian users and developers
to easily design, test and deploy alternative init systems both now
and in the future, no init system in Debian should be provided via an
Essential:yes package.

  [default-init] Having examined the features and bugs of the various
init systems packaged for Debian, the default init system for jessie
for Linux architectures shall be {OpenRC | systemd | upstart |
determined by a GR}.

The tech ctte further offers the following advice to maintainers:

  [logind] The systemd/logind API provided by systemd and documented
on the freedesktop API will be important for a number of packages, and
that API should be made available within Debian for users of init
systems other than systemd. The various non-systemd init system
maintainers are encouraged to work with the systemd maintainers and
upstream to limit the code duplication that may result from this, and
to ensure enhancements and bug fixes are as widely available as
practical (both within Debian for different inits/architectures and
upstream). The maintainers involved should work through the policy
process to establish a virtual package for this API if needed.

  [required-init] In order to avoid users mistakenly removing all init
systems from their machine, we recommend the init maintainers
establish a virtual package (eg, "init-system") that all init systems
in Debian both provide and conflict with, and that an Essential:yes
package depend on that virtual package. This should be undertaken
using the normal policy process.

  [init-minimal-compatability] In order to make it simple for packages
to work with different available init systems, a simple means of
providing a startup script/configuration that is understood by all
Debian init systems should be documented in policy as a requirement
for for packages providing the init system virtual package. This may
be providing a sysvinit style script and adding it via update-rc.d for
instance. This method may be assumed to always be available if the
[required-init] advice is followed, and thus packages can avoid a
dependency on the virtual package.

  [init-crossgrades] In order to provide a good user experience when
switching init systems, maintainers of init systems other than the
default should test converting both to and from their init system, and
that the system is able to correctly shutdown and restart after
transitions to different init systems.

  [init-related-patches] Maintainers should accept non-intrusive
patches to provide enhanced support for init systems (both for the
default init and other inits included in Debian). Patches may be
considered intrusive by the maintainer if they introduce additional
dependencies or significant patches to code that are not accepted
upstream. Patches that merely add files to the package or provide
extra code to maintainer scripts should generally not be considered
intrusive. Where a reasonable amount of time has been given to the
maintainer to review proposed patches via the BTS, and no objection
has been raised, a NMU to incorporate the patch is appropriate.

  [cgroups] Maintainers should be aware cgroups is a Linux-only
feature; if their package requires the use of cgroups to be usable it
should be configured to not build for non-Linux architectures. Where
cgroups support is a compile-time feature, it should generally be
supported on Linux architectures, and disabled on non-Linux
architectures, for the same reason.

  [systemd-portability] Maintainers should be aware systemd relies
heavily on cgroups and potentially other Linux-only features, and thus
should be aware that unless/until this changes, requiring use of a
systemd unit file for startup will likewise require their package to
be configured to not build for non-Linux architectures.
---

I think the [non-essential-init] and any of the four options for
[default-init] would 100% s

Bug#727708: upstadt vs. systemd: events vs. dependencies

[Lucas Nussbaum]

On 21/01/14 at 12:27 +0100, Matthias Urlichs wrote:
> Hi,
> 
> in this debate, enlightening *ahem* as it was, I think that one aspect
> didn't get the attention it should get. (IMHO.)
> 
> 
> systemd uses dependencies. Upstart uses events.

This was already discussed in the following subthreads:

https://lists.debian.org/debian-ctte/2013/11/msg00021.html

2.3 in https://lists.debian.org/debian-ctte/2013/12/msg00234.html

http://lists.debian.org/20131231025545.ga23...@riva.ucam.org (search for
"event")
the subthread starting with
http://lists.debian.org/87sit9puow@windlord.stanford.edu is also
about that.
As well as http://lists.debian.org/20131231032827.GA14382@leaf
and http://lists.debian.org/52c28387.488b440a.0457.5...@mx.google.com
and
http://lists.debian.Org/CAJS_LCUGaM6JS8Ec-73z30+_h8yW+HqSqfqVvHVh=ykpqn+...@mail.gmail.com
 (and its sub-thread)

Also, http://lists.debian.org/7y52zuuaw@vostro.rath.org

At this point of the discussion, stating that "one aspect didn't get the
attention it should get." sounds a lot like "I didn't bother to search the
archives". :-)

- Lucas


-- 
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/20140121130030.ga19...@xanadu.blop.info

Bug#727708: upstadt vs. systemd: events vs. dependencies

[Matthias Urlichs]

Hi,

in this debate, enlightening *ahem* as it was, I think that one aspect
didn't get the attention it should get. (IMHO.)


systemd uses dependencies. Upstart uses events.


Dependencies are static. My job's dependencies are either fulfilled, or
not. This means that troubleshooting is easy --  I can simply look at the
prerequisites and fix whatever is broken, bootup then continues by itself.

Events are dynamic. In order to debug a problem, one needs to know what
happened and in which order. If a job does not start, maybe the event
did not happen -- or it happened too early, or too late, or it's blocked
internally. Yes, upstart does that.

I would like to refer interested parties to two Launchpad bugs,
https://bugs.launchpad.net/upstart/+bug/516713 and
https://bugs.launchpad.net/upstart/+bug/447654, which (despite being three
and four years old, respectively) remain unfixed. They show quite clearly,
IHMO, that upstart's model does not work in the real world, and/or that its
development has stalled.

This would be enough reason for me to choose systemd, even if I were to
disregard all the other features of systemd which upstart does not have
(like the journal, or socket activation that actually works).

I would therefore like to ask the TC to select systemd.

-- 
-- Matthias Urlichs


-- 
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/20140121112701.go4...@smurf.noris.de

Bug#727708: Thoughts on Init System Debate

[David Balch]

On 21 Jan 2014 04:57, "Steve Langasek"  wrote:
>
> On Mon, Jan 20, 2014 at 07:09:51PM -0800, Nikolaus Rath wrote:
> > I would add the very presence of the "mountall" tool to this
> > list. Lennart has described the issues with mountall in
> >
https://plus.google.com/u/0/+LennartPoetteringTheOneAndOnly/posts/ip8e1DqJdxT
,
> > and apparently the upstart developers have been aware them as well since
> > the very beginning (at least since Ubuntu 8.04)
>
> I will not respond to this except to say that I do not agree with
Lennart's
> characterization of mountall as evidence that upstart's model is
incorrect.

Given 
Scott
James Remnant's agreement with Lennart (in a comment on
https://plus.google.com/+KaySievers/posts/C3chC26khpq, around 1UTC on Jan
21st)...

"Hindsight certainly lends a different perspective, and I'd be the first
person to say that Upstart doesn't work as intended. +Lennart
Poettering makes a great point about mountall in a recent post, it was
written because Upstart couldn't do the complex filesystem cases it was
designed to be able to do; and I was very aware even at the time that was a
failure that would need to be addressed."

...it seems that further discussion of these design issues might be a good
idea.

At the least, there should be some progress on the Upstart bug tracker
indicating the shape of a solution for the mountall and The "and/or" bugs
(and any other design issues).

Cheers,
Dave.