From ce096a5e9929fc9489c9168ec79cbf45befa567c Mon Sep 17 00:00:00 2001 From: z3rOR0ne Date: Wed, 30 Nov 2022 00:07:08 -0800 Subject: [PATCH] :memo: Archived debian systemd debate, updated nb urls --- .config/newsboat/urls | 1 + debian_email_systemd.html | 111507 +++++++++++++++++++++++++++++++++++ newsboat/urls | 3 + updates.txt | 3 +- 4 files changed, 111513 insertions(+), 1 deletion(-) create mode 100644 debian_email_systemd.html diff --git a/.config/newsboat/urls b/.config/newsboat/urls index 9eef139b..fbf882e7 100644 --- a/.config/newsboat/urls +++ b/.config/newsboat/urls @@ -6,6 +6,7 @@ https://gabmus.org/index.xml https://www.wilfred.me.uk/rss.xml https://interrupt.memfault.com/feed.xml https://www.brain-dump.org/index.xml +https://planet.debian.org/rss20.xml file://./rss/VYPJXZwH.rss file://./rss/ewontfix.rss file://./rss/0pointer.rss diff --git a/debian_email_systemd.html b/debian_email_systemd.html new file mode 100644 index 00000000..524d286f --- /dev/null +++ b/debian_email_systemd.html @@ -0,0 +1,111507 @@ + + + +#727708 - tech-ctte: Decide which init system to default to in Debian. - Debian Bug report logs + + + + + + + + +

Debian Bug report logs - +#727708
+tech-ctte: Decide which init system to default to in Debian.

+
+
+

Package: + tech-ctte; +Maintainer for tech-ctte is Technical Committee <debian-ctte@lists.debian.org>;

+ +
+ +
+

Reported by: Paul Tagliamonte <paultag@debian.org>

+

Date: Fri, 25 Oct 2013 16:18:01 UTC

+ +

Severity: normal

+

+ + +

Done: Bdale Garbee <bdale@gag.com>

+ +

Bug is archived. No further changes may be made.

+ +

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox

+ +

+ + + +Report forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 25 Oct 2013 16:18:06 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+New Bug report received and forwarded. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 25 Oct 2013 16:18:06 GMT) (full text, mbox, link).

+ +

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: submit@bugs.debian.org
+
Cc: debian-devel@lists.debian.org
+
Subject: tech-ctte: Decide which init system to default to in Debian.
+
Date: Fri, 25 Oct 2013 12:16:04 -0400
+
+
[Message part 1 (text/plain, inline)]
+
Package: tech-ctte
+Severity: normal
+thanks
+
+
+In response to the recent threads, I'd like to ask the tech-ctte to
+please vote on and decide on the default init system for Debian.
+
+There's been quite a lot of discussion and it's clear no consensus is
+coming out of the discussion.
+
+In addition, I find that developers care quite a bit (in both
+directions), and dependencies / conflicts are only going to become more
+common and serious for our users.
+
+
+Thank you!
+  Paul
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>
+: :'  : Proud Debian Developer
+`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+ `-     http://people.debian.org/~paultag
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 25 Oct 2013 16:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 25 Oct 2013 16:48:04 GMT) (full text, mbox, link).

+ +

Message #10 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: 727708@bugs.debian.org
+
Cc: debian-devel@lists.debian.org
+
Subject: Re: tech-ctte: Decide which init system to default to in Debian.
+
Date: Fri, 25 Oct 2013 16:40:15 +0000 (UTC)
+
+
Paul Tagliamonte dixit:
+
+>please vote on and decide on the default init system for Debian.
+
+It’s not (just) about the _default_ but also on whether we will
+force this default init system onto *all* our users, or whether
+we commit to support more than one, and if so, how.
+
+This is an *important* distinction / first step, and it absolutely
+*must* be decided *before* the default is decided, because otherwise
+the default system becomes just so much more important.
+
+Why is it so hard to understand that this is (for me) about
+freedom of choice?
+
+I’d still say, let’s just GR about it. Prepare one now, then
+have some time to cool down before the vote period.
+
+bye,
+//mirabilos
+-- 
+I believe no one can invent an algorithm. One just happens to hit upon it
+when God enlightens him. Or only God invents algorithms, we merely copy them.
+If you don't believe in God, just consider God as Nature if you won't deny
+existence.		-- Coywolf Qi Hunt
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 25 Oct 2013 16:51:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 25 Oct 2013 16:51:09 GMT) (full text, mbox, link).

+ +

Message #15 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: Thorsten Glaser <tg@mirbsd.de>
+
Cc: 727708@bugs.debian.org, debian-devel@lists.debian.org
+
Subject: Re: tech-ctte: Decide which init system to default to in Debian.
+
Date: Fri, 25 Oct 2013 12:48:03 -0400
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Oct 25, 2013 at 04:40:15PM +0000, Thorsten Glaser wrote:
+> Paul Tagliamonte dixit:
+> 
+> >please vote on and decide on the default init system for Debian.
+> 
+> It’s not (just) about the _default_ but also on whether we will
+> force this default init system onto *all* our users, or whether
+> we commit to support more than one, and if so, how.
+
+We've only ever supported one as a project; if you'd like to start
+supporting more, please start a thread on that, and perhaps a release
+goal.
+
+> This is an *important* distinction / first step, and it absolutely
+> *must* be decided *before* the default is decided, because otherwise
+> the default system becomes just so much more important.
+
+The default is the only thing we should support. Trying to support every
+init system is insane, and again, this has implications on how daemons
+are started, and small bugs for some radom daemon may start causing
+subtle heisenbugs in unrelated apps.
+
+> Why is it so hard to understand that this is (for me) about
+> freedom of choice?
+
+It may be, but it's not for the project. Let's let this bug be, and
+have the tech cttie decide on *the* init system for Debian. If you want
+to support more, again, please suggest it in another thread and/or bug.
+
+
+Cheers,
+  Paul
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>
+: :'  : Proud Debian Developer
+`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+ `-     http://people.debian.org/~paultag
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 25 Oct 2013 16:57:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 25 Oct 2013 16:57:10 GMT) (full text, mbox, link).

+ +

Message #20 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
Cc: 727708@bugs.debian.org, debian-devel@lists.debian.org
+
Subject: Re: tech-ctte: Decide which init system to default to in Debian.
+
Date: Fri, 25 Oct 2013 16:53:52 +0000 (UTC)
+
+
Paul Tagliamonte dixit:
+
+>It may be, but it's not for the project. Let's let this bug be, and
+>have the tech cttie decide on *the* init system for Debian. If you want
+
+No, this must really really be decided first.
+
+bye,
+//mirabilos
+-- 
+<diogenese> Beware of ritual lest you forget the meaning behind it.
+<igli> yeah but it means if you really care about something, don't
+    ritualise it, or you will lose it. don't fetishise it, don't
+    obsess. or you'll forget why you love it in the first place.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 25 Oct 2013 17:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 25 Oct 2013 17:00:05 GMT) (full text, mbox, link).

+ +

Message #25 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: Thorsten Glaser <tg@mirbsd.de>
+
Cc: debian-devel@lists.debian.org
+
Subject: Re: tech-ctte: Decide which init system to default to in Debian.
+
Date: Fri, 25 Oct 2013 12:57:28 -0400
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Oct 25, 2013 at 04:53:52PM +0000, Thorsten Glaser wrote:
+> Paul Tagliamonte dixit:
+> 
+> >It may be, but it's not for the project. Let's let this bug be, and
+> >have the tech cttie decide on *the* init system for Debian. If you want
+> 
+> No, this must really really be decided first.
+
+Moving bug off CC. Please don't re-add it.
+
+Feel free to start a new thread. Let that thread and bug be.
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>
+: :'  : Proud Debian Developer
+`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+ `-     http://people.debian.org/~paultag
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 25 Oct 2013 18:33:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 25 Oct 2013 18:33:11 GMT) (full text, mbox, link).

+ +

Message #30 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: 727708@bugs.debian.org
+
Cc: Ondřej Surý <ondrej@sury.org>
+
Subject: Re: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)
+
Date: Fri, 25 Oct 2013 18:22:44 +0000 (UTC)
+
+
Ondřej Surý dixit:
+
+>then please submit your arguments directly there.
+
+Sure.
+
+>> Please stick to your side and make arguments for _your_ case, not
+
+My “case” here is to ask CTTE to not make any decision and defer
+to the Developers as whole, by means of a GR. As Guillem wrote:
+
+| stop doing work due to this. Also even if a majority of the project would
+| disagree with any such decision, subsequently overruling the tech-ctte by
+| way of a GR requires more than a simple majority. You know, GRs do not
+| eat babies or something.
+
+I think that is, at this point, the only sensible way forward,
+because the amount of people that would feel annoyed by a decision,
+any decision, made by anyone, at this point in time is just too
+large, and a GR is at least “by the people for the people”.
+
+>> That doesn't take away Thorsten's will to make a GR, but I would like to
+>> take the case to tech-ctte first.
+
+I’m willing to wait with the GR until CTTE decided (or decided
+to not decide), now that the process is started, but I’m not happy
+(especially as we lose time considering time-based freeze).
+
+bye,
+//mirabilos
+-- 
+16:47⎜«mika:#grml» .oO(mira ist einfach gut....)      23:22⎜«mikap:#grml»
+mirabilos: und dein bootloader ist geil :)    23:29⎜«mikap:#grml» und ich
+finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
+gleich mal auf usb-stick installieren	-- Michael Prokop über MirOS bsd4grml
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 25 Oct 2013 18:48:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 25 Oct 2013 18:48:12 GMT) (full text, mbox, link).

+ +

Message #35 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: submit@bugs.debian.org
+
Cc: debian-devel@lists.debian.org
+
Subject: Re: tech-ctte: Decide which init system to default to in Debian.
+
Date: Fri, 25 Oct 2013 14:43:44 -0400
+
+
[Message part 1 (text/plain, inline)]
+
And, since I've been informed that this was basically a contentless bug,
+I'd like to frame the technical half of the question better:
+
+
+Whereas:
+
+ * the init system / pid 1 is a bit of software that multiple packages provide
+
+ * the choice of init system also dictates which types of init scripts
+   package maintainers write and maintain
+
+ * the situation in which packages depend on a feature of systemd that's not
+   dependent on pid 1 being systemd (such as dbus shutdown, or using logind)
+   being run without systemd as pid1 is *not* something the systemd maintainers
+   will support (fairly) is getting *more* common, and has been introduced into
+   a major package (GNOME)
+
+It is requested that the tech-ctte make a decision as to the init system
+Debian shall use as the default, and make a judgement call on where the
+efforts to resolve this situation shall go (patching *around* the lack
+of systemd, or patching software to use systemd)
+
+I believe this is within the ctte's jurisdiction, given 6.1 section 2.
+
+
+Thanks for your consideration,
+   Paul
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>
+: :'  : Proud Debian Developer
+`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+ `-     http://people.debian.org/~paultag
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 25 Oct 2013 22:21:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 25 Oct 2013 22:21:07 GMT) (full text, mbox, link).

+ +

Message #40 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)
+
Date: Fri, 25 Oct 2013 22:18:16 +0000 (UTC)
+
+
Okay,
+
+and here’s the reasoning for “sticking to an antiquated” init system:
+
+I fully believe that Debian should be as flexible as possible
+when meeting users’ needs. There is already a big downstream
+running on Upstart, and I believe that, given the assumption
+that we need to decide on one/the init system, there is indeed
+market for another big Debian downstream that runs on systemd
+and offers GNOME after it has, by Neil’s suggestion (and, if
+we decide to only support one init and it’s not systemd, that
+*is* the logical outcome, *and* one I fully support), been
+removed from Debian. This will cause “the market” to work and
+make for some healthy competition, while accepting the goodies
+from both downstreams to flow back into Debian if they’re good
+enough (i.e. do not prevent sysvinit from working). This appears
+to work pretty well with Ubuntu already, with early hostilities
+(on both sides) having been overcome.
+
+I believe that sysvinit allows for the most flexibility for
+users and porters, and imposes the least on package maintainers
+unwilling to write init scripts for more than one system. Both
+newcomers support running packages from initscripts, whereas
+it’s their way or the highway for the respective native scripts,
+which may be added to Debian to be used by Debian users running
+a nōn-default configuration (meaning with upstart of systemd as
+init, which would presumably still be doable by users, but not
+by packages, leading to the GNOME removal), and, of course, by
+the aforementioned downstreams.
+
+There needs to be said that sysvinit is the one closest to Unix
+principles by not being as “integrative” (cf. modular), not
+insisting on its own, proprietary binary logging format, and
+other things. There may be a place for FLOS, but a Universal OS
+is not it.
+
+Additionally, sysvinit, at this point in time, is the only system
+working universally across Debian thanks to the Hurd GSoC by Justus
+Winter, whose Planet posts I read amazedly. I believe we should
+solidify its status in Debian, as diversity is a good thing, and
+the newcomers are not as portable (even if a GNU/kFreeBSD port of
+upstart was begone). Downstreams may want to limit their set of
+architectures for arbitrary reasons, so they would not have the
+same constraints of being universal.
+
+Finally, sysvinit is “the thing to expect” in the GNU/Linux
+world, despite attempts from two big and a very small number
+of smaller GNU/Linux vendors. Keep the principle of least
+surprise and accept that sysvinit is the most universal one,
+the one people coming from other GNU/Linux systems and even
+some Unicēs will know, expect, or at least (if they’ve been
+at Fedora before) know something about, and one which even
+BSD people can accept and understand. It’s widespread, and
+a good common denominator.
+
+So I believe that, if we need to choose a default right now,
+it must be sysvinit, and this must be a reliable outcome, i.e.
+we commit to this and don’t arbitrarily change our mind later.
+I believe that, should this question be forced first, GNOME
+needs to be removed from Debian and welcomed as a downstream.
+
+That being said, I would support upstart over systemd alone
+for the fact that it doesn’t appear to do such “land grabs”,
+is open for improvement (such as the kFreeBSD port) and not
+as hostile as some of the people behind systemd/GNOME have
+shown themselves to be, over and over again; I believe that
+the fact of it being mainly driven by a company is not a big
+problem (if needs be, fork it), especially as they have shown
+themselves capable of doing large-scale projects in a mostly
+technically sound manner, and be somewhat more consistent in
+the implementation, as opposed to the perceived “a big change
+every other week” of the other newcomer systemd.
+
+bye,
+//mirabilos
+-- 
+<ch> you introduced a merge commit        │<mika> % g rebase -i HEAD^^
+<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
+<ch> should have cloned into a clean repo      │  fault (core dumped)
+<ch> if I rebase that now, it's really ugh     │<mika:#grml> wuahhhhhh
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 26 Oct 2013 09:09:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Lucas Nussbaum <leader@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 26 Oct 2013 09:09:09 GMT) (full text, mbox, link).

+ +

Message #45 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Lucas Nussbaum <leader@debian.org>
+
To: Paul Tagliamonte <paultag@debian.org>, 727708@bugs.debian.org
+
Cc: debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Sat, 26 Oct 2013 11:07:36 +0200
+
+
[Message part 1 (text/plain, inline)]
+
On 25/10/13 at 12:16 -0400, Paul Tagliamonte wrote:
+> In response to the recent threads, I'd like to ask the tech-ctte to
+> please vote on and decide on the default init system for Debian.
+
+I agree. I don't think that many substantial new arguments are going to
+be brought by waiting more on this topic. And it is clear that we have
+reached a point where not having clear guidance is severely hurting the
+project.
+
+On 25/10/13 at 16:40 +0000, Thorsten Glaser wrote:
+> I’d still say, let’s just GR about it. Prepare one now, then
+> have some time to cool down before the vote period.
+
+I think that it would be a failure of the Debian project if we had to have a GR
+about such a technical decision. I think that we need to trust that the
+Technical Committee will make the right decision. A GR about this will likely
+result in splitting and hurting the project even more.
+
+On 25/10/13 at 14:43 -0400, Paul Tagliamonte wrote:
+> And, since I've been informed that this was basically a contentless bug,
+> I'd like to frame the technical half of the question better:
+> 
+> 
+> Whereas:
+> 
+>  * the init system / pid 1 is a bit of software that multiple packages provide
+> 
+>  * the choice of init system also dictates which types of init scripts
+>    package maintainers write and maintain
+> 
+>  * the situation in which packages depend on a feature of systemd that's not
+>    dependent on pid 1 being systemd (such as dbus shutdown, or using logind)
+>    being run without systemd as pid1 is *not* something the systemd maintainers
+>    will support (fairly) is getting *more* common, and has been introduced into
+>    a major package (GNOME)
+> 
+> It is requested that the tech-ctte make a decision as to the init system
+> Debian shall use as the default, and make a judgement call on where the
+> efforts to resolve this situation shall go (patching *around* the lack
+> of systemd, or patching software to use systemd)
+> 
+> I believe this is within the ctte's jurisdiction, given 6.1 section 2.
+
+I think that there are two different questions:
+1) Could you clarify which init system(s) must be supported by packages
+   involved during system startup (daemons, etc.) and low-level services?
+   
+   [ the answer to that question would likely result into a update of
+     the Debian Policy, section 9.3 and 9.11 ]
+
+   [ Note that most daemons will likely still have to support sysvinit
+     in jessie, in order to handle partial upgrades. ]
+
+2) sysvinit is currently "Essential: yes", which causes it to be
+   installed by default by the installer. Should sysvinit stay
+   Essential? If not, should another init system be Essential?
+   If not, how should this be addressed in the debian installer?
+
+Lucas
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 26 Oct 2013 17:21:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 26 Oct 2013 17:21:08 GMT) (full text, mbox, link).

+ +

Message #50 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org
+
Cc: Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Sat, 26 Oct 2013 10:17:03 -0700
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Oct 26, 2013 at 11:07:36AM +0200, Lucas Nussbaum wrote:
+> I think that there are two different questions:
+> 1) Could you clarify which init system(s) must be supported by packages
+>    involved during system startup (daemons, etc.) and low-level services?
+    
+>    [ the answer to that question would likely result into a update of
+>      the Debian Policy, section 9.3 and 9.11 ]
+
+>    [ Note that most daemons will likely still have to support sysvinit
+>      in jessie, in order to handle partial upgrades. ]
+
+> 2) sysvinit is currently "Essential: yes", which causes it to be
+>    installed by default by the installer. Should sysvinit stay
+>    Essential? If not, should another init system be Essential?
+>    If not, how should this be addressed in the debian installer?
+
+I don't think either of these are the right question.  Even if we change
+the default init system for jessie, because we *must* support backwards
+compatibility with sysvinit for upgrades, there is no justification for
+requiring packages to do anything else for jessie and no policy change is
+needed.
+
+Likewise, the Essential: yes bit on the sysvinit package will be in effect
+for a full release cycle regardless of what init system we choose, so it
+needs to become a metapackage that depends on an ORed list of possible
+implementations in order for us to make any change in jessie.
+
+The real question before the TC is simply: what should the default init
+system be for jessie?  The rest are technical details that can be
+straightforwardly worked out once we have a decision on the direction.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 26 Oct 2013 17:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 26 Oct 2013 17:51:04 GMT) (full text, mbox, link).

+ +

Message #55 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Lucas Nussbaum <leader@debian.org>
+
Cc: 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Sat, 26 Oct 2013 10:46:38 -0700
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> I don't think either of these are the right question.  Even if we change
+> the default init system for jessie, because we *must* support backwards
+> compatibility with sysvinit for upgrades, there is no justification for
+> requiring packages to do anything else for jessie and no policy change
+> is needed.
+
+That isn't obvious to me.  We have, in the past, allowed upgrades to
+require a preliminary upgrade of one or more packages.  The udev
+transition comes to mind.  We *could* do the same thing here and require
+an init upgrade as a pre-upgrade step when going from wheezy to jessie,
+alongside a dependency on systemd or upstart (added by debhelper, for
+example) for all packages providing startup configuration but not an init
+script.  I'm not saying that's necessarily a good option, but it is an
+option that we should discuss.
+
+Also, we will eventually have to decide whether to drop the requirement
+that packages provide sysvinit-compatible init scripts.  Even if we agree
+on a requirement to do so for jessie, we could drop that requirement for
+jessie+1 (and indeed will want to if we choose any init system other than
+sysvinit or "all of the above," given that most of the benefits of either
+upstart or systemd from a packaging perspective will only be seen when we
+take that step).
+
+We could always defer that decision until jessie+1, but that's the
+decision with the most impact on kFreeBSD and Hurd, and if I were them,
+I'd want to know whether that's the eventual project direction or not as
+soon as possible so that I have as much time as possible to decide on my
+next steps.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 26 Oct 2013 18:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 26 Oct 2013 18:21:04 GMT) (full text, mbox, link).

+ +

Message #60 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, + Paul Tagliamonte <paultag@debian.org>, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Sat, 26 Oct 2013 11:20:21 -0700
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Oct 26, 2013 at 10:46:38AM -0700, Russ Allbery wrote:
+> Steve Langasek <vorlon@debian.org> writes:
+
+> > I don't think either of these are the right question.  Even if we change
+> > the default init system for jessie, because we *must* support backwards
+> > compatibility with sysvinit for upgrades, there is no justification for
+> > requiring packages to do anything else for jessie and no policy change
+> > is needed.
+
+> That isn't obvious to me.  We have, in the past, allowed upgrades to
+> require a preliminary upgrade of one or more packages.  The udev
+> transition comes to mind.
+
+udev transitions have always happened under duress.  We should do better
+than this where we reasonably can.  (In the udev case, we had no choice but
+to require a risky lockstep upgrade of the kernel and udev, because
+maintaining udev compatibility with older kernels would have required an
+excessive amount of new work.)
+
+>  We *could* do the same thing here and require an init upgrade as a
+> pre-upgrade step when going from wheezy to jessie, alongside a dependency
+> on systemd or upstart (added by debhelper, for example) for all packages
+> providing startup configuration but not an init script.  I'm not saying
+> that's necessarily a good option, but it is an option that we should
+> discuss.
+
+Ok, point taken.  We *could* decide that something other than sysvinit was
+now the new least common denominator for jessie, and using dependencies
+ensure a smooth upgrade (i.e., this still wouldn't be the udev problem).  I
+think that would be a surprisingly bold change for Debian to make in the
+space of a single release cycle, when up to now we collectively have very
+little experience running either systemd or upstart in production on Debian,
+and we don't as yet have a resolution for compatibility with non-Linux
+ports.
+
+> Also, we will eventually have to decide whether to drop the requirement
+> that packages provide sysvinit-compatible init scripts.  Even if we agree
+> on a requirement to do so for jessie, we could drop that requirement for
+> jessie+1 (and indeed will want to if we choose any init system other than
+> sysvinit or "all of the above," given that most of the benefits of either
+> upstart or systemd from a packaging perspective will only be seen when we
+> take that step).
+
+> We could always defer that decision until jessie+1, but that's the
+> decision with the most impact on kFreeBSD and Hurd, and if I were them,
+> I'd want to know whether that's the eventual project direction or not as
+> soon as possible so that I have as much time as possible to decide on my
+> next steps.
+
+Right.  Whichever init system we pick, I do expect the next step to be to
+drop the requirement to maintain sysvinit backwards-compatibility; my point
+was that I don't expect this to be something we change in policy for this
+cycle as part of the TC decision.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 26 Oct 2013 18:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thomas Goirand <zigo@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 26 Oct 2013 18:51:04 GMT) (full text, mbox, link).

+ +

Message #65 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thomas Goirand <zigo@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Sun, 27 Oct 2013 02:47:56 +0800
+
+
-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA256
+
+Hi there!
+
+I've been asked to write about OpenRC here. I'm a bit reluctant to do
+it, but feel that it's my duty as I've been mentoring the OpenRC GSoC
+project this summer.
+
+Well, it's been a month the OpenRC package is waiting in the FTP NEW
+queue (after a successful GSoC project), so it's a bit silly to tell
+about something which isn't even in Debian yet... Though if anyone wants
+to test it, it's in /git/collab-maint/openrc.git on Alioth.
+
+Anyway, the main point of OpenRC, IMO, is that it can work on non-linux
+platforms. But at this point, it is hard to make a case for it, since
+the porting work (well, I should rather say the no-FTBFS work... as it
+should be only a mater of configuring the build environment) hasn't been
+done yet. :(
+
+Note that OpenRC already works on some (non-Debian) BSD platforms, and
+that it should be trivial to have it to build on kFreeBSD and Hurd,
+though I didn't (and probably wont in the next few weeks/months, due to
+professional duties and personal events) have time to work on this.
+Though when this is done, OpenRC will be a drop-in replacement, with
+normally very little trouble to take care of. I of course welcome anyone
+to work on these ports.
+
+With a bit more goodies than with sysv-rc (for example, cgroups support
+for the platforms who supports it), OpenRC can be seen as an evolution
+of it, with more features.
+
+As for my own opinion on #727708, I'd like the tech committee to decide
+we *must* continue to support something that works on kFreeBSD and Hurd
+(either sysv-rc, or OpenRC when it's fully working on all arch) as a
+requirement in the Debian policy, at least if we don't have an upstart
+working port for Hurd / kFreeBSD (if this ever happens).
+
+It is to be noted that it's Systemd upstream opinion as well that Debian
+has no choice but to support something else than Systemd (sysv-rc,
+OpenRC,...) scripts for platforms which wont ever be supported by
+Systemd (I discussed about that with Lennart during Debconf).
+
+Even if there's no such a decision from the tech-ctte, some ways of
+starting daemons must be done for the non-linux Debian archs. And OpenRC
+could be adopted for them (in the absence of Upstart / Systemd), to
+simplify writing of these init scripts and bring more features. So,
+whatever the tech-ctte decides, OpenRC, in my opinion, makes sense! :)
+
+I also would like to wish good luck to the tech-ctte. Whatever you will
+decide, I will support it. I wouldn't like to be in your seats, and I
+hope everyone will also support your final decision.
+
+Hoping that the work on OpenRC will be useful for Debian,
+Cheers,
+
+Thomas Goirand (zigo)
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.12 (GNU/Linux)
+Comment: Using GnuPG with Icedove - http://www.enigmail.net/
+
+iQIcBAEBCAAGBQJSbA5ZAAoJENQWrRWsa0P+YYUP/37zqCtcornktT3xb7LKC4w7
+ZdDig/g6cGW1JbL90q/6OPSN0CDUiVcF66HkP5RXk6jUG9CBm5OMmkz2+VX3THLR
+Vhnyd/t5dQiyBLGgSO9YI4I9DizppasYjRpqsK7O3bI7cfmGgg8xyBk6CL3Kblvm
+D7+jvRbBwdt+HqJccHsM4+n3mUgJFLOajVwU2E8Mp7TFY3bRwIyXWDPsE+7q0Jxi
+1F1sS/bBxtaBOlj3tEAMRxLHH74bwKiT5VTo114ygQTu8ylsZ8hSCnNuDFSAm7mk
+0TL28xaD1bA7VN2VwYd41J/KIWHel+0In5fG7FOIX1DGf543Fyei+CfpaINAHS+7
+Yt8X2C/EFJr/4dERXTrxhxSN9T0B8fRvXwe1I6KEvcoyzIsEKjJO/yJxmr8NNrVA
+w5Qp/jjLfrL82HlUIdvva4OonFCHGIVZkP+KFjTYMnKUJ9mlOnqCIF7m+cfH7ZkR
+RFfodY3eWAiVY+Nq2SJ0EB9R+cslxXovotNvmMZQvagLIhlLC+qXMGTkV6VvXHbF
+B0nVT6qCGmuDHQSUBCCeGy7nEKU1ObRcyfW3YJ0tiXmOTBuCBltHJpOiV4OwBcMK
+7b20W8AtAyTbdtheksoUS4TSg25LOAQfeP0Gk0AVDV7nDDGLDVcCJ6L84JBjcu03
+5wvRVoh1K0uf/pC/jWM9
+=E/op
+-----END PGP SIGNATURE-----
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 27 Oct 2013 12:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Arno Töll <arno@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 27 Oct 2013 12:18:04 GMT) (full text, mbox, link).

+ +

Message #70 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Arno Töll <arno@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: RE: tech-ctte: Decide which init system to default to in Debian.
+
Date: Sun, 27 Oct 2013 13:06:03 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Hi,
+
+apart of the arguments raised by others, I'd like to point out three
+more things:
+
+- If we'd be inclined to switch the init system to something different
+to sysvinit, let's start rather soon than later. Starting with today we
+have one year until we expect to freeze which sounds like a lot, but
+it's not if you take in mind that (up to) 1200 packages [1] need to be
+adapted to this change, some in a non-trivial way. I guess any
+alternative being discussed here is able to provide some fall-back
+mechanism in case it's really needed, but if we rely on that, I don't
+see a reason to switch in the first place. Thus, I'd appreciate if the
+TC decides on that case rather soon than later since I'm one of these
+persons who maintains several not-trivial init scripts.
+
+- Please bear in mind that supporting more than one init script type is
+not feasible or doable. Especially for non-trivial scripts [2][3]
+maintaining an init script is a substantial piece of work, and I claim,
+that we could spend our time in better ways than maintaining three
+pieces of code (or, as for me, meta-language description files) which
+all need to be tested, fixed and updated every once in a while. I guess,
+I could deal with that burden once for Jessie, but please don't get us
+into that as a long term solution.
+
+- Whatever you decide, please do also turn your attention to the outside
+world apart of Debian. This discussion was raised (well, this time),
+because Gnome started to depend transitionally on systemd. Whether we
+like it or not, but we're not the center of the universe. There are
+distributions, and very important pieces of software outside the control
+Debian and the TC that have (biased) points of view conflicting with
+Debian's on this matter. Thus, I suspect that we are not going to
+succeed with an isolated island solution, which does not care about the
+ways other distributions move - especially since the init system choice
+seems to be heavily tied to the choice of the desktop these days.
+Whether it's systemd or upstart, both have major players standing behind
+its respective technologies, each with substantial financial resources
+to drive development of these platforms in a direction where Debian with
+an isolated solution cannot compete with, due to its community driven
+organizational structure.
+
+
+[1] $ apt-file search /etc/init.d | wc -l
+1194
+[2]
+http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/apache2.init;h=f5977abd302115e1517110fc2e00ca0cd2054afd;hb=HEAD
+[3]
+http://anonscm.debian.org/gitweb/?p=users/wouter/nbd.git;a=blob;f=debian/nbd-client.init.d;h=23994dd93b315533ee43bbb961b21aa40ff25c00;hb=HEAD
+
+-- 
+with kind regards,
+Arno Töll
+IRC: daemonkeeper on Freenode/OFTC
+GnuPG Key-ID: 0x9D80F36D
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 28 Oct 2013 09:39:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 28 Oct 2013 09:39:09 GMT) (full text, mbox, link).

+ +

Message #75 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Init systems: arguments for the CTTE
+
Date: Mon, 28 Oct 2013 10:36:48 +0100
+
+
Hi,
+
+since this is the time to submit arguments before the CTTE can discuss
+things internally and hopefully reach a decision, I’d like to say a few
+words.
+
+It won’t be a surprise if I say systemd should be the default init
+systems for the Linux architectures for jessie and, unless another
+solution arises, the only supported option for jessie+1.
+
+I say this as a systems engineer, because systemd is great software. I’m
+not going to list all systemd features, but there are many of them I
+want to see on my production servers. In addition, the command-line
+interface is awesome, and the unit file description is straightforward.
+
+I say this as a package maintainer, too. Systemd is becoming a de facto
+standard in Linux distributions (at least Fedora, SuSE and Arch), and is
+getting excellent upstream support in many packages. So far, only Gentoo
+uses OpenRC (and it doesn’t have most of the features I’d like to have),
+and only Ubuntu uses Upstart. Therefore using OpenRC would mean
+maintaining many patches on our own, and using Upstart would mean that
+our upstream would become Ubuntu.
+
+        As a side note, I think upstart’s CLA dismisses it as software
+        of choice for our core system. 
+        I know it’s not the only important piece of software in Debian
+        with a CLA. I still stand on this point. I have experienced a
+        real world CUPS nightmare because of Apple’s CLA, and I would be
+        all for ditching CUPS as default too if we had a decent
+        alternative.
+
+Finally, I say this as one of the GNOME packages’ maintainers. GNOME in
+jessie will need systemd as the init system to work with all its
+features, just like it needs the network configuration to be handled by
+NetworkManager. While it is (and can remain) possible, just like in the
+NM case, to install it without systemd and lose functionality, I think
+it is unreasonable to ask for a default GNOME installation without it.
+
+Some people have argued this functionality can be reimplemented on top
+of Upstart or OpenRC. These people should be ready to show the code and
+to commit on maintaining it in the long term before it can be considered
+as a possible alternative.
+
+Finally, a word about kFreeBSD. I know systemd and upstart have not been
+ported to kFreeBSD (and despite claims that upstart developers would
+accept patches, so far they don’t exist). However, we are talking about
+a major feature leap for Linux, and having kFreeBSD interfere in the
+decision would be unfair to Linux users. 
+
+My gut feeling is that, despite the original enthusiasm I shared,
+kFreeBSD was branded a release architecture too soon, or at least for a
+too broad set of packages. Most packages have never been tested on
+non-linux, and a large portion of those does not work. A possible
+approach would be to restrict these architectures to a defined set of
+packages and maintain OpenRC or insserv scripts for these packages. In
+all cases, this should be worked on after reaching a decision for the
+Linux init system.
+
+Thanks for reading,
+-- 
+ .''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 28 Oct 2013 12:18:16 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 28 Oct 2013 12:18:16 GMT) (full text, mbox, link).

+ +

Message #80 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Tollef Fog Heen <tfheen@debian.org>, + Michael Biebl <biebl@debian.org>, + Marco d'Itri <md@linux.it>, + Thomas Goirand <zigo@debian.org>, + Steve Langasek <vorlon@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: init system question before the technical committee
+
Date: Mon, 28 Oct 2013 12:04:58 +0000
+
+
Steve Langasek writes[1]:
+> For my part, I think the suggestion that Russ and Lars made a while ago to
+> maintain position statements in the Debian wiki is a good one, and I would
+> encourage you to make use of this structure so that you can lay out your
+> arguments in a way that doesn't require you to repeat yourselves endlessly
+> in a mail thread.  The wiki is just waiting for someone to create the
+> content:
+> 
+>   https://wiki.debian.org/Debate/initsystem/systemd
+
+I would like very much to second this.  This discussion is going to
+become unmanageable if we try to have it in the bug report and it will
+be difficult to get any kind of overview.
+
+I have been skimreading the messages from both sides here in the bug,
+but I can't guarantee to give proper consideration to all of the
+things which are said.
+
+In summary: I, at least, intend to base my decision on how to vote
+primarily on the information provided in the Debate wiki pages.
+
+
+So I would appreciate it if you (and by "you" I mean each side of the
+argument) would make sure that your page represents the best case you
+can put forward.
+
+In particular, I think for the systemd and OpenRC camps the first step
+would be to set out who the maintainers are of the position
+statement.  And then the points made in the emails need to be
+transferred into the wiki and perhaps merged.
+
+I'm expecting that the upstart camp will then want to add some
+text to the section "Rebuttals" of their page.
+
+For the avoidance of any doubt: only the listed position statement
+maintainers should edit the page for a particular camp; with the
+exception that if you agree with the thrust of the position statement
+you may add something to "Comments" for the maintainer's
+consideration.
+
+Maintainers, please make sure you subscribe to updates the page for
+your camp, so that you can spot any edits which don't confirm to this
+rule.
+
+
+Finally: we need this conversation to stay constructive and pleasant.
+If anyone receives any rude, unprofessional or insulting messages (in
+any medium) on this matter, please let one of the TC know.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 28 Oct 2013 17:27:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Wouter Verhelst <wouter@master.debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 28 Oct 2013 17:27:13 GMT) (full text, mbox, link).

+ +

Message #85 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Wouter Verhelst <wouter@master.debian.org>
+
To: Russ Allbery <rra@debian.org>, Lucas Nussbaum <leader@debian.org>, + 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Mon, 28 Oct 2013 17:22:14 +0000
+
+
On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
+> Right.  Whichever init system we pick, I do expect the next step to be to
+> drop the requirement to maintain sysvinit backwards-compatibility;
+
+While I'm not sure from your mail whether you meant to suggest otherwise, I do
+think that whatever we decide for jessie, we should continue the requirement of
+sysvinit compatibility for at least one release after we ship with some more
+modern init system.
+
+Also, since all alternative init implementations under consideration do
+support sysv-style init scripts, I think that whatever init system we
+(well, you, the TC) end up choosing, the requirement in policy should be
+that a package should ship either some init configuration for the
+default init system, or a sysv-style init script. In fact, I think we
+should continue to encourage the latter, in cases where it does make
+sense (e.g., when a given daemon doesn't have any init system specific
+features that could be enabled), since that will help our non-Linux
+ports without significantly impacting performance of the new init
+system.
+
+-- 
+This end should point toward the ground if you want to go to space.
+
+If it starts pointing toward space you are having a bad problem and you
+will not go to space today.
+
+  -- http://xkcd.com/1133/
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 28 Oct 2013 17:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Alexander Wirt <formorer@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 28 Oct 2013 17:45:04 GMT) (full text, mbox, link).

+ +

Message #90 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Alexander Wirt <formorer@debian.org>
+
To: Wouter Verhelst <wouter@master.debian.org>
+
Cc: Russ Allbery <rra@debian.org>, Lucas Nussbaum <leader@debian.org>, + 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Mon, 28 Oct 2013 18:40:46 +0100
+
+
Wouter Verhelst schrieb am Monday, den 28. October 2013:
+
+> On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
+> > Right.  Whichever init system we pick, I do expect the next step to be to
+> > drop the requirement to maintain sysvinit backwards-compatibility;
+> 
+> While I'm not sure from your mail whether you meant to suggest otherwise, I do
+> think that whatever we decide for jessie, we should continue the requirement of
+> sysvinit compatibility for at least one release after we ship with some more
+> modern init system.
+> 
+> Also, since all alternative init implementations under consideration do
+> support sysv-style init scripts, I think that whatever init system we
+> (well, you, the TC) end up choosing, the requirement in policy should be
+> that a package should ship either some init configuration for the
+> default init system, or a sysv-style init script. In fact, I think we
+> should continue to encourage the latter, in cases where it does make
+> sense (e.g., when a given daemon doesn't have any init system specific
+> features that could be enabled), since that will help our non-Linux
+> ports without significantly impacting performance of the new init
+> system.
+It will also make backporting much easier.
+
+Alex
+ 
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 28 Oct 2013 17:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 28 Oct 2013 17:51:04 GMT) (full text, mbox, link).

+ +

Message #95 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init systems: arguments for the CTTE
+
Date: Mon, 28 Oct 2013 11:47:52 -0600
+
+
[Message part 1 (text/plain, inline)]
+
Josselin Mouette <joss@debian.org> writes:
+
+> While it is (and can remain) possible, just like in the
+> NM case, to install it without systemd and lose functionality, I think
+> it is unreasonable to ask for a default GNOME installation without it.
+
+Thanks for making this clear.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 28 Oct 2013 18:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Stapelberg <stapelberg@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 28 Oct 2013 18:36:04 GMT) (full text, mbox, link).

+ +

Message #100 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Stapelberg <stapelberg@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: FYI: upstream’s take
+
Date: Mon, 28 Oct 2013 19:34:38 +0100
+
+
Hi,
+
+my apologies for not replying to any messages within the thread, but I
+think my mail is orthogonal to the other messages.
+
+Lennart Poettering wrote about the systemd upstream point of view on the
+discussion we are currently having:
+https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf
+
+I’d like to specifically stress this part:
+> And yeah, we, upstream, are of course open to answer any questions you
+> might have.
+
+So, please feel encouraged to explicitly ask upstream about any points
+that you feel are important and/or unclear.
+
+Also, it shouldn’t need saying, but let’s be sure: the same goes for
+pkg-systemd-maintainers within Debian. If you have any questions, please
+talk to us. You can reach us via
+pkg-systemd-maintainers@lists.alioth.debian.org, and feel free to CC me
+specifically.
+
+-- 
+Best regards,
+Michael
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 28 Oct 2013 19:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Christoph Anton Mitterer <calestyo@scientia.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 28 Oct 2013 19:18:04 GMT) (full text, mbox, link).

+ +

Message #105 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Christoph Anton Mitterer <calestyo@scientia.net>
+
To: 727708@bugs.debian.org, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Mon, 28 Oct 2013 20:14:04 +0100
+
+
[Message part 1 (text/plain, inline)]
+
For those who haven't seen it, Lennart has posted some of his comments
+about all this on G+:
+https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf
+
+
+Cheers,
+Chris.
+
+
[smime.p7s (application/x-pkcs7-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 00:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 00:48:04 GMT) (full text, mbox, link).

+ +

Message #110 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Tue, 29 Oct 2013 00:45:53 +0000
+
+
[Message part 1 (text/plain, inline)]
+
Hi!
+
+Please may I suggest another option for consideration:  a commitment to
+support two chosen init systems.
+
+On mainstream ports (Linux amd64, i386) where two init systems are
+available, a package should be tested and made to work reasonably well
+on both.  Any port would have at least one of these init systems.  This
+offers users a choice to avoid a particular init system, try the new
+features in another one, or perhaps stay with what they already have.
+
+It would require work, but maybe this turns argument into something that
+can be accomplished through team effort.  Supposing systemd and sysvinit
+were chosen:
+* systemd folks would aim to make best use of the existing sysvinit
+scripts, and provide help to packages where improvement can be made;
+* sysvinit users and porters can help ensure things keep working there.
+
+I've begun a debate page here, more suggestions are welcome:
+https://wiki.debian.org/debate/initsystem/multiple
+or follow up on debian-devel@
+
+Thanks!
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 01:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Christoph Anton Mitterer <calestyo@scientia.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 01:18:04 GMT) (full text, mbox, link).

+ +

Message #115 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Christoph Anton Mitterer <calestyo@scientia.net>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Tue, 29 Oct 2013 02:16:14 +0100
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, 2013-10-29 at 00:45 +0000, Steven Chamberlain wrote:
+> a commitment to
+> support two chosen init systems.
+The question is.... would supporting two be enough to give a
+considerable benefit?
+
+I guess the competition will be mostly between: systemd vs. upstart.
+And not between sysvinit, anything else vs. systemd or upstart.
+
+sysvinit is simply too old and lacks many modern features.
+With anything-else, Debian would be more or less completely alone since
+all world (except *buntu) seems to settle on systemd.
+So from that POV, I'd even say upstart is already an island solution.
+Look at most core daemons and systems/technologies (read about CUPS and
+Wayland just a few days ago) - their upstreams seem to focus on systemd.
+
+
+So when Debian really supports two init systems... what could that be?
+Either
+
+a) systemd AND upstart
+I guess that would largely be a political benefit, since then the two
+major fractions are happy.
+
+b) (EITHER systemd OR upstart) AND sysvinit
+That could have a real technical benefit, with respect to !Linux
+flavours- since then we'd have systemd|upstart for Linux and sysvinit
+for !Linux.
+At least systemd does not support !Linux... and I guess it's the same
+for upstart(??).
+
+But then we'd have again the political problem of systemd vs. upstart,
+since only one could win.
+
+
+So *if* supporting multiple init-systems, and by supporting I mean, that
+every package must support _at least_ those, then supporting 3(!) seems
+to make more sense: sysvinit, systemd and upstart.
+
+I generally hope, that the tech-ctte will not *forbid* the use of any
+other init system, but just rule about a _minimum_ set of initsystems
+(or one) that MUST be supported.
+
+
+Cheers,
+Chris.
+
+
[smime.p7s (application/x-pkcs7-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 01:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 01:24:05 GMT) (full text, mbox, link).

+ +

Message #120 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Wouter Verhelst <wouter@master.debian.org>
+
Cc: Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Mon, 28 Oct 2013 18:21:27 -0700
+
+
Wouter Verhelst <wouter@master.debian.org> writes:
+
+> Also, since all alternative init implementations under consideration do
+> support sysv-style init scripts, I think that whatever init system we
+> (well, you, the TC) end up choosing, the requirement in policy should be
+> that a package should ship either some init configuration for the
+> default init system, or a sysv-style init script. In fact, I think we
+> should continue to encourage the latter, in cases where it does make
+> sense (e.g., when a given daemon doesn't have any init system specific
+> features that could be enabled), since that will help our non-Linux
+> ports without significantly impacting performance of the new init
+> system.
+
+Well, I've said this before, but I think it's worth reiterating.  Either
+upstart or systemd configurations are *radically better* than init scripts
+on basically every axis.  They're more robust, more maintainable, easier
+for the local administrator to fix and revise, better on package upgrades,
+support new capabilities, etc.
+
+I believe that much of the benefit for adopting a new init system is
+dropping init scripts and using a much better configuration language.  If
+we're not going to take advantage of that benefit, it calls into question
+whether we should change init systems at all.
+
+In other words, I don't think it would make any sense at all to
+standardize on upstart or systemd and then ask people to continue to write
+init scripts in the long run (transition issues aside).  Getting rid of
+init scripts is not the whole point, but it's a huge part of it.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 01:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Peter Dolding <oiaohm@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 01:27:04 GMT) (full text, mbox, link).

+ +

Message #125 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Peter Dolding <oiaohm@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: tech-ctte: Decide which init system to default to in Debian.
+
Date: Tue, 29 Oct 2013 11:23:58 +1000
+
+
Anyone suggesting staying with sysvinit should be shot at down for
+foolishness   If you wish to stay something sysvinit like you should
+be backing OpenRC.
+
+The basic issue with sysvinit is lack of process tracking.
+
+This is the historic problem.
+
+You start a service.
+You stop a service.
+Ok everything is fine.
+
+You go to start service again.  Hello some random process is still
+running so preventing the service starting because the service did not
+stop properly.
+
+Systemd and OpenRC both can address this using cgroups under Linux.
+OpenRC also can use Jails under BSD line.
+
+Upstart might be simpler to port but it does not address this base
+problem at all.
+
+The dbus issue is going to get major on all platforms.   This is
+another http://www.freedesktop.org/wiki/Software/hal/ item.   Hal was
+implemented in userspace and its functionality it has been replaced by
+devicekit.  Same with the recent termination of userspace X11 drivers.
+
+kdbus changes things major way.    Both upstart and openrc are well behind.
+
+The big risk is after kdbus is in the Linux kernel items like kernel
+power management move straight connected to it.   So there may be no
+option bar use kdbus while running on the Linux kernel.
+
+Debian has big trouble ahead.   No point putting head in sand.   The
+Multi OS debian is means there is a lot of critical work that must
+start straight now.   Like will kdbus be a feature we should expect
+from all kernels debian supports?
+
+Cgroups from Linux and  Solaris Containers from Solaris operate close
+enough to make porting systemd possible.   The major road block to
+systemd on freebsd kernel is nothing really like cgroups or Solaris
+Containers.
+
+Yes I know this would upset the freebsd guys no end but at this point
+we do have to serously consider if the freebsd branch is even worth
+keeping it is too alien to Linux.
+
+Working with www.openindiana.org to bring on something that can be
+systemd compatible as second kernel might be the correct way forward.
+ Maybe then freebsd kernel developers would see the need to provide
+Container class features in their OS kernel.
+
+http://www.oracle.com/technetwork/articles/servers-storage-admin/intro-smf-basics-s11-1729181.html
+Service Management Facility of Solaris and systemd of Linux have a lot
+in common how they operate.   This is why porting systemd to Solaris
+is not too bad.  cgroup functionality can be directly swapped with
+Solaris Containers functionality.   Cgroups was not a magical new idea
+that the Linux world dreamed up.   Someone had been look at Solaris
+and liked what they saw.
+
+This is really the choice do we keep on attempting to make
+incompatible designed kernels interchange or do we move to kernels
+with similar operating designs.
+
+Yes we can still maintain the multi OS going forwards.   But we are to
+the fork in the road.
+
+Debian cannot support everything.    The project has to be willing to
+spill blood at times.   I know killing kfreebsd branch completely is a
+lot of blood shed.  But if that allows redirecting those resources to
+a more compatible kernel so be it.
+
+The big answer we need from freebsd kernel developers are they going
+to implement functionality to match cgroup and solaris containers.
+If not going forwards compatibility with them is going to become
+harder and harder to maintain.
+
+https://people.gnome.org/~alexl/glick2/  something people forget
+container/cgroup class tech enable relocatable installation of
+programs without the program seeing it.  Containers is something that
+could be used in future to make multi-arch cleaner.   Like allowing
+32bit and 64bit development files and applications to be installed
+side by side without issues.  Like being able to install 32bit and
+64bit ice-weasel at the same time.
+
+The road block coming from freebsd is blocking systemd is also
+blocking debian from using the same features to address other problems
+as status normal.  Solaris kernel and Linux kernel could have
+identical instructions given to developer to build packages due to the
+existence of container tech in both.
+
+Sorry everyone is hard choice time.
+Do we go forwards having to work around the limited functionality of freebsd?
+Do we nuke freebsd and move on to another kernel more compatible?
+Do we pressure freebsd kernel developers to add containers?
+
+Yes most people are missing the major road block to systemd on freebsd
+is road blocking a solutions to stacks of other problems.   So really
+this is more than a init system problem.   The fact systemd is not
+portable to freebsd is showing missing features.   So far no one other
+me has went out and looked at the other kernels to see if the bsd line
+is a edge.   This case they are an outer edge.
+
+Peter Dolding
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 02:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 02:15:04 GMT) (full text, mbox, link).

+ +

Message #130 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: FYI: upstream’s take
+
Date: Mon, 28 Oct 2013 19:12:13 -0700
+
+
Michael Stapelberg <stapelberg@debian.org> writes:
+
+> my apologies for not replying to any messages within the thread, but I
+> think my mail is orthogonal to the other messages.
+
+> Lennart Poettering wrote about the systemd upstream point of view on the
+> discussion we are currently having:
+> https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf
+
+This is a valuable post.  Thank you for the pointer!  I would be
+interested in seeing the two core technical arguments there (cgroup
+handling and how D-Bus services are handled) addressed by the upstart
+position paper, particularly if there are plans that Lennart isn't aware
+of for how that functionality will be provided.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 08:21:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Lucas Nussbaum <lucas@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 08:21:10 GMT) (full text, mbox, link).

+ +

Message #135 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Lucas Nussbaum <lucas@debian.org>
+
To: 727708@bugs.debian.org
+
Cc: debian-devel@lists.debian.org, Helmut Grohne <helmut@subdivi.de>
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Tue, 29 Oct 2013 09:20:10 +0100
+
+
On 28/10/13 at 18:21 -0700, Russ Allbery wrote:
+> Wouter Verhelst <wouter@master.debian.org> writes:
+> 
+> > Also, since all alternative init implementations under consideration do
+> > support sysv-style init scripts, I think that whatever init system we
+> > (well, you, the TC) end up choosing, the requirement in policy should be
+> > that a package should ship either some init configuration for the
+> > default init system, or a sysv-style init script. In fact, I think we
+> > should continue to encourage the latter, in cases where it does make
+> > sense (e.g., when a given daemon doesn't have any init system specific
+> > features that could be enabled), since that will help our non-Linux
+> > ports without significantly impacting performance of the new init
+> > system.
+> 
+> Well, I've said this before, but I think it's worth reiterating.  Either
+> upstart or systemd configurations are *radically better* than init scripts
+> on basically every axis.  They're more robust, more maintainable, easier
+> for the local administrator to fix and revise, better on package upgrades,
+> support new capabilities, etc.
+> 
+> I believe that much of the benefit for adopting a new init system is
+> dropping init scripts and using a much better configuration language.  If
+> we're not going to take advantage of that benefit, it calls into question
+> whether we should change init systems at all.
+
+Note that there are two options that could be explored, to remove the
+need to maintain init scripts:
+- generating sysvinit scripts from systemd service files or upstart job
+  files at build time (this was explored, for systemd service files,
+  during a GSoC project in 2012, without much success)
+- having a .service/job files runtime interpreter (that sounds quite
+  promising)
+
+Even if it cannot be used for all services, using such as interpreter
+could maybe provide an easy support path for sysvinit on non-linux
+platforms for a large number of "simple" services.
+
+There's a subthread about that starting at
+https://lists.debian.org/debian-devel/2013/05/msg01309.html
+Helmut Grohne (Cced) did most of the work on analyzing those possibilities.
+
+Lucas
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 08:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 08:30:04 GMT) (full text, mbox, link).

+ +

Message #140 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Wouter Verhelst <wouter@master.debian.org>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>, Lucas Nussbaum <leader@debian.org>, + Paul Tagliamonte <paultag@debian.org>, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Tue, 29 Oct 2013 01:26:24 -0700
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Oct 28, 2013 at 05:22:14PM +0000, Wouter Verhelst wrote:
+> On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
+> > Right.  Whichever init system we pick, I do expect the next step to be to
+> > drop the requirement to maintain sysvinit backwards-compatibility;
+
+> While I'm not sure from your mail whether you meant to suggest otherwise,
+> I do think that whatever we decide for jessie, we should continue the
+> requirement of sysvinit compatibility for at least one release after we
+> ship with some more modern init system.
+
+The point was not about whether the init system would maintain
+backwards-compatibility with sysvinit, which is straightforward to conserve
+for some time, but whether individual packages providing services need to
+maintain compatibility with sysvinit or if they can adopt the native service
+definition format.  If we adopt a different init system as the default in
+jessie, then certainly by jessie+1 at the latest, maintainers should feel
+free to use the native format exclusively and not feel required to maintain
+compatibility with sysvinit.
+
+> Also, since all alternative init implementations under consideration do
+> support sysv-style init scripts, I think that whatever init system we
+> (well, you, the TC) end up choosing, the requirement in policy should be
+> that a package should ship either some init configuration for the
+> default init system, or a sysv-style init script. In fact, I think we
+> should continue to encourage the latter, in cases where it does make
+> sense (e.g., when a given daemon doesn't have any init system specific
+> features that could be enabled), since that will help our non-Linux
+> ports without significantly impacting performance of the new init
+> system.
+
+I see no reason that, if upstart were chosen as the default, porters could
+not use it for our non-Linux ports as well.  This is a much better outcome
+across our distribution as a whole than to require developers to continue
+maintaining init scripts just for our non-Linux ports.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 09:27:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Helmut Grohne <helmut@subdivi.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 09:27:14 GMT) (full text, mbox, link).

+ +

Message #145 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Helmut Grohne <helmut@subdivi.de>
+
To: Lucas Nussbaum <lucas@debian.org>
+
Cc: 727708@bugs.debian.org, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Tue, 29 Oct 2013 10:22:54 +0100
+
+
TL;DR: Thoughts on using systemd .service files on non-Linux ports.
+
+On Tue, Oct 29, 2013 at 09:20:10AM +0100, Lucas Nussbaum wrote:
+> Note that there are two options that could be explored, to remove the
+> need to maintain init scripts:
+> - generating sysvinit scripts from systemd service files or upstart job
+>   files at build time (this was explored, for systemd service files,
+>   during a GSoC project in 2012, without much success)
+> - having a .service/job files runtime interpreter (that sounds quite
+>   promising)
+> 
+> Even if it cannot be used for all services, using such as interpreter
+> could maybe provide an easy support path for sysvinit on non-linux
+> platforms for a large number of "simple" services.
+> 
+> There's a subthread about that starting at
+> https://lists.debian.org/debian-devel/2013/05/msg01309.html
+> Helmut Grohne (Cced) did most of the work on analyzing those possibilities.
+
+Thanks for inviting me to speak up here. Lucas asked me to summarize my
+analysis of systemd/sysv integration earlier and I'll be giving this
+summary (written for Lucas at that time) below.
+
+For better separation of facts and opinion, let me point out my
+motivation for working on this aspect. I believe that the declarative
+service configuration of systemd and upstart is superior to init shell
+scripts. Consequently, dropping the need for init shell scripts is the
+only way to improve the situation (imo). Lacking time, I mostly
+neglected upstart.
+
+On 23/08/13 at 22:32 +0200, Helmut Grohne wrote:
+> The existing converter (GSOC) can be found at
+> https://github.com/akhilvij/systemd-to-sysvinit-converter.
+> 
+> My analysis of this project:
+> https://lists.debian.org/debian-devel/2013/05/msg01309.html
+> This includes a drafted idea on how to do runtime conversion.
+> 
+> Implementation details on runtime conversion: (last pragraph)
+> https://lists.debian.org/debian-devel/2013/05/msg01337.html
+> 
+> Random details about service file conversion issues:
+> https://lists.debian.org/debian-devel/2013/05/msg01334.html
+> Important point over here: In .service files important dependency
+> information has been elided by socket activation. Socket activation is
+> official part of the dependency tree and any conversion utility that
+> does not do socket activation will not produce correct boot ordering.
+> 
+> Statistical analysis of existing .service files in Debian.
+> https://lists.debian.org/debian-devel/2013/07/msg00436.html
+> 
+> .service file parser written in C, could be used as a starting point.
+> https://lists.debian.org/debian-devel/2013/07/msg00429.html
+> 
+> I presume that you are preparing arguments for a discussion with the
+> CTTE about how to move forward with /sbin/init. The question of whether
+> or how to support systemd .service files on non-Linux platforms will be
+> asked over there.
+> 
+> The biggest issue I see here is the socket activation. It is mandatory
+> for syslog, so no service will declare a dependency on syslog and just
+> assume it to be present. On a technical level implementing socket
+> activation on non-Linux platforms is possible. It would require a super
+> server (similar to inetd) to be started early on and it would start
+> .service files on request by other interpreted .service files when
+> executed as init scripts. This amounts to reimplementing a fair part of
+> systemd. The only alternative would be to annotate .service files with
+> the missing dependency information, but which would likely be wrong most
+> of the time.
+> 
+> I guess that an implementation that allows socket activation would be
+> able to support around 50% of the currently existing .service files.
+> 
+> Bear in mind that systemd is a rapidly moving target. When I talked to
+> Lennart about the idea of a portable .service file interpreter, he
+> summarized future extensions to systemd that would raise the bar. The
+> next issue will likely be the tight integration with dbus and later
+> kdbus (the kernel implementation of dbus). By the time we would have an
+> implementation featuring socket activation, we will likely need it to do
+> dbus activation as well.
+
+Having read the parts of the ctte bug, it feels odd to preclude the
+option of supporting multiple init systems from discussion or
+consideration. If Debian is to support only one init system and that one
+init system is systemd, then given my above analysis it will be very
+hard for non-Linux ports to catch up. I argue that in this case we
+should consider dropping support for non-Linux ports. So if we really
+are considering such an outcome, why not consider the outcome of
+supporting multiple init systems (but maybe only one per architecture)?
+This would become radically easier if gnome were to become Architecture:
+linux-any.
+
+In any case, feel free to ask me for answers or help with respect to
+possible integration of systemd .service files in a non-Linux
+environment.
+
+I hope that this mail moves the discussion/decision forward.
+
+Helmut
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 11:21:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 11:21:05 GMT) (full text, mbox, link).

+ +

Message #150 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: FYI: upstream’s take
+
Date: Tue, 29 Oct 2013 11:51:37 +0100
+
+
* Russ Allbery (rra@debian.org) [131029 03:15]:
+> Michael Stapelberg <stapelberg@debian.org> writes:
+> 
+> > my apologies for not replying to any messages within the thread, but I
+> > think my mail is orthogonal to the other messages.
+> 
+> > Lennart Poettering wrote about the systemd upstream point of view on the
+> > discussion we are currently having:
+> > https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf
+> 
+> This is a valuable post.  Thank you for the pointer!  I would be
+> interested in seeing the two core technical arguments there (cgroup
+> handling and how D-Bus services are handled) addressed by the upstart
+> position paper, particularly if there are plans that Lennart isn't aware
+> of for how that functionality will be provided.
+
+I'm wondering how much libcgroup matches (or not) the role of cgroup
+handling - I use that in a different environment quite successfully,
+but that might be just me and not the full answer for everybody.
+
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 12:51:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 12:51:14 GMT) (full text, mbox, link).

+ +

Message #155 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init systems: arguments for the CTTE
+
Date: Tue, 29 Oct 2013 13:45:36 +0100
+
+
* Josselin Mouette (joss@debian.org) [131028 10:39]:
+>         As a side note, I think upstart’s CLA dismisses it as software
+>         of choice for our core system. 
+>         I know it’s not the only important piece of software in Debian
+>         with a CLA. I still stand on this point. I have experienced a
+>         real world CUPS nightmare because of Apple’s CLA, and I would be
+>         all for ditching CUPS as default too if we had a decent
+>         alternative.
+
+It is important for us that we can identify and fix bugs in our
+packages, and that we could forward bug reports to upstream and have a
+good working relationship with them (and allow them to pull our
+patches).
+
+However, lots of packages in Debian require copyright assignments to
+bring patches upstream. This includes as central packages as gcc. One
+could argue that the assignment policies between Ubuntu and FSF are
+different enough that it matters. On the other hand, I don't see why
+this is a blocker for us.
+
+The upstart maintainers in Debian will work on bug reports and
+proposed patches even without copyright assignment (as do the gcc
+maintainers), and that is what is required for us. Of course I would
+prefer if the copyright assignment policy would be changed, but that's
+something else.
+
+So, IMHO this topic is not a blocker for upstart (which doesn't on the
+other hand automatically imply upstart is the right answer - this
+depends on other questions and answers within this discussion).
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 16:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 16:33:05 GMT) (full text, mbox, link).

+ +

Message #160 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: 727708@bugs.debian.org, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Tue, 29 Oct 2013 09:31:37 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Hi Helmut,
+
+On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote:
+> Having read the parts of the ctte bug, it feels odd to preclude the
+> option of supporting multiple init systems from discussion or
+> consideration. If Debian is to support only one init system and that one
+> init system is systemd, then given my above analysis it will be very
+> hard for non-Linux ports to catch up. I argue that in this case we
+> should consider dropping support for non-Linux ports. So if we really
+> are considering such an outcome, why not consider the outcome of
+> supporting multiple init systems (but maybe only one per architecture)?
+
+While other members of the TC may wish to consider this option, I've ruled
+it out myself because we would lose most of the benefits of switching away
+from sysvinit and instead accrue significant maintenance costs to individual
+developers who would then have to support both init systems in their
+packages.  What makes switching init systems worth doing is being able to
+*simplify* the interfaces between the init system and the services.
+Continuing to support different init systems across different architectures
+would add complexity instead.  That's a pretty bleak outcome.
+
+There's nothing fundamental that prevents upstart from being ported to
+non-Linux ports.  So certainly, if the TC decides for upstart, I see no
+reason we would want to support sysvinit on ports instead of expecting the
+porters to port upstart to their architecture.
+
+> This would become radically easier if gnome were to become Architecture:
+> linux-any.
+
+GNOME may be the trigger for this being raised to the TC, but it's not the
+core question that we need to address.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 19:06:18 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 19:06:18 GMT) (full text, mbox, link).

+ +

Message #165 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Paul Tagliamonte <paultag@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: tech-ctte: Decide which init system to default to in Debian.
+
Date: Tue, 29 Oct 2013 12:05:25 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Hi Paul,
+
+On Fri, Oct 25, 2013 at 02:43:44PM -0400, Paul Tagliamonte wrote:
+> And, since I've been informed that this was basically a contentless bug,
+> I'd like to frame the technical half of the question better:
+
+Thanks for bringing this question to the Technical Committee.  It's been on
+my todo list to raise this myself, with the intent of getting a TC decision
+before the end of this year.  With only two months left in the year, it's
+well past time that we start on this, so thanks for beating me to it.
+
+In keeping with discussions I've had with other members of the TC regarding
+what they feel would help with their decision making process, I've begun
+preparing a wiki page outlining the position of the upstart maintainers on
+why Debian should adopt upstart as the default init system for jessie.
+
+   https://wiki.debian.org/Debate/initsystem/upstart
+
+The page is not yet complete - in particular, I'm still fleshing out the
+"why upstart and not systemd" section.  But there's enough there to give the
+TC a starting point for discussion, I think.
+
+> Whereas:
+
+>  * the init system / pid 1 is a bit of software that multiple packages
+>    provide
+
+>  * the choice of init system also dictates which types of init scripts
+>    package maintainers write and maintain
+
+>  * the situation in which packages depend on a feature of systemd that's
+>    not dependent on pid 1 being systemd (such as dbus shutdown, or using
+>    logind) being run without systemd as pid1 is *not* something the
+>    systemd maintainers will support (fairly) is getting *more* common, and
+>    has been introduced into a major package (GNOME)
+
+> It is requested that the tech-ctte make a decision as to the init system
+> Debian shall use as the default, and make a judgement call on where the
+> efforts to resolve this situation shall go (patching *around* the lack
+> of systemd, or patching software to use systemd)
+
+> I believe this is within the ctte's jurisdiction, given 6.1 section 2.
+
+It seems to me that these are two separate questions, one dependent on the
+other.  First we need to decide what jessie will use as the default init
+system.  Once that's decided, if the decision is /not/ to use systemd, we
+can look at making recommendations about how to approach upstream
+incompatibilities; but while we should be aware that choosing a non-systemd
+default does imply a certain amount of work, we shouldn't rathole on
+deciding how to structure that work if we haven't even decided yet if that
+work will be necessary.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 19:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bruno Melo <brunosonic@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 19:27:04 GMT) (full text, mbox, link).

+ +

Message #170 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bruno Melo <brunosonic@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Tue, 29 Oct 2013 17:25:49 -0200
+
+
[Message part 1 (text/plain, inline)]
+
Hi guys, I'm just an user.
+Well, can I make a suggestion?
+We know systemd can't run on kFreeBSD and because of it Gnome can't run on
+kFreeBSD too, but what about Cinnamon? Cinnamon is dependent on systemd?
+1- If not, so Cinnamon + good apps can make kFreeBSD usable. So replacing
+Gnome by Cinnamon on kFreeBSD (in CD-1, netinst, DVD-1 or whatever) is
+feasible.
+2- If yes, MATE can be another good idea (I already have build MATE on it
+:D). MATE + good apps for example Pidgin, VLC, Brasero, and other).
+3- In last case, if necessary kill kFreeBSD in favor to Illumos, the
+OSDyson project still alive and can be adopted in Debian project. Or,
+considering Gnome 3.10 is in OpenBSD ports, maybe a kOpenBSD is feasible.
+
+I think FreeBSD is  not worried about the existence of systemd, and they
+are using your init yet, so kFreeBSD can work around that too.
+Sorry if I said some very absurd, I'm noob. Thanks.
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 20:33:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 20:33:08 GMT) (full text, mbox, link).

+ +

Message #175 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: tech-ctte: Decide which init system to default to in Debian.
+
Date: Tue, 29 Oct 2013 16:44:09 -0400
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Oct 29, 2013 at 12:05:25PM -0700, Steve Langasek wrote:
+> Hi Paul,
+
+Good afternoon, Steve,
+
+> Thanks for bringing this question to the Technical Committee.  It's been on
+> my todo list to raise this myself, with the intent of getting a TC decision
+> before the end of this year.  With only two months left in the year, it's
+> well past time that we start on this, so thanks for beating me to it.
+
+Happy to do it!
+
+> In keeping with discussions I've had with other members of the TC regarding
+> what they feel would help with their decision making process, I've begun
+> preparing a wiki page outlining the position of the upstart maintainers on
+> why Debian should adopt upstart as the default init system for jessie.
+> 
+>    https://wiki.debian.org/Debate/initsystem/upstart
+> 
+> The page is not yet complete - in particular, I'm still fleshing out the
+> "why upstart and not systemd" section.  But there's enough there to give the
+> TC a starting point for discussion, I think.
+
+Great, that sounds like really productive stuff.
+
+> It seems to me that these are two separate questions, one dependent on the
+> other.  First we need to decide what jessie will use as the default init
+> system.  Once that's decided, if the decision is /not/ to use systemd, we
+> can look at making recommendations about how to approach upstream
+> incompatibilities; but while we should be aware that choosing a non-systemd
+> default does imply a certain amount of work, we shouldn't rathole on
+> deciding how to structure that work if we haven't even decided yet if that
+> work will be necessary.
+
+Totally agree.
+
+FWIW; I had a brief conversation with a core Gentoo developer about
+their situation, and they also have a hard dep on systemd from GNOME,
+even though their "default" is OpenRC.
+
+As they're in the same situation, I can tell there's likely a lot of
+cross-distro work that *can* be done in collaboration with another
+(community driven) distribution if we decide to not default to systemd.
+
+(such as maintaining replacements for components which require the hard
+ systemd pid1 dep)
+
+
+Thanks for taking this (very divisive) subject on,
+   Paul
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>
+: :'  : Proud Debian Developer
+`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+ `-     http://people.debian.org/~paultag
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 21:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 21:18:05 GMT) (full text, mbox, link).

+ +

Message #180 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Andreas Barth <aba@ayous.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: FYI: upstream’s take
+
Date: Tue, 29 Oct 2013 14:15:04 -0700
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Oct 29, 2013 at 11:51:37AM +0100, Andreas Barth wrote:
+> * Russ Allbery (rra@debian.org) [131029 03:15]:
+> > Michael Stapelberg <stapelberg@debian.org> writes:
+
+> > > my apologies for not replying to any messages within the thread, but I
+> > > think my mail is orthogonal to the other messages.
+
+> > > Lennart Poettering wrote about the systemd upstream point of view on the
+> > > discussion we are currently having:
+> > > https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf
+
+> > This is a valuable post.  Thank you for the pointer!  I would be
+> > interested in seeing the two core technical arguments there (cgroup
+> > handling and how D-Bus services are handled) addressed by the upstart
+> > position paper, particularly if there are plans that Lennart isn't aware
+> > of for how that functionality will be provided.
+
+> I'm wondering how much libcgroup matches (or not) the role of cgroup
+> handling - I use that in a different environment quite successfully,
+> but that might be just me and not the full answer for everybody.
+
+It does not.  The impending kernel transition is that there should be a
+single process managing the cgroup heirarchy on behalf of userspace; the
+existing libcgroup is a library that lets individual processes interface
+with /sys/fs/cgroup, not an implementor of the userspace cgroup manager
+service.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 23:03:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Carlos Alberto Lopez Perez <clopez@igalia.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 23:03:05 GMT) (full text, mbox, link).

+ +

Message #185 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Carlos Alberto Lopez Perez <clopez@igalia.com>
+
To: 727708@bugs.debian.org
+
Cc: debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Tue, 29 Oct 2013 23:59:26 +0100
+
+
[Message part 1 (text/plain, inline)]
+
On 28/10/13 20:14, Christoph Anton Mitterer wrote:
+> For those who haven't seen it, Lennart has posted some of his comments
+> about all this on G+:
+> https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf
+
+And here is the reply from Gentoo developer Patrick Lauer:
+
+http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 29 Oct 2013 23:21:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 29 Oct 2013 23:21:09 GMT) (full text, mbox, link).

+ +

Message #190 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Tue, 29 Oct 2013 16:16:04 -0700
+
+
Carlos Alberto Lopez Perez <clopez@igalia.com> writes:
+> On 28/10/13 20:14, Christoph Anton Mitterer wrote:
+
+>> For those who haven't seen it, Lennart has posted some of his comments
+>> about all this on G+:
+>> https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf
+
+> And here is the reply from Gentoo developer Patrick Lauer:
+
+> http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt
+
+This, sadly, was not particularly useful or interesting.  As near as I can
+tell, the core content was that he doesn't think cgroup management is
+particularly difficult (fine, but I don't think that was the point; the
+point, instead, was that it's important to have a single arbitrator, which
+if true poses specific technical challenges) and he believes that the
+components to systemd would be easy to implement as separate daemons if
+they were properly documented.
+
+I'm one of those people who thinks that nearly everything in Linux is
+horribly underdocumented, so I'm not going to argue with that point, but
+it's not a very useful statement from a practical viewpoint.  systemd
+offers specific pieces of integrated functionality.  By and large, no one
+seems to question that the operations enabled by that functionality are
+useful (although there is some debate over how useful).  GNOME is not
+depending on systemd out of some nefarious plot.  It's depending on
+systemd because GNOME wants to use those pieces of functionality systemd
+provides.
+
+Therefore, I think it's important for arguments against using systemd to
+somehow engage directly with the questions about functionality.  Either
+there needs to be an argument that the functionality is not important and
+can be done without (which raises questions about how one would build
+GNOME in such an environment), or there needs to be some sort of plan for
+how equivalent functionality to systemd will be provided.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 30 Oct 2013 07:57:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thomas Goirand <zigo@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 30 Oct 2013 07:57:09 GMT) (full text, mbox, link).

+ +

Message #195 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thomas Goirand <zigo@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Strong argument for OpenRC
+
Date: Wed, 30 Oct 2013 15:52:29 +0800
+
+
Hi,
+
+I got a *new* argument in the favor of OpenRC:
+
+http://youtu.be/zoNoi8BgQjs
+
+Yes, we made it work in Debian GNU/kFreeBSD! :)
+
+Upstream was very friendly helping to do this last night and this
+morning. Now, the next blocker would be renaming /sbin/rc to
+/sbin/openrc, though upstream pretends it shouldn't be hard to do, and
+they told me they will work on it. I unfortunately (and of course, I'd
+say) can't upload to Debian until this is fixed, though it's in
+collab-maint for those who want to try.
+
+I warmly welcome Hurd folks to try porting it too.
+
+Thomas Goirand (zigo)
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 30 Oct 2013 11:57:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Wouter Verhelst <wouter@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 30 Oct 2013 11:57:08 GMT) (full text, mbox, link).

+ +

Message #200 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Wouter Verhelst <wouter@debian.org>
+
To: Wouter Verhelst <wouter@master.debian.org>, 727708@bugs.debian.org, + Russ Allbery <rra@debian.org>, + Lucas Nussbaum <leader@debian.org>, + Paul Tagliamonte <paultag@debian.org>, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Wed, 30 Oct 2013 12:27:20 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Op 29-10-13 09:26, Steve Langasek schreef:
+> I see no reason that, if upstart were chosen as the default, porters could
+> not use it for our non-Linux ports as well.
+
+With some work, sure.
+
+> This is a much better outcome
+> across our distribution as a whole than to require developers to continue
+> maintaining init scripts just for our non-Linux ports.
+
+I did not say "require", I said "encourage". I agree that it's
+unreasonable to expect developers to maintain init scripts that they
+themselves do not use in addition to init configuration for whatever
+init system we end up with; and I do agree that it should be fair game
+for people to drop the init script from their package.
+
+However, there are some advantages to be had in continue to ship init
+scripts (while I can see no downsides, apart from the fact that they
+need to be written), and in that light it can make sense for us to
+encourage people to continue shipping init scripts.
+
+-- 
+This end should point toward the ground if you want to go to space.
+
+If it starts pointing toward space you are having a bad problem and you
+will not go to space today.
+
+  -- http://xkcd.com/1133/
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 30 Oct 2013 14:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Helmut Grohne <helmut@subdivi.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 30 Oct 2013 14:15:05 GMT) (full text, mbox, link).

+ +

Message #205 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Helmut Grohne <helmut@subdivi.de>
+
To: 727708@bugs.debian.org, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Wed, 30 Oct 2013 15:10:16 +0100
+
+
Hi Steve,
+
+On Tue, Oct 29, 2013 at 09:31:37AM -0700, Steve Langasek wrote:
+> On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote:
+> > Having read the parts of the ctte bug, it feels odd to preclude the
+> > option of supporting multiple init systems from discussion or
+> > consideration. If Debian is to support only one init system and that one
+> > init system is systemd, then given my above analysis it will be very
+> > hard for non-Linux ports to catch up. I argue that in this case we
+> > should consider dropping support for non-Linux ports. So if we really
+> > are considering such an outcome, why not consider the outcome of
+> > supporting multiple init systems (but maybe only one per architecture)?
+> 
+> While other members of the TC may wish to consider this option, I've ruled
+> it out myself because we would lose most of the benefits of switching away
+> from sysvinit and instead accrue significant maintenance costs to individual
+> developers who would then have to support both init systems in their
+> packages.  What makes switching init systems worth doing is being able to
+> *simplify* the interfaces between the init system and the services.
+> Continuing to support different init systems across different architectures
+> would add complexity instead.  That's a pretty bleak outcome.
+
+I fully agree with your reasoning. Yet, I see that the options
+ * drop support for non-Linux ports and
+ * maintain some support for an alternate init system
+are similarly painful. I see neither of them a desirable, but if we
+really consider one of them, I'd ask for the other one to be considered
+and evaluated as well.
+
+Most participants in this thread appear to agree that the sysvinit
+*interface* for services (shell scripts) is suboptimal. We are currently
+mostly arguing about implementations, because each proposed interface
+has only one implementation. It might make sense to consider a subset of
+the interface that one implementation provides as our standard and
+provide a degraded experience to that interface on non-Linux ports. For
+example, if systemd were to be the init system of choice, it could be
+required to provide an init script for services with Type=notify.
+
+The interfaces of all init systems (except sysvinit, but are we really
+considering that one?) still are somewhat in flux, so this is the point
+where we can still influence and shape them.
+
+<dream>
+Imagine a world where upstart and systemd would use the same syntax
+(structure) but implement different and somewhat overlapping aspects.
+Maybe 50% of the daemons would work with either of them without needing
+changes. <wakeup/> But now we call it "exec" here and "ExecStart" there,
+"export" here and "Environment" there, and "chdir" here and
+"WorkingDirectory" there. Bummer.
+</dream>
+
+Oh wait, I am talking to one of the guys who can actually fix this. :)
+
+> > This would become radically easier if gnome were to become Architecture:
+> > linux-any.
+> 
+> GNOME may be the trigger for this being raised to the TC, but it's not the
+> core question that we need to address.
+
+Even though I did mention gnome over there, the argument is not
+restricted to gnome in any way. It can be applied to any other package
+not deemed worthy to support on non-Linux ports (and I should have made
+this explicit). Furthering this thought leads to turning non-Linux ports
+into derivatives as presented by others in this thread.
+
+I argue that a resolution of this bug needs to answer:
+
+  What is going to happen with non-Linux ports?
+
+Helmut
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 30 Oct 2013 15:30:20 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Wouter Verhelst <wouter@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 30 Oct 2013 15:30:20 GMT) (full text, mbox, link).

+ +

Message #210 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Wouter Verhelst <wouter@debian.org>
+
To: debian-devel@lists.debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Wed, 30 Oct 2013 16:29:24 +0100
+
+
Op 30-10-13 00:16, Russ Allbery schreef:
+> Carlos Alberto Lopez Perez <clopez@igalia.com> writes:
+>> On 28/10/13 20:14, Christoph Anton Mitterer wrote:
+> 
+>>> For those who haven't seen it, Lennart has posted some of his comments
+>>> about all this on G+:
+>>> https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf
+> 
+>> And here is the reply from Gentoo developer Patrick Lauer:
+> 
+>> http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt
+> 
+> This, sadly, was not particularly useful or interesting.
+
+I disagree. His point isn't argued very well (seems more like a rant
+than a discussion), but it's there.
+
+> As near as I can
+> tell, the core content was that he doesn't think cgroup management is
+> particularly difficult (fine, but I don't think that was the point; the
+> point, instead, was that it's important to have a single arbitrator, which
+> if true poses specific technical challenges) and he believes that the
+> components to systemd would be easy to implement as separate daemons if
+> they were properly documented.
+> 
+> I'm one of those people who thinks that nearly everything in Linux is
+> horribly underdocumented, so I'm not going to argue with that point, but
+> it's not a very useful statement from a practical viewpoint.  systemd
+> offers specific pieces of integrated functionality.  By and large, no one
+> seems to question that the operations enabled by that functionality are
+> useful (although there is some debate over how useful).  GNOME is not
+> depending on systemd out of some nefarious plot.  It's depending on
+> systemd because GNOME wants to use those pieces of functionality systemd
+> provides.
+> 
+> Therefore, I think it's important for arguments against using systemd to
+> somehow engage directly with the questions about functionality.  Either
+> there needs to be an argument that the functionality is not important and
+> can be done without (which raises questions about how one would build
+> GNOME in such an environment), or there needs to be some sort of plan for
+> how equivalent functionality to systemd will be provided.
+
+From the above link:
+
+"The only thing stopping me from reimplementing that functionality is
+that I have no idea what it's supposed to *do* ... and I don't enjoy
+reading through all of systemd to find out."
+
+(about logind)
+
+While I agree with your point, it's pretty difficult to reimplement the
+"interesting" parts of systemd in other implementations of pid1 if
+whoever wrote the "interesting" parts does not document it, does not say
+what it's supposed to do, does not want to accept patches for things
+they're not interested in, and is by and large uninterested in anyone
+who prefers to use something else than whatever their kool-aid is.
+
+I'll grant that maybe logind provides interesting functionality which
+other projects might want to depend on, and that there's nothing wrong
+with that. The problem, however, is that the functionality is not
+defined: if I want to provide an alternative pid1 implementation, then
+the specifications are clear, and I should Just Do It (not that I'm
+going to muddle the waters even more by doing so, but you understand the
+point). If I want to provide an alternative implementation of logind,
+however, then the only spec out there is the logind code, which might
+change one day to the next just because the logind developer feels like it.
+
+This wouldn't be much of a problem if I could just take logind (and
+udev, and dbus, and more things) out of the systemd source tree and use
+it without systemd, should I want to. But you can't; the problem is that
+the upstream of all these projects is by and large uninterested in doing
+so, and also does not seem to support other people who are, and at least
+the Debian maintainers of systemd have gone on record as saying that
+they won't guarantee this would remain possible (if the systemd
+developers would be willing to do so, then I suppose that could
+ameliorate some concerns).
+
+The "obvious" solution would be that the world changes to systemd
+because what, essentially, amounts to a level of sabotage by the systemd
+developers of things that aren't systemd. If systemd is in fact the best
+choice "out there", of which I'm not convinced at this point in time,
+then I wouldn't mind that (much). But I'd like us to do so for the right
+technical reasons, not just because it means we make our lives easier in
+not having to fight with a stubborn upstream all the time. We could,
+after all, fork, like we have done on other occasions of stubborn upstreams.
+
+Given all of the above, I would even argue that perhaps Debian should
+*not* adopt systemd as init system, out of principle; if we were to do
+so, then almost all the major distributions would be using systemd (with
+the sole exception of Ubuntu; I expect redhat to switch to systemd for
+their next EL version), which could go a long way to making it part of
+what it means to be running "Linux". At that point, any competing
+innovative implementations would simply face an almost insurmountable
+heap of undocumented code.
+
+Yes, absense of documentation is common on Unix and Linux systems; but
+no, I do not think that this is okay, or that we should in any way
+encourage that sort of thing.
+
+-- 
+This end should point toward the ground if you want to go to space.
+
+If it starts pointing toward space you are having a bad problem and you
+will not go to space today.
+
+  -- http://xkcd.com/1133/
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 30 Oct 2013 15:36:16 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 30 Oct 2013 15:36:16 GMT) (full text, mbox, link).

+ +

Message #215 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: 727708@bugs.debian.org, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Wed, 30 Oct 2013 15:52:46 +0100
+
+
On Wed, Oct 30, 2013 at 03:10:16PM +0100, Helmut Grohne wrote:
+> The interfaces of all init systems (except sysvinit, but are we really
+> considering that one?) still are somewhat in flux, so this is the point
+> where we can still influence and shape them.
+> 
+> <dream>
+> Imagine a world where upstart and systemd would use the same syntax
+> (structure) but implement different and somewhat overlapping aspects.
+> Maybe 50% of the daemons would work with either of them without needing
+> changes. <wakeup/> But now we call it "exec" here and "ExecStart" there,
+> "export" here and "Environment" there, and "chdir" here and
+> "WorkingDirectory" there. Bummer.
+> </dream>
+Hi Helmut,
+"exec" vs. "ExecStart=" and "export" vs. "Environment=" is easy.
+Anyone can whip up a sed script to convert between those. The question
+is how to deal with more advanced options. Let's say that I have a
+systemd unit with
+
+CapabilityBoundingSet=CAP_SYS_TIME    # limit the capability bounding set to CAP_SYS_TIME
+PrivateTmp=yes                        # run with unshared /tmp
+InaccessibleDirectories=/home	      # run without access to /home
+WatchdogSec=60			      # consider the service dead if it hasn't pinged the
+                                      # manager for in the last minute
+Restart=on-failure                    # restart service on watchdog failure or unclean exit
+
+This isn't a question of syntax, it's a question of significant
+functionality in the manager. I think that sharing service
+descriptions between disparate init managers is infeasible, unless we
+forbid the use of anything but the basic features.
+
+Another thing that is turning into a significant gap is socket
+activation.  In systemd, socket activation allows the service to
+receive multiple open sockets (e.g. ports 80 and 443 for an httpd
+server). Socket activation of daemons is cool:
+- it is very easy to write such a daemon, it must just do accept(), read() and write()
+- resource efficent because of activation on demand
+- great for running unpriviledged, since the daemon only does accept(), read() and write()
+- we get rid of a lot of inter-daemon ordering dependencies.
+With the recent addition of (experimental) systemd-socket-proxyd[1],
+even daemons like apache which do not support socket activation
+internally can be launched on demand by wrapping them with a
+helper. Socket activation is a great technique, bound to be used more.
+Achieving the same functionality with init scripts is very
+hard, and AFAIK, upstart doesn't support socket activation with
+more than one socket.
+
+[1] http://www.freedesktop.org/software/systemd/man/systemd-socket-proxyd.html
+
+> Oh wait, I am talking to one of the guys who can actually fix this. :)
+
+Zbyszek
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 30 Oct 2013 16:03:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 30 Oct 2013 16:03:11 GMT) (full text, mbox, link).

+ +

Message #220 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: debian-devel@lists.debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Wed, 30 Oct 2013 16:58:36 +0100
+
+
]] Wouter Verhelst 
+
+> Yes, absense of documentation is common on Unix and Linux systems; but
+> no, I do not think that this is okay, or that we should in any way
+> encourage that sort of thing.
+
+By absense of documentation, are you referring to the almost 10% of the
+source base that are comments or the 15% that is DocBook XML based
+documentation?  (Almost 14kLOC and almost 36kLOX, respectively.)
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + +Information stored +:
+Bug#727708; Package tech-ctte. + (Wed, 30 Oct 2013 16:09:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and filed, but not forwarded. + (Wed, 30 Oct 2013 16:09:05 GMT) (full text, mbox, link).

+ +

Message #225 received at 727708-quiet@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: debian-devel@lists.debian.org
+
Cc: 727708-quiet@bugs.debian.org
+
Subject: Re: Re: Bug#727708: tech-ctte: Decide which init system to default + to in Debian.
+
Date: Wed, 30 Oct 2013 16:05:48 +0000 (UTC)
+
+
Steven Chamberlain dixit:
+
+[…]
+>substitute Upstart here if you prefer), each package's maintainer could:
+[…]
+
+* Write scripts for one system and generate the other from it
+or even
+* Write “Debian init declaration” and let something take care
+  of generating an initscript and whatever the other systems
+  use out of it
+
+bye,
+//mirabilos
+-- 
+<hecker> cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten
+die nicht noch 3 Jahre warten können? <mirabilos> bis dahin gibts google nicht
+mehr <hecker> ja, könnte man meinen. wahrscheinlich ist der angekündigte welt-
+untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum
+müssen die die doodles vorher noch raushauen
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 30 Oct 2013 17:03:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Игорь Пашев <pashev.igor@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 30 Oct 2013 17:03:15 GMT) (full text, mbox, link).

+ +

Message #230 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Игорь Пашев <pashev.igor@gmail.com>
+
To: 727708@bugs.debian.org, Debian Devel <debian-devel@lists.debian.org>
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Wed, 30 Oct 2013 20:59:00 +0400
+
+
2013/10/30 Helmut Grohne <helmut@subdivi.de>:
+> What is going to happen with non-Linux ports?
+
+Debian is not Debian without non-Linux ports.
+
+As for me, I think it is not very hard to maintain diffrent init
+systems for different kernels.
+Especially if Debian GNU/Linux get rid of sysvinit: writing systemd or upstrart
+services is simple (as well as SMF).
+
+Just one example from OSDyson (lighttpd):
+
+1. dh-smf: http://cgit.osdyson.org/dh-smf.git
+2. lighttpd depends on dh-smf for illumos kernel:
+http://cgit.osdyson.org/lighttpd.git/tree/debian/control#n10
+3. No changes in d/rules (!):
+http://cgit.osdyson.org/lighttpd.git/tree/debian/rules
+4. DH automatically peeks up dh_smf:
+http://cgit.osdyson.org/debhelper.git/tree/dh?id=3769023faf4758f944e710480c43cda220821690#n524
+5. dh_smf looks into this directory:
+http://cgit.osdyson.org/lighttpd.git/tree/debian/lighttpd.smf
+6. dh_installinit is no-op on Dyson
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 30 Oct 2013 17:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 30 Oct 2013 17:57:05 GMT) (full text, mbox, link).

+ +

Message #235 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Wouter Verhelst <wouter@debian.org>, 727708@bugs.debian.org
+
Cc: debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Wed, 30 Oct 2013 10:56:07 -0700
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Oct 30, 2013 at 04:29:24PM +0100, Wouter Verhelst wrote:
+> While I agree with your point, it's pretty difficult to reimplement the
+> "interesting" parts of systemd in other implementations of pid1 if
+> whoever wrote the "interesting" parts does not document it, does not say
+> what it's supposed to do, does not want to accept patches for things
+> they're not interested in, and is by and large uninterested in anyone
+> who prefers to use something else than whatever their kool-aid is.
+
+> I'll grant that maybe logind provides interesting functionality which
+> other projects might want to depend on, and that there's nothing wrong
+> with that. The problem, however, is that the functionality is not
+> defined: if I want to provide an alternative pid1 implementation, then
+> the specifications are clear, and I should Just Do It (not that I'm
+> going to muddle the waters even more by doing so, but you understand the
+> point). If I want to provide an alternative implementation of logind,
+> however, then the only spec out there is the logind code, which might
+> change one day to the next just because the logind developer feels like it.
+
+Are there things missing from
+<http://www.freedesktop.org/wiki/Software/systemd/logind/> from an
+implementor's perspective?
+
+For my part I regard this as a tempest in a teapot.  Lennart has been
+effective at making people worry that not using systemd is too dangerous to
+consider.  But Ubuntu has done just fine with splitting the dbus services
+off of init up through systemd 204, and while we know there are some big
+issues on the horizon with the cgroup manager and kdbus questions, these are
+not settled matters across the Free Software ecosystem.  There are lots of
+other people besides the upstart and Debian non-Linux-port community who
+have reservations about the systemd gravity well, including anyone using
+cgroups today on top of lxc or using the Google tools.
+
+So I'm not going to give anyone a roadmap today for how these capabilities
+will be made available in a non-systemd environment, because a lot of this
+has to do with decisions that need to be made in the relevant wider
+technical communities and have nothing to do with the init system per se.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 01:21:31 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 01:21:31 GMT) (full text, mbox, link).

+ +

Message #240 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Theodore Ts'o <tytso@mit.edu>
+
Cc: Wouter Verhelst <wouter@master.debian.org>, Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Wed, 30 Oct 2013 18:18:29 -0700
+
+
Theodore Ts'o <tytso@mit.edu> writes:
+> On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
+
+>> Well, I've said this before, but I think it's worth reiterating.
+>> Either upstart or systemd configurations are *radically better* than
+>> init scripts on basically every axis.  They're more robust, more
+>> maintainable, easier for the local administrator to fix and revise,
+>> better on package upgrades, support new capabilities, etc.
+
+> Can you please go in to more detail why you believe this was true?
+
+I think it's painfully obvious if you compare an init script to an upstart
+or systemd configuration file for a simple daemon like, say, my lbcd
+package.
+
+For those who don't agree, please try the exercise of writing systemd and
+upstart configuration files for some typical daemon package and look at
+the number of lines of code in both and the behavior in edge cases (daemon
+already running, daemon running but with no PID file because something
+else deleted it, daemon part of a dependency chain that shouldn't fire
+until the daemon is actually listening to the network, correct exit status
+for various failure conditions, stopping the daemon when there is a user
+process with the same name as the daemon also running, and the other cases
+Policy says one must handle).  Now compare the length of time it took you
+to make an init script correctly handle all those cases versus how long it
+took to write the upstart or systemd configuration.  (Note that I have
+found, IIRC, two different edge-case bugs in /etc/init.d/skeleton while
+working on Debian, so even if you start from that file, which is only
+applicable to a relatively narrow range of circumstances, you can still
+fail edge cases.)
+
+I have prior experience here both as Policy editor dealing with the Policy
+sections related to init scripts and as a Lintian maintainer dealing with
+Lintian checks for init scripts.  Both of those experiences were, shall we
+say, convincing.
+
+Another way to look at this is that both upstart and systemd provide a
+high-level programming language for writing init scripts.  Not only does
+it implement a higher level of abstraction, it's also better-suited to the
+problem space because it's declarative rather than imperative.  (systemd
+somewhat more so than upstart, although that makes it somewhat more
+awkward to use in cases where you really need to run some shell script on
+various actions.)
+
+As with any move to a higher-level programming interface, there are
+drawbacks; if you really want to do your own memory management, you don't
+get to any more.  And as with most moves to a higher-level programming
+interface well-suited to the task at hand, the advantages outweigh the
+drawbacks.  (And in this case, I'd go a step farther and say that I think
+most of the drawbacks people cite around loss of flexibility are at least
+arguably benefits.  The world would be a better place with fewer init
+scripts doing weird and unexpected things to paper over bugs better fixed
+somewhere else.)
+
+This really shouldn't be a particularly controversial stance.  Ever since
+Solaris SMF, various UNIX implementations have been abandoning traditional
+init scripts for exactly these reasons.  I really don't think that all
+those completely independent technical teams, which at this point include
+most major Linux distributions (counting OpenRC as another higher-level
+implementation), are all wrong.
+
+This is an area of personal interest of mine.  I followed daemontools
+development back when Dan Bernstein was tackling this same basic problem
+in his distinctively radical way, and have subsequently been paying at
+least casual attention to various different daemon management facilities
+ever since.  A lot of people have tried to solve various aspects of the
+problem that init scripts are actually horrible at what they do, and the
+solutions have been slowly improving and becoming more and more robust.
+
+AFS attempted to solve this problem all the way back in the 1980s.  Even
+back then, it was obvious that init scripts were insufficiently powerful
+to manage production services properly, hence the whole bosserver system
+that persists in OpenAFS to this day and which, coming from MIT, you may
+be familiar with.  Not that I would advocate use of bosserver for anything
+other than AFS these days, as there are now lots of newer technologies
+that have surpassed it, although (relatively) secure network management of
+services is still an interesting feature.
+
+> The lsat time I played with Upstart, I saw a lot of policy moved from
+> shell scripts into C code (which I would have to edit and recompile) if
+> I wanted to change things.  I also was extremely frustrated with a
+> massive lack of documentation, where at least with shell scripts I could
+> read the scripts to understand what was going on.
+
+I suspect you and I have a root disagreement over the utility of exposing
+some of those degrees of freedom to every init script author, but if you
+have some more specific examples of policy that you wanted to change but
+couldn't, I'd be interested in examples.
+
+Note that *Debian*, as a distribution, has a significant interest in
+standardizing policy around how daemons are managed.  It's therefore not a
+bad thing for the distribution if we have an init system that handles that
+policy, provided that it encodes the policy that we want.  I realize that
+the local administrator may have other goals, and they should have ways of
+achieving them, but both systemd and upstart support running SysV init
+scripts for those cases.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 01:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Theodore Ts'o <tytso@mit.edu>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 01:24:04 GMT) (full text, mbox, link).

+ +

Message #245 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Theodore Ts'o <tytso@mit.edu>
+
To: Russ Allbery <rra@debian.org>
+
Cc: Wouter Verhelst <wouter@master.debian.org>, + Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, + Paul Tagliamonte <paultag@debian.org>, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Wed, 30 Oct 2013 20:41:10 -0400
+
+
On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
+> Well, I've said this before, but I think it's worth reiterating.  Either
+> upstart or systemd configurations are *radically better* than init scripts
+> on basically every axis.  They're more robust, more maintainable, easier
+> for the local administrator to fix and revise, better on package upgrades,
+> support new capabilities, etc.
+
+Can you please go in to more detail why you believe this was true?
+
+The lsat time I played with Upstart, I saw a lot of policy moved from
+shell scripts into C code (which I would have to edit and recompile)
+if I wanted to change things.  I also was extremely frustrated with a
+massive lack of documentation, where at least with shell scripts I
+could read the scripts to understand what was going on.
+
+Maybe things have changed, but that was my impression with both
+Systemd and Upstart (and policykit, and consolekit, etc. all of which
+has caused me no end of frustration).
+
+						- Ted
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 01:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Theodore Ts'o <tytso@mit.edu>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 01:54:04 GMT) (full text, mbox, link).

+ +

Message #250 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Theodore Ts'o <tytso@mit.edu>
+
To: Russ Allbery <rra@debian.org>
+
Cc: Wouter Verhelst <wouter@master.debian.org>, + Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, + Paul Tagliamonte <paultag@debian.org>, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Wed, 30 Oct 2013 21:50:53 -0400
+
+
On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
+> I suspect you and I have a root disagreement over the utility of exposing
+> some of those degrees of freedom to every init script author, but if you
+> have some more specific examples of policy that you wanted to change but
+> couldn't, I'd be interested in examples.
+
+It's not necessarily the init script author who might want the degrees
+of freedom, but the local system administrator.
+
+The most basic is the idea that whether you can control (via shell
+scrpit fragments) whether or not a service should start at all, and
+what options or environments should be enabled by pasing some file.
+The fact that we can put that sort of thing in configuration files
+such as /etc/default/*, for example.
+
+Yes, yes, you can do this via if you use system V init scripts scripts
+in backwards compatibility mode, but you've argued that we should be
+moving briskly away from that.  In which case system administrators
+will need to hand-edit the services files by hand, which will no doubt
+increase the chances of conflicts at package upgrade time, compared to
+if the configuration options were isolated away in files such as
+/etc/default/rsync (for example).
+
+> I realize that
+> the local administrator may have other goals, and they should have ways of
+> achieving them, but both systemd and upstart support running SysV init
+> scripts for those cases.
+
+If the package does not ship a SysV init script (which is your ideal
+long-term outcome), that may not be very practical option for a system
+adminsitrator who may need to recreate a SysV init script, especially
+if the service file is rather complicated, or is using some of the
+more advanced feature of systemd/upstart.
+
+						- Ted
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 02:15:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 02:15:07 GMT) (full text, mbox, link).

+ +

Message #255 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Theodore Ts'o <tytso@mit.edu>
+
Cc: Wouter Verhelst <wouter@master.debian.org>, Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Wed, 30 Oct 2013 19:13:04 -0700
+
+
Theodore Ts'o <tytso@mit.edu> writes:
+> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
+
+>> I suspect you and I have a root disagreement over the utility of
+>> exposing some of those degrees of freedom to every init script author,
+>> but if you have some more specific examples of policy that you wanted
+>> to change but couldn't, I'd be interested in examples.
+
+> It's not necessarily the init script author who might want the degrees
+> of freedom, but the local system administrator.
+
+> The most basic is the idea that whether you can control (via shell
+> scrpit fragments) whether or not a service should start at all, and what
+> options or environments should be enabled by pasing some file.  The fact
+> that we can put that sort of thing in configuration files such as
+> /etc/default/*, for example.
+
+> Yes, yes, you can do this via if you use system V init scripts scripts
+> in backwards compatibility mode, but you've argued that we should be
+> moving briskly away from that.  In which case system administrators will
+> need to hand-edit the services files by hand, which will no doubt
+> increase the chances of conflicts at package upgrade time, compared to
+> if the configuration options were isolated away in files such as
+> /etc/default/rsync (for example).
+
+Ah, I see.
+
+However, I do think this is mostly a solvable problem.  We should provide
+meaningful flexibility in our init script configuration, which may include
+providing hooks so that local administrators have a place to put that
+local policy.
+
+You're right that some of this functionality will probably be lost in the
+initial conversion to something other than init scripts, but I would
+consider that to (usually) be a bug, and as people report problems, we can
+be sure it's added back in after understanding the issues involved.  Yes,
+this may be a bit annoying for people in the short term, but I do think it
+gets us to a better place in the long run by way of supporting clean and
+documented interfaces for those policy settings.
+
+It is true that currently init scripts are full-blown programs, allowing
+anyone who is capable of programming in that language to make arbitrary
+policy modifications.  We lose that by switching to a higher-level
+language, and only policy decisions anticipated by that language will be
+easily implemented.  More complex policy decisions would have to be
+handled at a higher level, via selectively creating or removing the
+configuration files.  It's certainly a disruptive change.  I'm not
+convinced it's a net negative, but it will depend on how strong the
+available hooks are and what types of policy the local administrator wants
+to easily change.
+
+I do think that being able to treat the init scripts as real configuration
+files will make maintaining such local policy easier than it is currently.
+The prospect of modifying init scripts was already dire enough that we
+pushed most meaningful configuration into /etc/default instead of asking
+that people change the complicated init scripts and then handle merges on
+package upgrades.  *Most* local changes are fairly simple, and would only
+require small and mergable changes to upstart configuration files, and
+small overrides to systemd files.
+
+I personally like upstart's model a little better, but systemd's model of
+/etc overrides /lib is, I think, workable as long as people remember to
+change only the setting they want and then include the original instead of
+making copies of the whole configuration.  (That being said, I'm worried
+about how the systemd model handles the common case of wanting to change
+the command-line arguments to a daemon, and then having the package also
+change the command-line arguments in some orthogonal way.)
+
+> If the package does not ship a SysV init script (which is your ideal
+> long-term outcome), that may not be very practical option for a system
+> adminsitrator who may need to recreate a SysV init script, especially if
+> the service file is rather complicated, or is using some of the more
+> advanced feature of systemd/upstart.
+
+You can do quite a bit with the hooks that are part of the specification
+of both types of files.  For example, logic that you may add to control
+whether the service should start at all can be implemented by adding a
+pre-start stanza to the upstart configuration.
+
+This particular action appears to be harder to do in systemd, which
+doesn't, at least from the documentation that I've found, support running
+arbitrary shell code to determine whether to start a unit, but there are a
+bunch of other possible built-in checks.  I suppose one could also change
+the command started to wrap it and put the check there, although that
+feels quite ugly.
+
+In general, upstart's integration with arbitrary actions in shell
+fragments is considerably better than systemd's, at least based on the
+documentation I've read.  upstart feels like it provides more useful
+flexibility.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 02:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 02:24:04 GMT) (full text, mbox, link).

+ +

Message #260 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: Theodore Ts'o <tytso@mit.edu>
+
Cc: Russ Allbery <rra@debian.org>, + Wouter Verhelst <wouter@master.debian.org>, + Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, + Paul Tagliamonte <paultag@debian.org>, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Thu, 31 Oct 2013 03:21:36 +0100
+
+
On Wed, Oct 30, 2013 at 09:50:53PM -0400, Theodore Ts'o wrote:
+> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
+> > I suspect you and I have a root disagreement over the utility of exposing
+> > some of those degrees of freedom to every init script author, but if you
+> > have some more specific examples of policy that you wanted to change but
+> > couldn't, I'd be interested in examples.
+> 
+> It's not necessarily the init script author who might want the degrees
+> of freedom, but the local system administrator.
+> 
+> The most basic is the idea that whether you can control (via shell
+> scrpit fragments) whether or not a service should start at all, and
+> what options or environments should be enabled by pasing some file.
+> The fact that we can put that sort of thing in configuration files
+> such as /etc/default/*, for example.
+Both systemd and upstart support this well enough.
+
+With systemd you can say EnvironmentFile=/etc/default/<whatever>
+and use the variables in ExecStart=/path/to/prog $VAR1 $VAR2.
+This is usually discouraged, not because it doesn't work, but
+because it uses two files to provide very little value. In majority
+of cases it turns out that the settings in /etc/default either
+can't be changed in an useful way, or are better read by the daemon
+itself from a different configuration file. But if you want this, then
+it's there.
+
+If the settings are to complicated for the declarative style, you
+can always use an helper shell script to launch the daemon.
+Again, discouraged, but certainly supported.
+
+> Yes, yes, you can do this via if you use system V init scripts scripts
+> in backwards compatibility mode, but you've argued that we should be
+> moving briskly away from that.  In which case system administrators
+> will need to hand-edit the services files by hand, which will no doubt
+> increase the chances of conflicts at package upgrade time, compared to
+> if the configuration options were isolated away in files such as
+> /etc/default/rsync (for example).
+Actually this doesn't happen that often. Typical systemd service file
+has 1-3 lines of documentation, 1+ lines of ExecStart stuff, and a few
+additional settings. They are mostly orthogonal, so you just override
+the one you need. Probably most common case is to override ExecStart=,
+done by adding the file like /etc/systemd/system/myservice.d/custom-start.conf
+which only overrides ExecStart. Nice and simple, no conflicts on upgrade.
+
+> > I realize that
+> > the local administrator may have other goals, and they should have ways of
+> > achieving them, but both systemd and upstart support running SysV init
+> > scripts for those cases.
+> 
+> If the package does not ship a SysV init script (which is your ideal
+> long-term outcome), that may not be very practical option for a system
+> adminsitrator who may need to recreate a SysV init script, especially
+> if the service file is rather complicated, or is using some of the
+> more advanced feature of systemd/upstart.
+Why would you recreate the whole script? Let the init manager take
+care of starting and stopping and supervising, and only do the custom
+stuff in the script. Then it should be just a few lines.
+
+Zbyszek
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 05:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 05:36:04 GMT) (full text, mbox, link).

+ +

Message #265 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+
To: Theodore Ts'o <tytso@mit.edu>
+
Cc: Russ Allbery <rra@debian.org>, + Wouter Verhelst <wouter@master.debian.org>, + Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, + Paul Tagliamonte <paultag@debian.org>, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Thu, 31 Oct 2013 06:33:44 +0100
+
+
On 10/31/2013 02:50 AM, Theodore Ts'o wrote:
+> The most basic is the idea that whether you can control (via shell
+> scrpit fragments) whether or not a service should start at all, and
+> what options or environments should be enabled by pasing some file.
+> The fact that we can put that sort of thing in configuration files
+> such as /etc/default/*, for example.
+> 
+> Yes, yes, you can do this via if you use system V init scripts scripts
+> in backwards compatibility mode, but you've argued that we should be
+> moving briskly away from that.  In which case system administrators
+> will need to hand-edit the services files by hand, which will no doubt
+> increase the chances of conflicts at package upgrade time, compared to
+> if the configuration options were isolated away in files such as
+> /etc/default/rsync (for example).
+
+Ted, I'm sorry, but it's very obvious you have no clue how systemd is
+supposed to be used. First of all, systemd - like udevd - supports
+two places where to place systemd service files. One is located
+below /usr/lib/systemd which is the directory where service files
+provided by the package are placed, and one is /etc/systemd where
+your own, custom service files are located.
+
+If systemd finds an appropriate service file in /etc/systemd it will
+ignore the appropriate service file in /usr/lib/systemd, always. So
+there is never a problem with service files being overwritten during an
+upgrade like you describe.
+
+The same holds true, btw, for udevd with it's rules files which are
+located in /lib/udev/rules.d and /etc/rules.d respectively.
+
+And everything that you might want change in the configuration of
+a service can be done by editing the service file and this in
+a much easier and consistent way. Editing a file in the .ini
+file format is a no-brainer which, in the worst mistake case, will
+probably lead to an error message from the daemon or systemd while
+messed up custom code may end up rendering your whole system unusable
+if you are smart enough to mess up an rm command. Just have a look
+at this wonderful bug in upstart [1].
+
+> If the package does not ship a SysV init script (which is your ideal
+> long-term outcome), that may not be very practical option for a system
+> adminsitrator who may need to recreate a SysV init script, especially
+> if the service file is rather complicated, or is using some of the
+> more advanced feature of systemd/upstart.
+
+No, System V Init scripts are not ideal on the long-term outcome since
+they are highly distribution-specific, error-prone and annoying to
+maintain. We have had tons of bugs in the bug tracker because of
+broken init scripts, like this one [2].
+
+I don't understand why anyone would think that having to write a small
+piece of code to start another program is a sensible and good design,
+especially when this is done for dozens of programs (= daemons) in very
+much the same way. It absolutely makes sense to encode the logic to
+start and control a daemon through a single piece of C code rather
+than writing more-or-less the same bash script for every
+single daemon on your machine.
+
+Adrian
+
+> [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177
+> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668890
+
+-- 
+ .''`.  John Paul Adrian Glaubitz
+: :' :  Debian Developer - glaubitz@debian.org
+`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
+  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 05:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 05:42:04 GMT) (full text, mbox, link).

+ +

Message #270 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: debian-devel@lists.debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Thu, 31 Oct 2013 06:39:53 +0100
+
+
]] Russ Allbery 
+
+(Cleaned up the Cc line somewhat)
+
+> You can do quite a bit with the hooks that are part of the specification
+> of both types of files.  For example, logic that you may add to control
+> whether the service should start at all can be implemented by adding a
+> pre-start stanza to the upstart configuration.
+
+ExecStartPre=/bin/false
+
+will make the service be considered failed.  The ExecStartPre line can
+of course be an executable that implements more checking or logic.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 08:45:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 08:45:05 GMT) (full text, mbox, link).

+ +

Message #275 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Theodore Ts'o <tytso@mit.edu>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>, + Wouter Verhelst <wouter@master.debian.org>, + Lucas Nussbaum <leader@debian.org>, + Paul Tagliamonte <paultag@debian.org>, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Thu, 31 Oct 2013 01:41:53 -0700
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Oct 30, 2013 at 08:41:10PM -0400, Theodore Ts'o wrote:
+> On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
+> > Well, I've said this before, but I think it's worth reiterating.  Either
+> > upstart or systemd configurations are *radically better* than init scripts
+> > on basically every axis.  They're more robust, more maintainable, easier
+> > for the local administrator to fix and revise, better on package upgrades,
+> > support new capabilities, etc.
+
+> Can you please go in to more detail why you believe this was true?
+
+> The lsat time I played with Upstart, I saw a lot of policy moved from
+> shell scripts into C code (which I would have to edit and recompile)
+> if I wanted to change things.
+
+I'm surprised by this comment.  Very little policy is actually encoded in
+upstart's C code; in fact, the only policy I can think of offhand that is is
+some basic stuff around filesystems, which, aside from some must-have kernel
+filesystems without which it can't boot the rest of the system, should be
+entirely overrideable via /etc/fstab.  Perhaps you could expand on what
+policies you saw a need to change?
+
+> I also was extremely frustrated with a massive lack of documentation,
+> where at least with shell scripts I could read the scripts to understand
+> what was going on.
+
+There's an awful lot of documentation available for upstart, but of course
+people look for documentation in lots of different ways and we aren't
+necessarily presenting the documentation where and when we need it.  There's
+comprehensive documentation available at
+<http://upstart.ubuntu.com/cookbook/>, but from context it's possible that's
+not what you were looking for.  Aside from adding links to manpages to all
+of the upstart jobs themselves (which I don't think is reasonable), are
+there things you think should be done to make the right documentation easy
+to find?  (For starters, what were you trying to find documentation of?)
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 08:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Wouter Verhelst <wouter@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 08:57:04 GMT) (full text, mbox, link).

+ +

Message #280 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Wouter Verhelst <wouter@debian.org>
+
To: Theodore Ts'o <tytso@mit.edu>
+
Cc: Russ Allbery <rra@debian.org>, + Wouter Verhelst <wouter@master.debian.org>, + Lucas Nussbaum <leader@debian.org>, 727708@bugs.debian.org, + Paul Tagliamonte <paultag@debian.org>, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Thu, 31 Oct 2013 09:54:10 +0100
+
+
Op 31-10-13 02:50, Theodore Ts'o schreef:
+> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
+>> I suspect you and I have a root disagreement over the utility of exposing
+>> some of those degrees of freedom to every init script author, but if you
+>> have some more specific examples of policy that you wanted to change but
+>> couldn't, I'd be interested in examples.
+> 
+> It's not necessarily the init script author who might want the degrees
+> of freedom, but the local system administrator.
+> 
+> The most basic is the idea that whether you can control (via shell
+> scrpit fragments) whether or not a service should start at all, and
+> what options or environments should be enabled by pasing some file.
+> The fact that we can put that sort of thing in configuration files
+> such as /etc/default/*, for example.
+
+This, in my opinion, is one of the worst abominations we currently have
+in Debian.
+
+Whether an init script should run at boot time has no relation
+whatsoever to whether it should run when the system administrator calls
+it manually. Yet, with "ENABLE=" variables in /etc/default, this is
+related, because the initscript will say "I'm disabled, go edit this
+file if you want to start me", even if you just want to start a daemon
+just this once manually, for testing.
+
+AIUI, both upstart and systemd have configuration options where you can
+tell the system that this particular service should not start at boot;
+that will then, however, not affect the result when one manually tries
+to start the service.
+
+I'm not sure that's a very good argument ;-)
+
+-- 
+This end should point toward the ground if you want to go to space.
+
+If it starts pointing toward space you are having a bad problem and you
+will not go to space today.
+
+  -- http://xkcd.com/1133/
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 11:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to David Härdeman <david@hardeman.nu>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 11:06:04 GMT) (full text, mbox, link).

+ +

Message #285 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: David Härdeman <david@hardeman.nu>
+
To: 727708@bugs.debian.org
+
Cc: leader@debian.org
+
Subject: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Thu, 31 Oct 2013 11:55:41 +0100
+
+
Dear Committee members,
+
+I'm not a DD, just a random contributor, and I haven't been actively 
+involved in the init system debate at all, nor do I have any stake in 
+it, though I've followed it with some interest.
+
+Now that the question has been referred to the Technical Committee 
+(which seems reasonable given the lack of progress in the discussion so 
+far), it strikes me as somewhat odd that the issue of impartiality/bias 
+hasn't been discussed in the committee to this point.
+
+The issue has already been raised on the Debian mailing lists[1] and 
+externally[2][3].
+
+The aphorism "Not only must Justice be done; it must also be seen to be 
+done" [4], which is oft quoted, not only in judicial proceedings, but 
+also in domestic tribunals (which would probably best describe the 
+committee), is based on the principle that the mere appearance of bias 
+(as opposed to actual bias which can be shown to have influenced a 
+decision) is sufficient to taint the process/decision.
+
+I would expect that a discussion that leads up to a decision on the 
+technical issues would at least address the question of bias as well. 
+Please note that I'm *not* trying to start a flame war here, and I'm 
+*not* accusing anyone, but I'm afraid that any discussion (and decision) 
+which was completely silent with regard to bias, once the question has 
+been raised, would appear to be lacking and would undermine public 
+confidence in the decision itself (and that's also the reason I bring 
+this up on a public list rather than in private email).
+
+Kind regards,
+David Härdeman
+
+[1] http://lists.debian.org/debian-devel/2013/10/msg00963.html
+[2] 
+http://slashdot.org/story/13/10/28/1621219/debian-to-replace-sysvinit-switch-to-systemd-or-upstart
+[3] http://www.phoronix.com/scan.php?page=news_item&px=MTQ5NzQ
+[4] http://en.wikipedia.org/wiki/R_v_Sussex_Justices,_ex_parte_McCarthy
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 11:09:18 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 11:09:18 GMT) (full text, mbox, link).

+ +

Message #290 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Thu, 31 Oct 2013 12:06:26 +0100
+
+
* Russ Allbery (rra@debian.org) [131031 02:19]:
+> Theodore Ts'o <tytso@mit.edu> writes:
+> > On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
+> 
+> >> Well, I've said this before, but I think it's worth reiterating.
+> >> Either upstart or systemd configurations are *radically better* than
+> >> init scripts on basically every axis.  They're more robust, more
+> >> maintainable, easier for the local administrator to fix and revise,
+> >> better on package upgrades, support new capabilities, etc.
+> 
+> > Can you please go in to more detail why you believe this was true?
+> 
+> I think it's painfully obvious if you compare an init script to an upstart
+> or systemd configuration file for a simple daemon like, say, my lbcd
+> package.
+
+For simple packages we would be far better of with a simple snippet
+that is either used by programms like systemd or upstart directly, or
+converted to a script by dh_initsnippet. One way or another we should
+as you write below go to an higher level language for init scripts.
+
+
+> Note that *Debian*, as a distribution, has a significant interest in
+> standardizing policy around how daemons are managed.  It's therefore not a
+> bad thing for the distribution if we have an init system that handles that
+> policy, provided that it encodes the policy that we want.  I realize that
+> the local administrator may have other goals, and they should have ways of
+> achieving them, but both systemd and upstart support running SysV init
+> scripts for those cases.
+
+Also I think we should make sure that the init system we use doesn't
+make it unnecessarily hard for local system administrators to change
+local defaults.
+
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 11:21:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Theodore Ts'o <tytso@mit.edu>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 11:21:08 GMT) (full text, mbox, link).

+ +

Message #295 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Theodore Ts'o <tytso@mit.edu>
+
To: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>, + Wouter Verhelst <wouter@master.debian.org>, + Lucas Nussbaum <leader@debian.org>, + Paul Tagliamonte <paultag@debian.org>, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Thu, 31 Oct 2013 07:20:12 -0400
+
+
On Thu, Oct 31, 2013 at 01:41:53AM -0700, Steve Langasek wrote:
+> I'm surprised by this comment.  Very little policy is actually encoded in
+> upstart's C code; in fact, the only policy I can think of offhand that is is
+> some basic stuff around filesystems, which, aside from some must-have kernel
+> filesystems without which it can't boot the rest of the system, should be
+> entirely overrideable via /etc/fstab.  Perhaps you could expand on what
+> policies you saw a need to change?
+
+The details are a bit fuzzy, because this was a quite a while ago,
+when Upstart was first introduced into Ubuntu, and it was so
+frustrating that it was what caused me to abandon Ubuntu and switch
+back to Debian.  The high bit was I couldn't get a particular service
+to start (it might have been bind, or some such), and I had no idea
+how to debug the darned thing.  With shell scripts, it's possible to
+insert "echo debug 1 $variable >> /tmp/debug.log" to figure out what's
+going on.  With upstart, I had no way of figuring out what was going
+on, and why it was failing, and the "no user-serviceable parts inside"
+was extremely frusrtating.
+
+I'm sure part of the problem was lack of documentation.  That seems to
+be a common theme with many of these "higher level language" systems.
+They may be powerful if you know the magic XML file to edit (in the
+case of policy kit), but it took me several hours before I figured out
+even something as simple as "say 'yes' to for all authorization
+questions", which is how I still run to this day, because (a) the
+default of prompting for the root password in popup windows all the
+time was too painful, and (b) trying to figure out how to XML
+language, and all of the triggeers, etc., was ***far*** too painful.
+One of the nice things about shell scripts is that they are far more
+self-documenting, and easier to debug, than XML and other
+'higher-level' configuration files (at least for this dumb kernel
+hacker :-).
+
+So hopefully that is something the technical committee will take into
+account --- how well things are documented, both in terms of a
+comprehensive reference manual, and a tutorial that helps people with
+common things that system administrators might want to do.  The
+docuementation you pointed to at http://upstart.ubuntu.com/cookbook/
+is something I wish I had access to when I first was forced to use
+Upstart; maybe if Upstart was as polished back then, I might not have
+given up on Ubuntu in disgust.
+
+Regards,
+
+					- Ted
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 11:54:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Florian Weimer <fw@deneb.enyo.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 11:54:09 GMT) (full text, mbox, link).

+ +

Message #300 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Florian Weimer <fw@deneb.enyo.de>
+
To: Theodore Ts'o <tytso@mit.edu>
+
Cc: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>, Wouter Verhelst <wouter@master.debian.org>, Lucas Nussbaum <leader@debian.org>, Paul Tagliamonte <paultag@debian.org>, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Thu, 31 Oct 2013 12:09:05 +0100
+
+
* Theodore Ts'o:
+
+> The most basic is the idea that whether you can control (via shell
+> scrpit fragments) whether or not a service should start at all, and
+> what options or environments should be enabled by pasing some file.
+
+Curiously, a lot of system administrators do not do this correctly
+using sysvinit, causing system daemons to start unexpectedly after
+installing package updates.
+
+I hope that a new init system will finally allow us to have something
+like chkconfig (not the best name in the world, I admit) that works
+reliably.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 15:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 15:03:05 GMT) (full text, mbox, link).

+ +

Message #305 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Cc: Tollef Fog Heen <tfheen@debian.org>, + Michael Biebl <biebl@debian.org>, + Marco d'Itri <md@linux.it>, + Thomas Goirand <zigo@debian.org>, + Steve Langasek <vorlon@debian.org>, + Steven Chamberlain <steven@pyro.eu.org>, + Patrick Lauer <patrick@gentoo.org>, + Alexander Vershilov <qnikst@gentoo.org>, + Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: init system question before the technical committee
+
Date: Thu, 31 Oct 2013 15:01:03 +0000
+
+
Ian Jackson writes ("Bug#727708: init system question before the technical committee"):
+> Steve Langasek writes[1]:
+> >   https://wiki.debian.org/Debate/initsystem/systemd
+...
+> So I would appreciate it if you (and by "you" I mean each side of the
+> argument) would make sure that your page represents the best case you
+> can put forward.
+
+This seems to have come along very well in the past few days.
+
+We now have five camps with pages with substantial content:
+
+  https://wiki.debian.org/Debate/initsystem/multiple
+  https://wiki.debian.org/Debate/initsystem/openrc
+  https://wiki.debian.org/Debate/initsystem/systemd
+  https://wiki.debian.org/Debate/initsystem/sysvinit
+  https://wiki.debian.org/Debate/initsystem/upstart
+
+Obviously people will need some time to further flesh this out and
+particularly to write rebuttals (or incorporate points into their main
+text which amount to rebuttals).
+
+If you're in one of these camps you'll probably want to subscribe to
+the pages of the others, so you can follow what they're doing and make
+sure to respond appropriately.
+
+How long do people think finalising this is going to take ?  There are
+some potential problems with setting a hard deadline in advance but
+we're hoping to deal with this matter fairly soon now.
+
+Perhaps it would be good if the camp leader(s) for each camp would
+reply with a summary of:
+  - the status of their own main arguments: are you mostly done,
+     or do you expect to add more substantial points
+  - the status of their rebuttals: subject of course, to any future
+     changes by the other camps, how close are you to having what
+     you consider a good answer to the other camps' points ?
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 15:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 15:21:04 GMT) (full text, mbox, link).

+ +

Message #310 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: David Hardeman <david@hardeman.nu>, + 727708@bugs.debian.org
+
Cc: leader@debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Thu, 31 Oct 2013 15:17:38 +0000
+
+
David Härdeman writes ("Bug#727708: tech-ctte: Decide which init system to default to in  Debian."):
+> I'm not a DD, just a random contributor, and I haven't been actively 
+> involved in the init system debate at all, nor do I have any stake in 
+> it, though I've followed it with some interest.
+> 
+> Now that the question has been referred to the Technical Committee 
+> (which seems reasonable given the lack of progress in the discussion so 
+> far), it strikes me as somewhat odd that the issue of impartiality/bias 
+> hasn't been discussed in the committee to this point.
+
+Several of the messages on debian-devel in the init system GR proposal
+thread on -devel have discussed this.  Please read that thread, which
+has comments from a number of TC members on this question.
+
+I don't think there would be any value in formally addressing this as
+part of the TC resolution on the init system question.  If nothing
+else, it would be rather circular to have people voting on whether to
+disqualify each other.  There is a clear constitutionally defined
+process for excluding some TC members from voting on some matters,
+which does not apply in the current situation.
+
+If your concern is just that those messages from TC members aren't
+"[discussion] in the committee" as you put it, I think simply
+repeating the earlier messages, as postings to this bug, doesn't seem
+to have much value.
+
+But just for reference here are the urls I found of the contributions
+from TC members and (ex-)DPLs on the subject of bias:
+  http://lists.debian.org/debian-devel/2013/10/msg00692.html
+  http://lists.debian.org/debian-devel/2013/10/msg00747.html
+  http://lists.debian.org/debian-devel/2013/10/msg00777.html
+  http://lists.debian.org/debian-devel/2013/10/msg00699.html
+  http://lists.debian.org/debian-devel/2013/10/msg00702.html
+  http://lists.debian.org/debian-devel/2013/10/msg00818.html
+  http://lists.debian.org/debian-devel/2013/10/msg00946.html
+  http://lists.debian.org/debian-devel/2013/10/msg01014.html
+
+And generally on democracy vs technogracy (if I may put it like that):
+  http://lists.debian.org/debian-devel/2013/10/msg00996.html
+  http://lists.debian.org/debian-devel/2013/10/msg00821.html
+  http://lists.debian.org/debian-devel/2013/10/msg00830.html
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 16:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 16:06:04 GMT) (full text, mbox, link).

+ +

Message #315 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Tollef Fog Heen <tfheen@debian.org>, Michael Biebl <biebl@debian.org>, Marco d'Itri <md@linux.it>, Thomas Goirand <zigo@debian.org>, Steve Langasek <vorlon@debian.org>, Steven Chamberlain <steven@pyro.eu.org>, Patrick Lauer <patrick@gentoo.org>, Alexander Vershilov <qnikst@gentoo.org>, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: init system question before the technical committee
+
Date: Thu, 31 Oct 2013 09:05:07 -0700
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> How long do people think finalising this is going to take ?  There are
+> some potential problems with setting a hard deadline in advance but
+> we're hoping to deal with this matter fairly soon now.
+
+I propose the following approach:
+
+1. Set a date for the first drafts of the various position papers to be
+   finalized
+2. Set a time period for the technical committee to review all of those
+   papers and think about them and possibly have some discussion, and to
+   produce a list of questions or concerns that don't feel adequately
+   addressed
+3. Give all of the position drafters an opportunity to further revise
+   their positions based on feedback from that discussion
+4. Have a vote based on those final position papers
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 19:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Konstantinos Margaritis <markos@freevec.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 19:57:04 GMT) (full text, mbox, link).

+ +

Message #320 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Konstantinos Margaritis <markos@freevec.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system question before the technical committee
+
Date: Thu, 31 Oct 2013 21:44:59 +0200
+
+
[Message part 1 (text/plain, inline)]
+
+Hi all,
+
+I'd just like to mentioned just a small(big? you decide) issue that I
+haven't seen mentioned yet from anyone. Against systemd.
+
+systemd has explicitly mentioned its Linux-only support. Sure, that
+affects kFreeBSD/Hurd now. But changing an init system should be done
+looking ahead *at least* 10 years (we've used the old one for 20+ and
+in itself sysvinit exists for >30 years). Binding Debian to Linux *now*
+will make it pretty certain that soon current non-Linux ports will
+disappear, but also that potential *new* ports will never appear -or
+will be extremely hard/unlikely to be integrated as well as these ones
+have.
+
+So I think this question should really be added as a con to systemd. To
+be honest I'm indifferent, but if I had to, I'd choose either
+OpenRC or upstart, and that would be one of the reasons for that. We
+might not have a new port now, but I doubt anyone could foresee the
+addition of kFreeBSD a year before. With a OS-agnostic init system, you
+leave the option open, with systemd you don't. 
+
+Anyway, enough ranting, I think I've made my point, I'm sure the
+technical committee will make the proper choice. And -I also want to
+say this- contrary to the claims, I see no bias involved, both Steve and
+Colin are extremely well respected Debian Developers. I honestly trust
+them they will do the proper *technically sound* choice.
+
+Regards
+
+Konstantinos
+
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 20:51:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 20:51:08 GMT) (full text, mbox, link).

+ +

Message #325 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Konstantinos Margaritis <markos@freevec.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system question before the technical committee
+
Date: Thu, 31 Oct 2013 20:47:05 +0000
+
+
Konstantinos Margaritis writes ("Bug#727708: init system question before the technical committee"):
+> So I think this question should really be added as a con to systemd.
+
+The way that the Debate wiki system works is that the proponents of
+any particular answer are in charge of the page on that answer.
+
+So it is up to the systemd maintainers whether they want to discuss
+this question on their page.  They do indeed mention it there,
+although fairly briefly.  Of course the proponents of other approaches
+can mention this on their page, as some of them do.
+
+The Debate format does make it rather difficult to collect negative
+views on a particular option.  Given how controversial systemd seems
+to be (compared to the alternatives) I wonder though whether there is
+a sufficient quorum of systemd naysayers to make it worth a separate
+"anything but just systemd" camp.  There's nothing stopping such a
+page being created, ideally by a team led by someone with experience
+of working within and persuading Debian.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 31 Oct 2013 21:09:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 31 Oct 2013 21:09:05 GMT) (full text, mbox, link).

+ +

Message #330 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Theodore Ts'o <tytso@mit.edu>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>, + Wouter Verhelst <wouter@master.debian.org>, + Lucas Nussbaum <leader@debian.org>, + Paul Tagliamonte <paultag@debian.org>, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Thu, 31 Oct 2013 14:07:20 -0700
+
+
[Message part 1 (text/plain, inline)]
+
On Thu, Oct 31, 2013 at 07:20:12AM -0400, Theodore Ts'o wrote:
+> On Thu, Oct 31, 2013 at 01:41:53AM -0700, Steve Langasek wrote:
+> > I'm surprised by this comment.  Very little policy is actually encoded in
+> > upstart's C code; in fact, the only policy I can think of offhand that is is
+> > some basic stuff around filesystems, which, aside from some must-have kernel
+> > filesystems without which it can't boot the rest of the system, should be
+> > entirely overrideable via /etc/fstab.  Perhaps you could expand on what
+> > policies you saw a need to change?
+
+> The details are a bit fuzzy, because this was a quite a while ago,
+> when Upstart was first introduced into Ubuntu, and it was so
+> frustrating that it was what caused me to abandon Ubuntu and switch
+> back to Debian.  The high bit was I couldn't get a particular service
+> to start (it might have been bind, or some such), and I had no idea
+> how to debug the darned thing.  With shell scripts, it's possible to
+> insert "echo debug 1 $variable >> /tmp/debug.log" to figure out what's
+> going on.  With upstart, I had no way of figuring out what was going
+> on, and why it was failing, and the "no user-serviceable parts inside"
+> was extremely frusrtating.
+
+Ah.  Sounds like you may have been hit by upstart's lack of logging support
+for jobs at the time.  Upstart has supported logging of all output from jobs
+(stderr,stdout) since 1.5, which was included in 12.04 LTS.  This was added
+precisely because of that sort of frustrating experience you describe - an
+experience that was shared not only by administrators, but also Ubuntu
+developers trying to debug remaining corner cases in the init system
+integration itself.
+
+So on 12.04 and later, you just look at /var/log/upstart/$job.log to get the
+debugging info you're looking for.  And if you need to debug upstart's own
+state, you can boot with --verbose (or if necessary, --debug) to get useful
+information dumped to kmsg - or turn this on with 'initctl log-priority
+info' after boot.
+
+Cheers,
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 01 Nov 2013 04:45:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Peter Dolding <oiaohm@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 01 Nov 2013 04:45:12 GMT) (full text, mbox, link).

+ +

Message #335 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Peter Dolding <oiaohm@gmail.com>
+
To: rra@debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Fri, 1 Nov 2013 14:42:51 +1000
+
+
Russ Allbery (rra@debian.org)
+
+> In general, upstart's integration with arbitrary actions in shell
+> fragments is considerably better than systemd's, at least based on the
+> documentation I've read.  upstart feels like it provides more useful
+> flexibility
+
+This is in fact a extremely bad idea how it is implemented in upstart.
+
+ExecStartPre=, ExecStartPost=,ExecReload=.... Kind of model in systemd
+is better.
+
+1 the upstart method you have to be watching the version of shell that
+the scripts in the init system are using.   So we are back to the
+sysvinit problem of update bash and hello stack of stuff don't start
+any more.  ExecStartPre=/bin/bash somescript.sh
+
+Think lets say I am a php or python developer.   Upstream.  Why do
+they have to code there init items in bash or some other shell script.
+
+The one property about systemd unit files that is extremely good is
+there are no multi line commands.   Every command is a single line.
+
+script
+    # do some stuff
+    if [ ... ]; then
+        ...
+    fi
+end script
+
+This pattern in upstart is in fact highly bad.
+
+script
+    # do some stuff
+    if [ ... ]; then
+        ...
+    fi
+end script
+
+post-stop script
+    # do some stuff
+    if [ ... ]; then
+        ...
+    fi
+end script
+
+Think about this case.   While editing you by mistake delete something.
+
+script
+    # do some stuff
+    if [ ... ]; then
+        ...
+    fi
+
+post-stop script
+    # do some stuff
+    if [ ... ]; then
+        ...
+    fi
+end script
+
+See what missing.   Now your service start does something completely you wrong.
+
+--script instead gives shell script code that will be executed using /bin/sh.--
+
+Exactly what says that /bin/sh will be bash ash dash.....   Basically
+you need to be able to declare interpreter of script.  Under sysvinit
+you can declare interpreter of script.   systemd and openrc you can
+also declare interpreter of script.   upstart has it hard coded.
+This hard coded bit is bad.
+
+systemd forces you to use many small shell files.  With systemd you
+delete a line you take out a complete command.   You cannot mutate the
+command todo something strange.
+
+We are in a modern age of Languages there is no point taking in a init
+system that forces the usage of one scripting interpreter that can
+change and bring the system down.
+
+
+Peter Dolding
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 01 Nov 2013 04:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 01 Nov 2013 04:54:04 GMT) (full text, mbox, link).

+ +

Message #340 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Peter Dolding <oiaohm@gmail.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Thu, 31 Oct 2013 21:51:39 -0700
+
+
Peter Dolding <oiaohm@gmail.com> writes:
+
+> The one property about systemd unit files that is extremely good is
+> there are no multi line commands.   Every command is a single line.
+
+Yes, that's exactly what I think is obnoxious.  I prefer the upstart
+syntax, which avoids the temptation to write unreadable one-line shell
+constructs.  (Indeed, several have already been posted in recipes in
+various threads on debian-devel about this.)  You can, of course, be
+disciplined about this when writing systemd helper scripts by always
+exernalizing the shell script into a separate file, but I really like that
+upstart lets me inline trivial shell fragments without worrying about
+that while still keeping them readable.
+
+I personally don't find any of your other arguments persuasive (maybe I'm
+too used to writing portable /bin/sh scripts), but I do see where you're
+coming from.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 01 Nov 2013 14:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Matthias Urlichs <matthias@urlichs.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 01 Nov 2013 14:21:04 GMT) (full text, mbox, link).

+ +

Message #345 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Matthias Urlichs <matthias@urlichs.de>
+
To: 727708@bugs.debian.org
+
Subject: systemd vs. whatever
+
Date: Fri, 1 Nov 2013 14:03:06 +0000
+
+
IMHO.
+
+Sorry, but SysV init scripts are an unfixable mess. The sooner we have
+a system which does not have, let alone require, /etc/rc*, the better.
+
+One non-feature of upstart which I happen to care strongly about is its
+use of ptrace(2) to figure out what a job is doing. This destroys any
+attempt to just use "strace foo" as the job, if one really needs to
+figure out what a piece of software is doing wrong. Thanks but no
+thanks.
+
+One important feature of systemd, as Dracut has demonstrated on Fedora,
+is to cleanly shutdown a complex system. The other init systems in
+question do not support this feature. IMHO this is an essential
+feature which we should have had ten years ago. At least.
+
+Again IMHO, the perfect solution is to use systemd for Debian/Linux.
+Non-Linux packages of Debian can simply steal ^w copy Gentoo's OpenRC
+scripts.
+
+(The additional effort packaging OpenRC scripts will be more than
+ amortized the first time somebody finds a bug on Linux by simply
+ running journalctl – instead of grepping through multiple syslog files,
+ finding nothing, running the job under strace, and discovering that the
+ daemonized code wrote its error message to stderr … which it previousy
+ re-opened into /dev/null. Sounds familiar?)
+
+On a more political note: the number of users of non-Linux Debian is …
+let's admit it … tiny verging on negligible. While I do applaud their
+proponents' efforts to build Debian userspace for alternate kernels, I
+don't think it's fair for them to force us to stay with a technically
+inferior solution.
+
+-- 
+-- Matthias Urlichs
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 01 Nov 2013 16:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Miroslaw Baran <miroslaw+c+debbugs@makabra.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 01 Nov 2013 16:24:04 GMT) (full text, mbox, link).

+ +

Message #350 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>
+
To: Matthias Urlichs <matthias@urlichs.de>, 727708@bugs.debian.org
+
Subject: Value of reading other's position statements [was: systemd vs. whatever]
+
Date: Fri, 01 Nov 2013 15:43:40 +0000
+
+
Dear Mr. Urlichs,
+
+You wrote:
+
+> One non-feature of upstart which I happen to care strongly about is its
+> use of ptrace(2) to figure out what a job is doing. This destroys any
+> attempt to just use "strace foo" as the job, if one really needs to
+> figure out what a piece of software is doing wrong. Thanks but no
+> thanks.
+
+Let me allow to quote the upstart's position statement:
+
+> The systemd position statement asserts that you can't attach gdb to a
+> process run by the init system. This is not true, and can only be
+> speculation on the part of the systemd proponents: ptrace is only used
+> during service startup, after which upstart detaches from the process
+> (relying on ordinary waitpid() for notification of service exit). This
+> means that for all intents and purposes, by the time you would actually be
+> in a position to try to attach to the process with gdb, upstart will no
+> longer be tracing it. For valgrind, it's true that this would be less
+> straightforward to do as part of an upstart job. If there were widespread
+> demand for solving this, it wouldn't be difficult; but this doesn't seem
+> like something that has much practical impact. It's unlikely that someone
+> using valgrind for debugging will need to debug via an upstart job or
+> systemd unit, as opposed to running the service directly.
+
+(Cf. https://wiki.debian.org/Debate/initsystem/upstart)
+
+HTH, HAND
+– Mirosław Baran
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 01 Nov 2013 16:33:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 01 Nov 2013 16:33:07 GMT) (full text, mbox, link).

+ +

Message #355 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>
+
Cc: 727708@bugs.debian.org, Matthias Urlichs <matthias@urlichs.de>
+
Subject: Re: Bug#727708: Value of reading other's position statements
+
Date: Fri, 01 Nov 2013 09:30:22 -0700
+
+
Miroslaw Baran <miroslaw+c+debbugs@makabra.org> writes:
+> You wrote:
+
+>> One non-feature of upstart which I happen to care strongly about is its
+>> use of ptrace(2) to figure out what a job is doing. This destroys any
+>> attempt to just use "strace foo" as the job, if one really needs to
+>> figure out what a piece of software is doing wrong. Thanks but no
+>> thanks.
+
+> Let me allow to quote the upstart's position statement:
+
+That statement talks about attaching gdb later in the lifetime of the
+process.  It doesn't address Matthias's point about running the daemon
+itself under strace.
+
+The issues discussed with valgrind here:
+
+>> For valgrind, it's true that this would be less straightforward to do
+>> as part of an upstart job. If there were widespread demand for solving
+>> this, it wouldn't be difficult; but this doesn't seem like something
+>> that has much practical impact. It's unlikely that someone using
+>> valgrind for debugging will need to debug via an upstart job or systemd
+>> unit, as opposed to running the service directly.
+
+are, I believe, the same as the issues with strace, so I think this
+position statement concedes that Matthias is correct and the use of ptrace
+does prevent that particular use case.
+
+I don't personally consider this a major issue, but it is a minor one.  I
+have personally done exactly that (replaced the daemon invocation with one
+run under strace -o /root/tmp/trace) to debug problems in the past.  You
+can attach strace later, just like you can attach gdb later, but that
+doesn't help if the problem you're trying to get a system call trace for
+is during the daemon startup.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 01 Nov 2013 16:33:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 01 Nov 2013 16:33:10 GMT) (full text, mbox, link).

+ +

Message #360 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>, + 727708@bugs.debian.org
+
Cc: Matthias Urlichs <matthias@urlichs.de>
+
Subject: Re: Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]
+
Date: Fri, 1 Nov 2013 16:31:30 +0000
+
+
Miroslaw Baran writes ("Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]"):
+> You wrote:
+> > One non-feature of upstart which I happen to care strongly about is its
+> > use of ptrace(2) to figure out what a job is doing. This destroys any
+> > attempt to just use "strace foo" as the job, if one really needs to
+> > figure out what a piece of software is doing wrong. Thanks but no
+> > thanks.
+> 
+> Let me allow to quote the upstart's position statement:
+
+I have to say that I think that if we were to suggest that packages
+should supply upstart configs, this should be done by having the
+packages use the SIGSTOP protocol, not by having init ptrace them.
+
+Using ptrace like this is a trick one would use if one didn't have the
+source code.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 01 Nov 2013 17:09:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 01 Nov 2013 17:09:19 GMT) (full text, mbox, link).

+ +

Message #365 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Cc: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>, + Matthias Urlichs <matthias@urlichs.de>
+
Subject: Re: Bug#727708: Value of reading other's position statements [was: + systemd vs. whatever]
+
Date: Fri, 1 Nov 2013 10:04:31 -0700
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Nov 01, 2013 at 04:31:30PM +0000, Ian Jackson wrote:
+> Miroslaw Baran writes ("Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]"):
+> > You wrote:
+> > > One non-feature of upstart which I happen to care strongly about is its
+> > > use of ptrace(2) to figure out what a job is doing. This destroys any
+> > > attempt to just use "strace foo" as the job, if one really needs to
+> > > figure out what a piece of software is doing wrong. Thanks but no
+> > > thanks.
+
+> > Let me allow to quote the upstart's position statement:
+
+> I have to say that I think that if we were to suggest that packages
+> should supply upstart configs, this should be done by having the
+> packages use the SIGSTOP protocol, not by having init ptrace them.
+
+> Using ptrace like this is a trick one would use if one didn't have the
+> source code.
+
+I agree.  It would still require some fiddling to make 'expect stop' work
+together with strace anyway, since upstart only cares about SIGSTOP raised
+by upstart's child process, not by the grandchild; so if you actually need
+upstart to know non-racily when the service is started you would need the
+process under trace to SIGSTOP its own parent.  Not elegant, but possible.
+
+Or if you don't need to worry about a non-racy startup for the service
+you're testing, just omit the 'expect' stanza entirely.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 01 Nov 2013 17:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 01 Nov 2013 17:42:04 GMT) (full text, mbox, link).

+ +

Message #370 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve Langasek <vorlon@debian.org>, + 727708@bugs.debian.org
+
Cc: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>, + Matthias Urlichs <matthias@urlichs.de>
+
Subject: Re: Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]
+
Date: Fri, 1 Nov 2013 17:39:15 +0000
+
+
Steve Langasek writes ("Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]"):
+> I agree.  It would still require some fiddling to make 'expect stop' work
+> together with strace anyway, since upstart only cares about SIGSTOP raised
+> by upstart's child process, not by the grandchild; so if you actually need
+> upstart to know non-racily when the service is started you would need the
+> process under trace to SIGSTOP its own parent.  Not elegant, but possible.
+
+Perhaps upstart could be made somehow to spawn strace -p at the
+appropriate moment.
+
+stracing daemon startup (and indeed anything else which seems to be
+malfunctioning) is a powerful tool that the competent but desperate
+sysadmin will reach for in many situations.  Making it difficult is a
+distinct downside for any init replacement.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 01 Nov 2013 18:45:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 01 Nov 2013 18:45:05 GMT) (full text, mbox, link).

+ +

Message #375 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Miroslaw Baran <miroslaw+c+debbugs@makabra.org>, + Matthias Urlichs <matthias@urlichs.de>
+
Subject: Re: Bug#727708: Value of reading other's position statements [was: + systemd vs. whatever]
+
Date: Fri, 1 Nov 2013 11:42:24 -0700
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Nov 01, 2013 at 05:39:15PM +0000, Ian Jackson wrote:
+> Steve Langasek writes ("Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]"):
+> > I agree.  It would still require some fiddling to make 'expect stop' work
+> > together with strace anyway, since upstart only cares about SIGSTOP raised
+> > by upstart's child process, not by the grandchild; so if you actually need
+> > upstart to know non-racily when the service is started you would need the
+> > process under trace to SIGSTOP its own parent.  Not elegant, but possible.
+
+> Perhaps upstart could be made somehow to spawn strace -p at the
+> appropriate moment.
+
+> stracing daemon startup (and indeed anything else which seems to be
+> malfunctioning) is a powerful tool that the competent but desperate
+> sysadmin will reach for in many situations.  Making it difficult is a
+> distinct downside for any init replacement.
+
+Sure; but I think the difficulty here is overstated.  strace and upstart
+service readiness have adverse interactions with one another, but when
+you're debugging a daemon you are unlikely to be doing so under conditions
+where you are simultaneously worried about upstart service readiness races.
+
+I agree with all of the technical critiques here, I just don't see that this
+relatively minor issue, which can be documented and worked around (and
+ultimately, fixed upstream), is something that should be driving Debian's
+choice of init system.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 01 Nov 2013 18:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 01 Nov 2013 18:51:04 GMT) (full text, mbox, link).

+ +

Message #380 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve Langasek <vorlon@debian.org>, + 727708@bugs.debian.org
+
Cc: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>, + Matthias Urlichs <matthias@urlichs.de>
+
Subject: Re: Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]
+
Date: Fri, 1 Nov 2013 18:49:34 +0000
+
+
Steve Langasek writes ("Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]"):
+> I agree with all of the technical critiques here, I just don't see that this
+> relatively minor issue, which can be documented and worked around (and
+> ultimately, fixed upstream), is something that should be driving Debian's
+> choice of init system.
+
+One of the reasons that people are worried about replacing the
+venerable sysvinit, is that they fear the loss of useful (sometimes,
+essential) debugging techniques - of which this is one.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 01 Nov 2013 19:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 01 Nov 2013 19:27:04 GMT) (full text, mbox, link).

+ +

Message #385 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Value of reading other's position statements [was: + systemd vs. whatever]
+
Date: Fri, 1 Nov 2013 12:15:15 -0700
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Nov 01, 2013 at 06:49:34PM +0000, Ian Jackson wrote:
+> Steve Langasek writes ("Bug#727708: Value of reading other's position statements [was: systemd vs. whatever]"):
+> > I agree with all of the technical critiques here, I just don't see that this
+> > relatively minor issue, which can be documented and worked around (and
+> > ultimately, fixed upstream), is something that should be driving Debian's
+> > choice of init system.
+
+> One of the reasons that people are worried about replacing the
+> venerable sysvinit, is that they fear the loss of useful (sometimes,
+> essential) debugging techniques - of which this is one.
+
+But that's an unwarranted fear here.  Sysvinit doesn't give you any way to
+plug in strace without having the exact same kind of service readiness
+problems - either you can background the strace invocation, and then the
+process unblocks the flow of execution immediately and the init script may
+exit before the service is actually working; or you keep strace in the
+foreground, and the init script as a whole never backgrounds.  You have the
+exact same choices in upstart; people are just less familiar with the
+interfaces for doing so, and familiarity isn't a good reason to stick with
+sysvinit indefinitely.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 01 Nov 2013 20:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Matthias Urlichs <matthias@urlichs.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 01 Nov 2013 20:18:04 GMT) (full text, mbox, link).

+ +

Message #390 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Matthias Urlichs <matthias@urlichs.de>
+
To: Russ Allbery <rra@debian.org>
+
Cc: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart ./. ptrace, sockets, etc.
+
Date: Fri, 1 Nov 2013 20:14:09 +0000
+
+
On Fri, 01 Nov 2013 09:30:22 -0700
+Russ Allbery <rra@debian.org> wrote:
+
+> I don't personally consider this a major issue
+
+It's probably not something that cannot be worked around in some way,
+as the upstart position statement asserts (which by the way I *have*
+read).
+
+However, IMHO systemd's cgroups solution makes a whole lot more sense
+from a technical PoV, and also fixes a couple of other problems which
+SysV init is notorious for.
+
+Apropos of upstart's position statement, it says that
+> upstart provides more granular definitions of service readiness
+> that are not available in systemd. 
+
+Personally I consider this to be a bug. A daemon either can accept
+requests, or it cannot. A file system is either mounted, or it is
+not. Anything else is internal fiddling by the init subsystem and
+should not be of any interest, or in fact visible (unless you're
+debugging daemon startup), to anybody else.
+
+… and another thing, speaking about accepting requests:
+
+One of the interesting side effects of socket activation, as
+implemented by systemd, is that one can restart a service (even one
+using multiple sockets and dbus and whatnot) without losing a single
+request.
+
+AFAIK, upstart cannot do that: its socket activation only passes a
+single socket to the daemon, if I interpret the manpage at 
+http://manpages.ubuntu.com/manpages/raring/en/man7/socket-event.7.html
+correctly.
+
+This is an example of the fundamental difference between upstart's
+model, which is based on events, and systemd's, which relies on
+service states and dependencies.
+IMHO the systemd model makes a lot more sense, from the PoV of a system
+administrator. You can easily ask systemd which preconditioon prevents a
+daemon from starting up. Asking upstart which event ultimately failed
+to fire for (one of?) a daemon's "start on" conditions to be fulfilled
+is a more "interestig" problem.
+
+*****
+
+My personal bottom line is that systemd has a whole lot of features
+which I am already taking for granted -- I started using systemd as my
+primary init system on a wide range of Debian systems since it showed
+up in Experimental -- and which other init implementations do not
+provide. To be perfectly frank, I'd rather switch distros than stop
+using systemd.
+
+IMHO, maintaining "duplicate" init scripts for <whatever we decide
+non-Linux Debian systems should standardize on> would consume far less
+manpower than re-implementing systemd's journal, and re-implementing a
+cgroups controller, and getting whatever we decide on to work with
+kdbus in the future, and getting logind and whatnot to run without
+systemd, and getting gnome (and maybe others) to not require systemd
+as PID 1, … the list goes on.
+
+To be fair, some of this work is going to be necessary anyway, assuming
+that Debian continues to treat non-Linux kernels as first-class
+citizens. However, the burden of doing it (and to live with the
+inevitable bugs) should be carried by those who require it.
+
+-- 
+-- Matthias Urlichs
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 02 Nov 2013 02:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 02 Nov 2013 02:57:04 GMT) (full text, mbox, link).

+ +

Message #395 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Fri, 1 Nov 2013 21:52:22 -0500
+
+
[Message part 1 (text/plain, inline)]
+
Hi Russ,
+
+On Tue, Oct 29, 2013 at 04:16:04PM -0700, Russ Allbery wrote:
+
+> Therefore, I think it's important for arguments against using systemd to
+> somehow engage directly with the questions about functionality.  Either
+> there needs to be an argument that the functionality is not important and
+> can be done without (which raises questions about how one would build
+> GNOME in such an environment), or there needs to be some sort of plan for
+> how equivalent functionality to systemd will be provided.
+
+I agree; and the plan from the Upstart side is to ensure that equivalent
+functionality remains available, but it's premature to try to flesh this
+plan out in any detail while the interfaces themselves are not yet
+finalized.
+
+For the TC decision, what kind of information are you looking for about the
+plans, beyond "the Ubuntu developers expect to need to address this before
+upgrading from systemd logind 204 and will hold at 204 until a correct
+solution is known"?
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 02 Nov 2013 03:12:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 02 Nov 2013 03:12:14 GMT) (full text, mbox, link).

+ +

Message #400 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Fri, 01 Nov 2013 20:11:38 -0700
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> For the TC decision, what kind of information are you looking for about
+> the plans, beyond "the Ubuntu developers expect to need to address this
+> before upgrading from systemd logind 204 and will hold at 204 until a
+> correct solution is known"?
+
+I think the right way to put this is that systemd has significant
+development resources behind it and is working in fairly close cooperation
+with both kernel developers and GNOME developers to make available new
+kernel functionality and to provide implementations of various other
+interfaces.  Multiple implementations are good, but there's potentially an
+ongoing stream of development to keep up with, and (putting aside
+arguments about coupling and appropriate ways to integrate that
+functionality) I believe there is a general agreement that functionality
+is desirable and will be used by other software that Debian wants to
+provide.
+
+So, one question is whether anyone outside of Canonical is in a position
+to help with the heavy development (as opposed to the occasional patch).
+Red Hat is clearly committed to systemd, and there's some convergence
+towards it among other RPM-based distributions, so long-term resources for
+systemd don't seem to be in doubt.  Canonical is a smaller company, and
+does not always have the resources to keep projects for which it is the
+sole upstream vibrant and growing, even when it seems strongly committed
+to them (c.f. bzr).
+
+If Canonical *is* the sole upstream, the upstream future here is troubling
+to me, particularly given Canonical's current strategic direction towards
+Unity.  To give a specific example of the sort of thing that I'm worried
+about, suppose that GNOME Shell wants a new piece of functionality that
+is, on Red Hat, provided via kernel functionality managed by systemd, but
+Unity has no need for that functionality.  Is Canonical going to develop
+an upstart equivalent in support of GNOME Shell, when it is pushing Unity
+over GNOME Shell?
+
+Maybe this example is very artificial; I know it's not clear what piece of
+functionality would be required from the init system and surrounding
+infrastructure that would be required by GNOME Shell and not Unity.  But I
+think it's at least conceivable given different priorities around such
+things as multiseat, and in any case it provides a concrete example of the
+sort of scenario I'm worried about.
+
+In other words, it's not so much a specific roadmap as it is a roadmap
+approach and resource committment.  Debian, by choosing a default init
+system, is potentially investing a lot of developer effort on supporting
+that platform for packaged daemons, somewhat akin to an organization
+choosing a product on which to base a required piece of internal
+functionality.  I'm therefore asking the same sort of question that I
+would ask of a vendor whose products we were evaluating for my day job:
+what guarantees do we have that this product will continue to be developed
+and supported going forward?
+
+The situation with free software is a bit different from a vendor, of
+course, since Debian could always patch or even pick up development of the
+software ourselves, but I think we'd all agree that Debian ending up
+committed to a system service family (since that's really what we're
+talking about here -- not just the init system itself, but also how the
+equivalents, forks, or refactorings of logind, D-Bus, cgroups, udev, and
+so forth will be handled) whose pace of development has slowed to the
+extent that bzr's has would be a very bad outcome.
+
+At least superficially, that outcome looks more likely to me with upstart
+than it does with systemd, so I'm looking for some reassurance for why the
+risk of ending up in that situation is low.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 02 Nov 2013 11:45:11 GMT) (full text, mbox, link).

+ +

Message #403 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Sat, 02 Nov 2013 12:40:19 +0100
+
+
Hi,
+
+Russ Allbery <rra@debian.org> writes:
+> Steve Langasek <vorlon@debian.org> writes:
+>
+>> For the TC decision, what kind of information are you looking for about
+>> the plans, beyond "the Ubuntu developers expect to need to address this
+>> before upgrading from systemd logind 204 and will hold at 204 until a
+>> correct solution is known"?
+>
+[...]
+>
+> If Canonical *is* the sole upstream, the upstream future here is troubling
+> to me, particularly given Canonical's current strategic direction towards
+> Unity.  To give a specific example of the sort of thing that I'm worried
+> about, suppose that GNOME Shell wants a new piece of functionality that
+> is, on Red Hat, provided via kernel functionality managed by systemd, but
+> Unity has no need for that functionality.  Is Canonical going to develop
+> an upstart equivalent in support of GNOME Shell, when it is pushing Unity
+> over GNOME Shell?
+>
+> Maybe this example is very artificial; I know it's not clear what piece of
+> functionality would be required from the init system and surrounding
+> infrastructure that would be required by GNOME Shell and not Unity.  But I
+> think it's at least conceivable given different priorities around such
+> things as multiseat, and in any case it provides a concrete example of the
+> sort of scenario I'm worried about.
+
+Thanks for finding a nice wording for this. This is also my main concern
+in the init systemd discussions: upstart might end up playing catch-up,
+but stay behind in the end.
+
+In Lennart's Google+ post referenced earlier in the discussion[1] there
+was also an example of new functionality in systemd 205+ that I'm not
+sure Canonical has a business interest in supporting (namely "all the
+nifty stuff that allows Wayland to run nicely without privs is
+implemented in the newer logind versions"). As Canonical has decided to
+go with Mir instead of Wayland, these features might not get backported
+to their logind fork (unless they are also required there, I don't
+know).
+
+So having a more concrete roadmap than "we might just stay at logind 204
+forever" from the UpstarT proponents seems very important to me.
+
+  [1] <https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf>
+
+Ansgar
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 02 Nov 2013 11:54:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 02 Nov 2013 11:54:09 GMT) (full text, mbox, link).

+ +

Message #408 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Tollef Fog Heen <tfheen@debian.org>, Michael + Biebl <biebl@debian.org>
+
Subject: Re: Bug#727708: init system question before the technical committee
+
Date: Sat, 02 Nov 2013 12:50:52 +0100
+
+
Hi Ian,
+
+Le jeudi 31 octobre 2013 à 15:01 +0000, Ian Jackson a écrit : 
+> Perhaps it would be good if the camp leader(s) for each camp would
+> reply with a summary of:
+>   - the status of their own main arguments: are you mostly done,
+>      or do you expect to add more substantial points
+>   - the status of their rebuttals: subject of course, to any future
+>      changes by the other camps, how close are you to having what
+>      you consider a good answer to the other camps' points ?
+
+With some help from the other systemd proponents, I have added today
+what I consider the final touch for the systemd statement page. It is
+now mostly finished, including the rebuttals, and should only need new
+updates for spelling mistakes or minor inaccuracies.
+
+Cheers,
+-- 
+ .''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 04 Nov 2013 10:27:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Carlos Alberto Lopez Perez <clopez@igalia.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 04 Nov 2013 10:27:10 GMT) (full text, mbox, link).

+ +

Message #413 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Carlos Alberto Lopez Perez <clopez@igalia.com>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org, Steve Langasek <vorlon@debian.org>
+
Subject: Re: Re: Bug#727708: tech-ctte: Decide which init system to default + to in Debian.
+
Date: Mon, 04 Nov 2013 11:23:26 +0100
+
+
[Message part 1 (text/plain, inline)]
+
On 02/11/13 04:11, Russ Allbery wrote:
+> I think the right way to put this is that systemd has significant
+> development resources behind it and is working in fairly close cooperation
+> with both kernel developers and GNOME developers to make available new
+> kernel functionality and to provide implementations of various other
+> interfaces.  Multiple implementations are good, but there's potentially an
+> ongoing stream of development to keep up with, and (putting aside
+> arguments about coupling and appropriate ways to integrate that
+> functionality) I believe there is a general agreement that functionality
+> is desirable and will be used by other software that Debian wants to
+> provide.
+> 
+> So, one question is whether anyone outside of Canonical is in a position
+> to help with the heavy development (as opposed to the occasional patch).
+> Red Hat is clearly committed to systemd, and there's some convergence
+> towards it among other RPM-based distributions, so long-term resources for
+> systemd don't seem to be in doubt.  Canonical is a smaller company, and
+> does not always have the resources to keep projects for which it is the
+> sole upstream vibrant and growing, even when it seems strongly committed
+> to them (c.f. bzr).
+
+Regarding the development force behind each project, I find the following
+comparison at Ohloh very illustrative
+
+https://www.ohloh.net/p/compare?project_0=openrc&project_1=upstart&project_2=systemd
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 04 Nov 2013 17:21:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 04 Nov 2013 17:21:10 GMT) (full text, mbox, link).

+ +

Message #418 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Carlos Alberto Lopez Perez <clopez@igalia.com>
+
Cc: 727708@bugs.debian.org, Steve Langasek <vorlon@debian.org>
+
Subject: Re: Bug#727708: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Mon, 04 Nov 2013 09:19:40 -0800
+
+
Carlos Alberto Lopez Perez <clopez@igalia.com> writes:
+
+> Regarding the development force behind each project, I find the following
+> comparison at Ohloh very illustrative
+
+> https://www.ohloh.net/p/compare?project_0=openrc&project_1=upstart&project_2=systemd
+
+This isn't really a fair comparison since systemd as a project contains
+considerably more subsystems than upstart or OpenRC do.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 05 Nov 2013 03:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Peter Dolding <oiaohm@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 05 Nov 2013 03:57:04 GMT) (full text, mbox, link).

+ +

Message #423 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Peter Dolding <oiaohm@gmail.com>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Tue, 5 Nov 2013 13:54:49 +1000
+
+
On Fri, Nov 1, 2013 at 2:51 PM, Russ Allbery <rra@debian.org> wrote:
+> Peter Dolding <oiaohm@gmail.com> writes:
+>
+>> The one property about systemd unit files that is extremely good is
+>> there are no multi line commands.   Every command is a single line.
+>
+> Yes, that's exactly what I think is obnoxious.  I prefer the upstart
+> syntax, which avoids the temptation to write unreadable one-line shell
+> constructs.  (Indeed, several have already been posted in recipes in
+> various threads on debian-devel about this.)  You can, of course, be
+> disciplined about this when writing systemd helper scripts by always
+> exernalizing the shell script into a separate file, but I really like that
+> upstart lets me inline trivial shell fragments without worrying about
+> that while still keeping them readable.
+http://www.freedesktop.org/software/systemd/man/systemd.service.html
+
+Systemd in fact support the exec lines being written many times.
+
+ExecStart= is recommend against being used many due to using XDG
+desktop processing by somethings.   But that is something can could be
+changed in time.  Personally I think it should be changed.
+http://www.freedesktop.org/software/systemd/man/systemd.service.html
+
+ExecStartPre=, ExecStartPost= can be written many times.
+
+ExecStartPre= rm somewhere
+ExecStartPre= touch somewhere
+
+That is in fact valid and both will run in order.  From the start of
+unit file to end.
+
+In fact lot of cases I see one line entries in systemd and I see bad
+form.  Unless one line has like if or for statements its really bad
+form inside systemd.
+
+Yes systemd supports ; split statements most cases this should not be
+used in most cases.  Its cleaner in the log to see what statement
+failed the multi line way.
+
+Really I would like to see some of those unreadable single line
+script.    I am a little bit suspect they will be people not
+understanding systemd.   So failing to split over many Exec statements
+for clear readability.
+
+Even using upstart you don't stop people from doing unreadable shell script.
+>
+> I personally don't find any of your other arguments persuasive (maybe I'm
+> too used to writing portable /bin/sh scripts), but I do see where you're
+> coming from.
+
+I have been the the receiving end of too many not portable shell
+scripts.  My big problem about not being able to set it is what if
+Ubuntu and Debian decide on a different /bin/sh to each other.   No
+way to set no way to work around this with current upstart.
+
+Its not like /bin/sh has not changed in the past.
+https://wiki.ubuntu.com/DashAsBinSh  Has everyone forgot the screw ups
+that happened when bash was swapped for dash with the old sysvinit.
+They were workable around under sysvinit by setting the scripts that
+required bash to bash.   So means to change the shell is remembering
+historic stuff ups.
+
+There is already complaints with upstart with canonical controlling
+the upstream.  So we have to be very careful with dependencies.
+
+Basically upstart is lacking one key feature.   If it not fixed it
+will come back and bite us.   Really I would like to see this fixed
+before debian takes up upstart if debian takes up upstart at all.
+
+Openrc and systemd both can work around the prior issues that have
+effected sysvinit in history.
+
+Replacement we have to be able to beat up like sysvinit and still have it work.
+
+SourcePath= option exists in systemd to mark a location of a file that
+the current file is generated from.   I don't know openrc or upstart
+to say if either of them have this functionality as well.
+
+History tells us what is likely to happen again.   History is what
+against taking in upstart in it current form.    Upstart in it current
+form cannot get past the same issues sysvinit got around without major
+trouble.   It should only be a minor fix to add a means to define
+/bin/sh as a different executable per service.
+
+Peter Dolding
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 05 Nov 2013 04:06:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 05 Nov 2013 04:06:05 GMT) (full text, mbox, link).

+ +

Message #428 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Peter Dolding <oiaohm@gmail.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Mon, 04 Nov 2013 20:02:35 -0800
+
+
Peter Dolding <oiaohm@gmail.com> writes:
+
+> ExecStartPre=, ExecStartPost= can be written many times.
+
+> ExecStartPre= rm somewhere
+> ExecStartPre= touch somewhere
+
+That really doesn't help, because...
+
+> In fact lot of cases I see one line entries in systemd and I see bad
+> form.  Unless one line has like if or for statements its really bad
+> form inside systemd.
+
+...of this.  If you can't write the scripts with proper block structure,
+it's actually better to just externalize them in a separate file rather
+than doing something this awful to try to inline them.
+
+I don't think you're going to convince me to like this syntax.  :)  But
+it's a minor issue.
+
+> Basically upstart is lacking one key feature.  If it not fixed it will
+> come back and bite us.  Really I would like to see this fixed before
+> debian takes up upstart if debian takes up upstart at all.
+
+I'm afraid there is little chance you will manage to convince me that this
+is a key feature.  I've been writing portable shell scripts for years, and
+Debian has been dealing with shell portability issues for years.
+Regardless of what we do with the init system, we will still have to deal
+with this with maintainer scripts, etc.  I do see why you're concerned,
+but I just don't see this as critical compared to other issues under
+discussion.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 05 Nov 2013 04:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 05 Nov 2013 04:18:04 GMT) (full text, mbox, link).

+ +

Message #433 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: 727708@bugs.debian.org
+
Subject: Problems with upstarts event model
+
Date: Mon, 04 Nov 2013 19:53:33 -0800
+
+
Hi,
+
+I just want to raise one issue that I think has not been adequately
+addressed by any of the position statements (it has unfortunately been
+deleted from the upstart page and been trimmed down a lot on the systemd
+page):
+
+I think an important drawback of upstart is the idea of treating
+dependencies as events.
+
+The systemd statement already mentions correctly that upstart turns the
+dependency chain “upside down”, because it starts a service as soon as
+all its dependencies are ready, instead of starting the dependencies of
+a service when the service itself should be started.
+
+This has practical implications as well. When trying to debug why a
+service isn't starting, it's simpler to investigate which dependency
+couldn't be started than to figure out which event was not emitted for
+what reason at some point in the past.
+
+
+Moreover (and, in my opinion, most importantly), by treating
+dependencies as events ("start A if B has started" rather than the
+conventional "A requires B"), native upstart jobs can create "event
+loops" which can block starting of all services in the loop. Example:
+https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/964207 and
+discussion at https://lists.debian.org/debian-devel/2013/05/msg01500.html
+
+As far as I can tell, something like this can not happen with systemd units.
+
+
+Best,
+-Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 05 Nov 2013 04:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 05 Nov 2013 04:36:04 GMT) (full text, mbox, link).

+ +

Message #438 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Mon, 04 Nov 2013 20:32:45 -0800
+
+
On 10/31/2013 09:51 PM, Russ Allbery wrote:
+> You can, of course, be
+> disciplined about this when writing systemd helper scripts by always
+> exernalizing the shell script into a separate file, but I really like that
+> upstart lets me inline trivial shell fragments without worrying about
+> that while still keeping them readable.
+
+I can very well imagine that this is how sysv init scripts started out.
+"Let's make them shell scripts, it's so convenient to be able to place
+that extra bit of initialization code in there..."
+
+In other words: the ability to add extra features to upstart jobs by
+"extending" them with shell scripts could eventually end up making them
+just as complex as sysv scripts. I am guilty of having written some
+rather complicated trickery in upstart shell sections myself, so I know
+how tempting it is.
+
+(In my case, I was mostly working around my still insufficient
+understanding of the upstart event system to start a job only in some
+specific conditions. Just coding the condition and stopping the job in
+its pre-start script (in itself a rather weird concept, but it came from
+the upstart cookbook) turned out to be quicker and easier, but it
+certainly wasn't the proper solution...)
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 05 Nov 2013 09:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 05 Nov 2013 09:03:04 GMT) (full text, mbox, link).

+ +

Message #443 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Tue, 05 Nov 2013 09:59:35 +0100
+
+
]] Russ Allbery 
+
+> Peter Dolding <oiaohm@gmail.com> writes:
+> 
+> > ExecStartPre=, ExecStartPost= can be written many times.
+> 
+> > ExecStartPre= rm somewhere
+> > ExecStartPre= touch somewhere
+> 
+> That really doesn't help, because...
+> 
+> > In fact lot of cases I see one line entries in systemd and I see bad
+> > form.  Unless one line has like if or for statements its really bad
+> > form inside systemd.
+> 
+> ...of this.  If you can't write the scripts with proper block structure,
+> it's actually better to just externalize them in a separate file rather
+> than doing something this awful to try to inline them.
+> 
+> I don't think you're going to convince me to like this syntax.  :)  But
+> it's a minor issue.
+
+Disliking the syntax is of course fair enough. :-) In general, there
+should be enough declarative knobs that you can twiddle that you don't
+need to write shell scripts.  That's the idea, at least.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 05 Nov 2013 09:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 05 Nov 2013 09:09:05 GMT) (full text, mbox, link).

+ +

Message #448 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Tue, 5 Nov 2013 10:05:40 +0100
+
+
* Russ Allbery (rra@debian.org) [131104 18:21]:
+> Carlos Alberto Lopez Perez <clopez@igalia.com> writes:
+> 
+> > Regarding the development force behind each project, I find the following
+> > comparison at Ohloh very illustrative
+> 
+> > https://www.ohloh.net/p/compare?project_0=openrc&project_1=upstart&project_2=systemd
+> 
+> This isn't really a fair comparison since systemd as a project contains
+> considerably more subsystems than upstart or OpenRC do.
+
+Actually I think this comparison contains valuable data points.
+However, one shouldn't think of it as "more code is always better" -
+in fact, I have often made the experience that too much code in
+critical systems is a problem by itself. And as you pointed out, it
+doesn't show the amount of development force correctly.
+
+However, it shows two things: one is as you said that systemd contains
+many more subsystems as the others (whether this is good or not is a
+different question), the other is that code documentation seems to be
+not as verbose as for upstart or OpenRC (in spite of the remarks I saw
+earlier about how much documentation is there).
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 05 Nov 2013 10:15:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Chris.Knadle@coredump.us:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 05 Nov 2013 10:15:08 GMT) (full text, mbox, link).

+ +

Message #453 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Chris Knadle <Chris.Knadle@coredump.us>
+
To: Andreas Barth <aba@ayous.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Tue, 05 Nov 2013 04:39:26 -0500
+
+
On Tuesday, November 05, 2013 10:05:40 Andreas Barth wrote:
+[...] 
+> However, it shows two things: one is as you said that systemd contains
+> many more subsystems as the others (whether this is good or not is a
+> different question), the other is that code documentation seems to be
+> not as verbose as for upstart or OpenRC (in spite of the remarks I saw
+> earlier about how much documentation is there).
+
+On the latter point -- according to Ohloh, in OpenRC [1] and Upstart [2], 
+19% of the code is comments, where for SystemD [3] it's 11%.
+
+1: https://www.ohloh.net/p/openrc/factoids#FactoidCommentsAverage
+2: https://www.ohloh.net/p/upstart/factoids#FactoidCommentsAverage
+3: https://www.ohloh.net/p/systemd/factoids#FactoidCommentsLow
+
+  -- Chris
+
+--
+Chris Knadle
+Chris.Knadle@coredump.us
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 06 Nov 2013 00:06:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 06 Nov 2013 00:06:05 GMT) (full text, mbox, link).

+ +

Message #458 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Wed, 6 Nov 2013 01:03:06 +0100
+
+
* Russ Allbery (rra@debian.org) [131102 04:12]:
+> If Canonical *is* the sole upstream, the upstream future here is troubling
+> to me, particularly given Canonical's current strategic direction towards
+> Unity.  To give a specific example of the sort of thing that I'm worried
+> about, suppose that GNOME Shell wants a new piece of functionality that
+> is, on Red Hat, provided via kernel functionality managed by systemd, but
+> Unity has no need for that functionality.  Is Canonical going to develop
+> an upstart equivalent in support of GNOME Shell, when it is pushing Unity
+> over GNOME Shell?
+> [...]
+> In other words, it's not so much a specific roadmap as it is a roadmap
+> approach and resource committment.  Debian, by choosing a default init
+> system, is potentially investing a lot of developer effort on supporting
+> that platform for packaged daemons, somewhat akin to an organization
+> choosing a product on which to base a required piece of internal
+> functionality.
+
+I would like to ask this question even a bit more general (for all
+involved init systems): 
+
+How much would we have "vendor lock-in" by each init system? Means, is
+there more software except the pure init system we might need to take
+if we switch to that init system. Also, what can we expect for the
+future? How much does the roadmap allow for exchanging other services
+without changing the init service? And also looking from the other
+perspective, if we would change the init service later on, which of
+the nearby services would we loose at the same moment as the init
+service?
+
+For upstart, this might be the case described above.
+
+For systemd, just one example (which might be as artificial as the
+upstart example): there are more services included in the code base,
+like IIRC a syslog server. Can we continue to run different services,
+or do we de-facto need to switch to systemds implementations of the
+services? Would upstream be interested to keep the non-systemds
+implementation of the accompying services working?
+
+(Examples for the other init systems are also possible, but I think I
+can save the time of writing them down. But I would also be
+interessted in answer for those.)
+
+
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 06 Nov 2013 00:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 06 Nov 2013 00:21:04 GMT) (full text, mbox, link).

+ +

Message #463 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Andreas Barth <aba@ayous.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Tue, 05 Nov 2013 16:16:22 -0800
+
+
Andreas Barth <aba@ayous.org> writes:
+
+> I would like to ask this question even a bit more general (for all
+> involved init systems):
+
+> How much would we have "vendor lock-in" by each init system? Means, is
+> there more software except the pure init system we might need to take if
+> we switch to that init system. Also, what can we expect for the future?
+> How much does the roadmap allow for exchanging other services without
+> changing the init service? And also looking from the other perspective,
+> if we would change the init service later on, which of the nearby
+> services would we loose at the same moment as the init service?
+
+I think it's worth noting that there are a couple of angles on this.  One
+is the direction that you note, but there's also the inverse direction:
+committing to a particular init system may mean that we *can't* run some
+other piece of software, at least without additional work on our side that
+may constitute a fork.
+
+For example, we're apparently already in that situation with logind.  In
+order to run logind with an init system other than systemd, we will need
+to fork it (to a greater or lesser extent), possibly in conjunction with
+Ubuntu and Gentoo.  It would be good to know if there are, or will be,
+other cases like that.
+
+We'll want to look at both sides of that question, and try to understand
+how much work like that is potentially on the horizon with the various
+choices.
+
+> For systemd, just one example (which might be as artificial as the
+> upstart example): there are more services included in the code base,
+> like IIRC a syslog server. Can we continue to run different services, or
+> do we de-facto need to switch to systemds implementations of the
+> services?
+
+Yes -- I think both your question and my question are two sides of the
+same coin, and what side we're looking at in any given case is largely
+determined by whether there *are* any other implementations of that
+particular service.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 06 Nov 2013 00:45:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 06 Nov 2013 00:45:05 GMT) (full text, mbox, link).

+ +

Message #468 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Wed, 6 Nov 2013 01:44:20 +0100
+
+
* Russ Allbery (rra@debian.org) [131106 01:21]:
+> We'll want to look at both sides of that question, and try to understand
+> how much work like that is potentially on the horizon with the various
+> choices.
+
+Yes, and I hope that all potential init systems add appropriate
+information to their position page (on both sides of this coin).
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 06 Nov 2013 07:45:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Thijs Kinkhorst" <thijs@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 06 Nov 2013 07:45:11 GMT) (full text, mbox, link).

+ +

Message #473 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Thijs Kinkhorst" <thijs@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Wed, 6 Nov 2013 08:37:06 +0100
+
+
On Wed, November 6, 2013 01:16, Russ Allbery wrote:
+> We'll want to look at both sides of that question, and try to understand
+> how much work like that is potentially on the horizon with the various
+> choices.
+
+Do you? In the past Debian has not shied away from making the choice that
+it considers technically (or philosophically) the most sound, not the one
+that implies the least amount of work. The choice will probably be made on
+just a few high-level factors, such as the chosen approach (dependency vs
+event based), best user experience and/or licensing.
+
+Facts are being gathered about the percentage of code comments, but I it
+seems unlikely that Debian would reject a solution that it thinks is
+architecturally superior because of it having fewer code comments.
+
+
+Cheers,
+Thijs
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 06 Nov 2013 08:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 06 Nov 2013 08:15:04 GMT) (full text, mbox, link).

+ +

Message #478 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: "Thijs Kinkhorst" <thijs@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Wed, 06 Nov 2013 00:10:49 -0800
+
+
"Thijs Kinkhorst" <thijs@debian.org> writes:
+> On Wed, November 6, 2013 01:16, Russ Allbery wrote:
+
+>> We'll want to look at both sides of that question, and try to
+>> understand how much work like that is potentially on the horizon with
+>> the various choices.
+
+> Do you? In the past Debian has not shied away from making the choice
+> that it considers technically (or philosophically) the most sound, not
+> the one that implies the least amount of work. The choice will probably
+> be made on just a few high-level factors, such as the chosen approach
+> (dependency vs event based), best user experience and/or licensing.
+
+Well, my choice won't be made on just those few high-level factors, for
+whatever that matters.  And I seem to have one.  :)
+
+Technically the most sound and implying the least amount of work are not
+two unrelated factors.  Apply reductio ad absurdum: vaporware is not
+technicallly sound, regardless of what lofty design principles underlie
+it.
+
+We need to be realistic here about what we, as a project, can accomplish.
+The ideal init system for Debian is, almost by definition, the one we
+write ourselves from scratch to do exactly what we want it to do.  There's
+a good reason why no one has proposed that.  We have certain realistic
+limitations about what we can and can't do as a project, which in this
+space, among other things, require us to adopt an existing project rather
+than writing our ideal implementation from scratch.
+
+The same also applies to other subsystems that go into our distribution.
+We aren't going to, realistically, write our own new syslog
+implementation, or our own new user session manager, or our own udev
+implementation, or our own desktop environment, or our own kernel.  We're
+going to use existing projects, maintained by other people with other
+goals, some with goals that have nothing to do with Debian's goals.  We
+need to choose useful, interoperable sets of those projects that can, at
+the end of the day, come together into a coherent system for our users.
+Since that's why we're all here.
+
+As part of that process, we may well contribute to those projects, perhaps
+substantially.  But Debian is not an island to itself, and if we pretend
+we are, we won't produce the quality of distribution that we want to
+produce.  We're part of a larger ecosystem, and that has quite a bit to do
+with the specific decision of how we choose our init system.
+
+> Facts are being gathered about the percentage of code comments, but I it
+> seems unlikely that Debian would reject a solution that it thinks is
+> architecturally superior because of it having fewer code comments.
+
+That metric is trying to get at something that we do care about, namely is
+a particular upstream project going to be excessively buggy (poorly
+documented code implies harder to understand code implies people make
+mistakes when they change it) and can we understand it well enough to make
+whatever integration changes we need to make to it.
+
+Percentage of code comments is a very rough and somewhat dubious metric to
+use for getting at that question, but it's getting at something real.
+Just like the discussion that we had about syntax is getting at something
+real around the UI of the init system that we will expose to our users,
+even if the specific question of how one embeds shell commands in the
+startup script is not one on which the choice of init system will turn.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 06 Nov 2013 11:51:18 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Thijs Kinkhorst" <thijs@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 06 Nov 2013 11:51:18 GMT) (full text, mbox, link).

+ +

Message #483 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Thijs Kinkhorst" <thijs@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Wed, 6 Nov 2013 12:46:17 +0100
+
+
On Wed, November 6, 2013 09:10, Russ Allbery wrote:
+> "Thijs Kinkhorst" <thijs@debian.org> writes:
+>> On Wed, November 6, 2013 01:16, Russ Allbery wrote:
+>
+>>> We'll want to look at both sides of that question, and try to
+>>> understand how much work like that is potentially on the horizon with
+>>> the various choices.
+>
+>> Do you? In the past Debian has not shied away from making the choice
+>> that it considers technically (or philosophically) the most sound, not
+>> the one that implies the least amount of work. The choice will probably
+>> be made on just a few high-level factors, such as the chosen approach
+>> (dependency vs event based), best user experience and/or licensing.
+>
+> Well, my choice won't be made on just those few high-level factors, for
+> whatever that matters.  And I seem to have one.  :)
+>
+> Technically the most sound and implying the least amount of work are not
+> two unrelated factors.  Apply reductio ad absurdum: vaporware is not
+> technicallly sound, regardless of what lofty design principles underlie
+> it.
+>
+> We need to be realistic here about what we, as a project, can accomplish.
+> The ideal init system for Debian is, almost by definition, the one we
+> write ourselves from scratch to do exactly what we want it to do.  There's
+> a good reason why no one has proposed that.  We have certain realistic
+> limitations about what we can and can't do as a project, which in this
+> space, among other things, require us to adopt an existing project rather
+> than writing our ideal implementation from scratch.
+
+I doubt that Debian writing something from scratch would not be realistic:
+Debian actually has chosen to go the self-implementing route in key
+infrastructures the past, for example for the installer or package
+managers.
+
+Nonetheless, that's not relevant here. There are several likely candidates
+in existence, so the choice will not be to use something existing versus
+implementing from scratch; the choice will be between existing projects,
+and given that, the amount of work per system may differ but the
+difference will not likely be that great that it's unsurmountable, as they
+exist, they have active upstreams and they have successfully been used in
+other distributions.
+
+> That metric is trying to get at something that we do care about, namely is
+> a particular upstream project going to be excessively buggy (poorly
+> documented code implies harder to understand code implies people make
+> mistakes when they change it) and can we understand it well enough to make
+> whatever integration changes we need to make to it.
+
+I do agree that it's nice to have the very best code quality available,
+but in the long run, having underdocumented code is annoying and may lead
+to bugs, but bugs can be fixed and documentation improved; changing the
+basic architecture of the system is unlikely to be fixed. I really believe
+we are going to regret it if Debian chooses the architecture it likes less
+for the reason that it has more documentation.
+
+Which system has better code documentation is not relevant. The relevant
+question is whether a system has adequate documentation, regardless of the
+documentation of other systems.
+
+I think I would like it better if the choice process was split in two.
+First, for each candidate system assess the supportability in Debian. Code
+quality can be a factor here. Can we reasonably run this? (Given that the
+two major choices have been used by several other distributions probably
+qualifies them, but Debian can make its own assessment here.) Then, from
+the shortlist of candidates, choose the 'best' one based on high-level but
+fundamental criteria, like architecture, licensing etc.
+
+Currently, it seems these two steps (is it supportable vs what should be
+the default) are conflated and a big matrix of facts of the different
+systems is built.
+
+
+Cheers,
+Thijs
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 06 Nov 2013 12:33:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 06 Nov 2013 12:33:07 GMT) (full text, mbox, link).

+ +

Message #488 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: Thijs Kinkhorst <thijs@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Wed, 6 Nov 2013 13:29:21 +0100
+
+
* Thijs Kinkhorst (thijs@debian.org) [131106 12:51]:
+> Nonetheless, that's not relevant here. There are several likely candidates
+> in existence, so the choice will not be to use something existing versus
+> implementing from scratch; the choice will be between existing projects,
+> and given that, the amount of work per system may differ but the
+> difference will not likely be that great that it's unsurmountable, as they
+> exist, they have active upstreams and they have successfully been used in
+> other distributions.
+
+I'm not sure we are all convinced about that. And the question is not
+only "do they have active upstreams", but also "would upstream
+(continue to) develop things in a direction that's also useful for
+us". Taking an example (and this one is made-up, so please don't use
+the flame-key on me), if systemd would start to only work with the
+gnome desktop chooser this might be considered inacceptable, and
+wouldn't be too helpful for us I'd expect. Same example would work
+with upstart and unity. Or whatever else.
+
+
+> I do agree that it's nice to have the very best code quality available,
+> but in the long run, having underdocumented code is annoying and may lead
+> to bugs, but bugs can be fixed and documentation improved; changing the
+> basic architecture of the system is unlikely to be fixed. I really believe
+> we are going to regret it if Debian chooses the architecture it likes less
+> for the reason that it has more documentation.
+
+In the end (at least from my perspective) we need to choose on a set
+of advantages and disadvantages. There are different sets available
+(or at least there is no consensus in Debian at large that only one of
+them works).
+
+First of all, we need to check which ones would be working at all. If
+we notice that one of them won't allow us to properly release jessie,
+I think we don't need to check if that architecture might be a bit
+nicer. Also, if we notice that one architecture is unbearable broken,
+the same applies. If we however notice that a set might only work if
+Debian spends quite some effort, and we also notice that there are
+enough people in Debian willing to do the work - well, that returns
+this set in the group of sets we could choose from.
+
+Of course it still could happen that after this pre-check we end up
+with examples where we say "no, really not because" and we have to
+re-evaluate what other optins we have. But also we're not there yet.
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 07 Nov 2013 13:42:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Miroslaw Baran <miroslaw+c+debbugs@makabra.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 07 Nov 2013 13:42:08 GMT) (full text, mbox, link).

+ +

Message #493 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>
+
To: 727708@bugs.debian.org
+
Subject: New development in systemd ecosystem: networkd
+
Date: Thu, 07 Nov 2013 13:40:25 +0000
+
+
Hey,
+
+There is new exciting development in the systemd ecosystem, one that can be 
+used as an argument by both the proponents of systemd and the proponents of 
+‘anything than systemd’. It's not mandatory yet, but it was greeted with 
+enthusiasm, and I think it will become mandatory as soon it matures a bit, 
+considering that servers are RedHat's priority.
+
+Quoting the author of networkd:
+
+> This daemon listens for and configures network devices tagged with
+> 'systemd-networkd'. By default, no devices are tagged so this daemon
+> can safely run in parallel with existing network daemons/scripts.
+
+> Networks are configured in /etc/systemd/network/*.network. The first
+> .network
+> file that matches a given link is applied. The matching logic is similar to
+> the one for .link files, but additionally supports matching on interface
+> name.
+ 
+> The mid-term aim is to provide an alternative to ad-hoc scripts currently
+> used in initrd's and for wired setups that don't change much (e.g., as seen
+> on servers/and some embedded systems).
+
+More details in the original thread: 
+<http://lists.freedesktop.org/archives/systemd-devel/2013-November/014077.html>
+
+Cheers,
+– Mirosław Baran
+
+-- 
+    DMSNUTS100A INVALID REPLY. ANSWER YES OR NO
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 07 Nov 2013 17:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Konstantinos Margaritis <markos@freevec.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 07 Nov 2013 17:57:04 GMT) (full text, mbox, link).

+ +

Message #498 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Konstantinos Margaritis <markos@freevec.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Thu, 7 Nov 2013 19:53:08 +0200
+
+
[Message part 1 (text/plain, inline)]
+
Hi TC and people,
+
+Another issue that might or might have not already been answered, that
+was triggered from seeing direct comparison metrics. Do we have some
+kind of a metric or some even personal experience with regards to which
+project has been the most friendly in accepting patches *from* Debian?
+
+I think it's also important, especially if the patches are not really
+relevant to the project's direct goals, say, fixes for a specific
+Debian port or missing feature that Debian needs and has a patch for,
+but upstream does not care about. I'm being generic here, but it's
+quite common for Debian to have distro-specific patches in its
+packages. Some of them can be upstreamed, but there are cases where
+Debian has to carry those patches around forever. So the question is,
+which of the init systems has been the "friendliest" to Debian so far,
+if anyone has any experience on this matter?
+
+Regards
+
+Konstantinos
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 07 Nov 2013 18:39:31 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 07 Nov 2013 18:39:31 GMT) (full text, mbox, link).

+ +

Message #503 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Miroslaw Baran <miroslaw+c+debbugs@makabra.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: New development in systemd ecosystem: networkd
+
Date: Thu, 07 Nov 2013 11:38:14 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Miroslaw Baran <miroslaw+c+debbugs@makabra.org> writes:
+
+> Quoting the author of networkd:
+
+If the existence of this code helps reduce the number of ad-hoc scripts
+in the world as the author hopes, then it may add some value.  However,
+in the Debian context, systemd-networkd seems at first glance to be
+purely duplicative? 
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 07 Nov 2013 18:51:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 07 Nov 2013 18:51:10 GMT) (full text, mbox, link).

+ +

Message #508 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Bdale Garbee <bdale@gag.com>
+
Cc: 727708@bugs.debian.org, Miroslaw Baran <miroslaw+c+debbugs@makabra.org>
+
Subject: Re: Bug#727708: New development in systemd ecosystem: networkd
+
Date: Thu, 07 Nov 2013 10:50:22 -0800
+
+
Bdale Garbee <bdale@gag.com> writes:
+> Miroslaw Baran <miroslaw+c+debbugs@makabra.org> writes:
+
+>> Quoting the author of networkd:
+
+> If the existence of this code helps reduce the number of ad-hoc scripts
+> in the world as the author hopes, then it may add some value.  However,
+> in the Debian context, systemd-networkd seems at first glance to be
+> purely duplicative?
+
+It sounds like it does the same thing as ifupdown for static, simple
+networks, but doesn't include the more complex stuff.
+
+It's an interesting option to have available.  I could see possibly using
+it on servers that don't care about any of the DHCP or wireless
+complexity, just to have simpler code paths.  But I suspect we'd want to
+leave it turned off by default in Debian for the forseeable future, at
+least as long as we have active ifupdown maintainers who are still
+interested in keeping that system working.  The transition to something
+else would be annoying, and it's not clear there would be much benefit.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 07 Nov 2013 19:51:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 07 Nov 2013 19:51:07 GMT) (full text, mbox, link).

+ +

Message #513 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init systems: arguments for the CTTE
+
Date: Thu, 7 Nov 2013 20:47:28 +0100
+
+
* Bdale Garbee (bdale@gag.com) [131028 18:51]:
+> Josselin Mouette <joss@debian.org> writes:
+> 
+> > While it is (and can remain) possible, just like in the
+> > NM case, to install it without systemd and lose functionality, I think
+> > it is unreasonable to ask for a default GNOME installation without it.
+> 
+> Thanks for making this clear.
+
+http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/
+contains a bit more information on the connection of gnome - logind -
+systemd.
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 08 Nov 2013 14:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Marko Randjelovic <markoran@eunet.rs>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 08 Nov 2013 14:21:04 GMT) (full text, mbox, link).

+ +

Message #518 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Marko Randjelovic <markoran@eunet.rs>
+
To: Thorsten Glaser <tg@mirbsd.de>, 727708@bugs.debian.org, + Josselin Mouette + <joss@debian.org>
+
Cc: debian-devel@lists.debian.org, Steven Chamberlain <steven@pyro.eu.org>, + Steve Langasek <vorlon@debian.org>, Thomas Goirand <zigo@debian.org>, + Lucas + Nussbaum <leader@debian.org>
+
Subject: Re: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)
+
Date: Fri, 8 Nov 2013 14:54:37 +0100
+
+
Additional arguments in favor of sysvinit:
+
+* systemd and upstart lead to vendor lock-in; it will be complicated
+later to return back or change to third option, as well to change from
+first to second option
+
+* I don't have a feeling that configuration can be very simpler than
+shell scripts; there are things such as 'events' and such things have
+to be properly defined)
+
+* If OpenRC's development continues in good direction, Debian could
+switch to OpenRC
+
+* If our shell scripts are a mess, then we should clean up the mess,
+not trying to escape it by changing whole init system; more precisely,
+we should correct mistakes we made in past, such as not enough
+abstraction
+
+* existing software (sysvinit+initscripts) can be enhanced:
+
+(1) add new features to sysvinit; e.g. start-stop-daemon could be
+extended, to return only when service is ready, or if timeout exceeds
+to return with error status (2) add new software in addition to sysvinit
+(3) make init scripts more correct (abstraction)
+(4) extend configurability (more options in /etc/default/*)
+
+(3) makes (4) easily possible
+
+If sysvinit is in accord with UNIX philosophy, and as they say it is,
+than I don't see why (1) and (2) would not be possible, too, and with
+not to much effort. 
+
+* What is alleged to be disadvantages of sysvinit (lack of features),
+is not really to blame sysvinit, because it does one thing and do it
+right. Other features could be implemented as additional software. On
+the other hand, what actually was done was writing new software that
+make old software obsolete and that do *many* things, which is not in
+accord with UNIX philosophy. 
+
+* More complex software has more bugs, old software is cleaned out of
+original bugs, and new software is not. 
+
+* Software that is not well commented is hard to understand and find
+bugs
+
+For more details:
+
+http://lists.debian.org/20131108125545.1b43fc64@eunet.rs
+http://lists.debian.org/20131108134841.715634cc@eunet.rs
+http://lists.debian.org/20131105234316.4407f99b@eunet.rs
+http://lists.debian.org/20131106135535.7d0919bb@eunet.rs
+http://lists.debian.org/20131103102302.4249321d@eunet.rs
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 08 Nov 2013 15:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 08 Nov 2013 15:33:04 GMT) (full text, mbox, link).

+ +

Message #523 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+
To: Marko Randjelovic <markoran@eunet.rs>
+
Cc: Thorsten Glaser <tg@mirbsd.de>, 727708@bugs.debian.org, + Josselin Mouette <joss@debian.org>, + debian-devel@lists.debian.org, Steven Chamberlain <steven@pyro.eu.org>, + Steve Langasek <vorlon@debian.org>, + Thomas Goirand <zigo@debian.org>, Lucas Nussbaum <leader@debian.org>
+
Subject: Re: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)
+
Date: Fri, 08 Nov 2013 16:30:28 +0100
+
+
On 11/08/2013 02:54 PM, Marko Randjelovic wrote:
+> Additional arguments in favor of sysvinit:
+> 
+> * systemd and upstart lead to vendor lock-in; it will be complicated
+> later to return back or change to third option, as well to change from
+> first to second option
+
+Exactly what vendor would we be locked into with systemd?
+
+> * I don't have a feeling that configuration can be very simpler than
+> shell scripts; there are things such as 'events' and such things have
+> to be properly defined)
+
+A bash script as glue code between the init daemon is simpler than the
+simple descriptive XDG format used for systemd's unit files? I don't
+think so.
+
+> * If OpenRC's development continues in good direction, Debian could
+> switch to OpenRC
+
+The word here is "if". It's not going to happen. OpenRC has fundamental
+issues which haven't been resolved for years now:
+
+> https://bugs.gentoo.org/show_bug.cgi?id=391945
+
+I don't think this is a viable alternative to anything. We can't work
+with vaporware, we need software that actually works.
+
+> * If our shell scripts are a mess, then we should clean up the mess,
+> not trying to escape it by changing whole init system; more precisely,
+> we should correct mistakes we made in past, such as not enough
+> abstraction
+
+And who is going to do it? Are you?
+
+People constantly stating that systems like OpenRC and sysvinit
+are actually viable alternatives if someone improved them without
+actually stepping forward themselves leaves me up to the impression
+that those people actually don't have interests in pushing sysvinit
+or OpenRC but just blocking the adoption of systemd or upstart.
+
+> * existing software (sysvinit+initscripts) can be enhanced:
+> 
+> (1) add new features to sysvinit; e.g. start-stop-daemon could be
+> extended, to return only when service is ready, or if timeout exceeds
+> to return with error status (2) add new software in addition to sysvinit
+> (3) make init scripts more correct (abstraction)
+> (4) extend configurability (more options in /etc/default/*)
+> 
+> (3) makes (4) easily possible
+
+The X.org developers were thinking to do the same with X.org but
+at some point figured out that the sources they are dealing
+with were such a mess that it's better to start over altogether and
+started Wayland, see:
+
+> http://www.youtube.com/watch?v=RIctzAQOe44
+
+> If sysvinit is in accord with UNIX philosophy, and as they say it is,
+> than I don't see why (1) and (2) would not be possible, too, and with
+> not to much effort. 
+
+No one cares about the "Unix philosophy" (TM), it's not some super
+holy cow we're not allowed to touch. Additionally, original Unix
+sucks, it's all the GNU- and Linux-specific extensions that
+actually made it usable.
+
+> * What is alleged to be disadvantages of sysvinit (lack of features),
+> is not really to blame sysvinit, because it does one thing and do it
+> right.
+
+No, sysvinit doesn't even do the one thing it does right. It has been
+explained many many times before why that isn't the case.
+
+> * More complex software has more bugs, old software is cleaned out of
+> original bugs, and new software is not. 
+
+If that should be a dogma we should always stick to, we should
+immediately abandon all efforts to improve software and go back
+to Linux 0.01.
+
+> * Software that is not well commented is hard to understand and find
+> bugs
+
+Your last statement doesn't hold at all without actually giving a
+couple if examples where you think that systemd or upstart are
+poorly documented.
+
+Adrian
+
+-- 
+ .''`.  John Paul Adrian Glaubitz
+: :' :  Debian Developer - glaubitz@debian.org
+`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
+  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 08 Nov 2013 15:45:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Paul R. Tagliamonte" <paultag@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 08 Nov 2013 15:45:14 GMT) (full text, mbox, link).

+ +

Message #528 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Paul R. Tagliamonte" <paultag@gmail.com>
+
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>, 727708@bugs.debian.org
+
Cc: Marko Randjelovic <markoran@eunet.rs>, Thorsten Glaser <tg@mirbsd.de>, Josselin Mouette <joss@debian.org>, + Debian Devel <debian-devel@lists.debian.org>, Steven Chamberlain <steven@pyro.eu.org>, + Steve Langasek <vorlon@debian.org>, Thomas Goirand <zigo@debian.org>, Lucas Nussbaum <leader@debian.org>
+
Subject: Re: Bug#727708: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)
+
Date: Fri, 8 Nov 2013 10:40:33 -0500
+
+
[Message part 1 (text/plain, inline)]
+
This has now been discussed ad nauseam. Can we please stop posting about
+this on -devel and let the tech-ctte work?
+
+Thanks,
+  Paul
+
+
+On Fri, Nov 8, 2013 at 10:30 AM, John Paul Adrian Glaubitz <
+glaubitz@physik.fu-berlin.de> wrote:
+
+> On 11/08/2013 02:54 PM, Marko Randjelovic wrote:
+> > Additional arguments in favor of sysvinit:
+> >
+> > * systemd and upstart lead to vendor lock-in; it will be complicated
+> > later to return back or change to third option, as well to change from
+> > first to second option
+>
+> Exactly what vendor would we be locked into with systemd?
+>
+> > * I don't have a feeling that configuration can be very simpler than
+> > shell scripts; there are things such as 'events' and such things have
+> > to be properly defined)
+>
+> A bash script as glue code between the init daemon is simpler than the
+> simple descriptive XDG format used for systemd's unit files? I don't
+> think so.
+>
+> > * If OpenRC's development continues in good direction, Debian could
+> > switch to OpenRC
+>
+> The word here is "if". It's not going to happen. OpenRC has fundamental
+> issues which haven't been resolved for years now:
+>
+> > https://bugs.gentoo.org/show_bug.cgi?id=391945
+>
+> I don't think this is a viable alternative to anything. We can't work
+> with vaporware, we need software that actually works.
+>
+> > * If our shell scripts are a mess, then we should clean up the mess,
+> > not trying to escape it by changing whole init system; more precisely,
+> > we should correct mistakes we made in past, such as not enough
+> > abstraction
+>
+> And who is going to do it? Are you?
+>
+> People constantly stating that systems like OpenRC and sysvinit
+> are actually viable alternatives if someone improved them without
+> actually stepping forward themselves leaves me up to the impression
+> that those people actually don't have interests in pushing sysvinit
+> or OpenRC but just blocking the adoption of systemd or upstart.
+>
+> > * existing software (sysvinit+initscripts) can be enhanced:
+> >
+> > (1) add new features to sysvinit; e.g. start-stop-daemon could be
+> > extended, to return only when service is ready, or if timeout exceeds
+> > to return with error status (2) add new software in addition to sysvinit
+> > (3) make init scripts more correct (abstraction)
+> > (4) extend configurability (more options in /etc/default/*)
+> >
+> > (3) makes (4) easily possible
+>
+> The X.org developers were thinking to do the same with X.org but
+> at some point figured out that the sources they are dealing
+> with were such a mess that it's better to start over altogether and
+> started Wayland, see:
+>
+> > http://www.youtube.com/watch?v=RIctzAQOe44
+>
+> > If sysvinit is in accord with UNIX philosophy, and as they say it is,
+> > than I don't see why (1) and (2) would not be possible, too, and with
+> > not to much effort.
+>
+> No one cares about the "Unix philosophy" (TM), it's not some super
+> holy cow we're not allowed to touch. Additionally, original Unix
+> sucks, it's all the GNU- and Linux-specific extensions that
+> actually made it usable.
+>
+> > * What is alleged to be disadvantages of sysvinit (lack of features),
+> > is not really to blame sysvinit, because it does one thing and do it
+> > right.
+>
+> No, sysvinit doesn't even do the one thing it does right. It has been
+> explained many many times before why that isn't the case.
+>
+> > * More complex software has more bugs, old software is cleaned out of
+> > original bugs, and new software is not.
+>
+> If that should be a dogma we should always stick to, we should
+> immediately abandon all efforts to improve software and go back
+> to Linux 0.01.
+>
+> > * Software that is not well commented is hard to understand and find
+> > bugs
+>
+> Your last statement doesn't hold at all without actually giving a
+> couple if examples where you think that systemd or upstart are
+> poorly documented.
+>
+> Adrian
+>
+> --
+>  .''`.  John Paul Adrian Glaubitz
+> : :' :  Debian Developer - glaubitz@debian.org
+> `. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
+>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
+>
+>
+> --
+> To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
+> with a subject of "unsubscribe". Trouble? Contact
+> listmaster@lists.debian.org
+> Archive: http://lists.debian.org/527D0394.3010806@physik.fu-berlin.de
+>
+>
+
+
+-- 
+:wq
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 08 Nov 2013 17:45:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Marko Randjelovic <markoran@eunet.rs>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 08 Nov 2013 17:45:08 GMT) (full text, mbox, link).

+ +

Message #533 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Marko Randjelovic <markoran@eunet.rs>
+
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)
+
Date: Fri, 8 Nov 2013 18:41:45 +0100
+
+
On Fri, 08 Nov 2013 16:30:28 +0100
+John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
+
+> On 11/08/2013 02:54 PM, Marko Randjelovic wrote:
+> > Additional arguments in favor of sysvinit:
+> > 
+> > * systemd and upstart lead to vendor lock-in; it will be complicated
+> > later to return back or change to third option, as well to change from
+> > first to second option
+> 
+> Exactly what vendor would we be locked into with systemd?
+
+I don't want to accuse anyone, but obviously there is a possibility for
+a situation similar to lock-in, merely because of what I said: "it will
+be complicated later to return back or change to third option".
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 10 Nov 2013 18:27:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 10 Nov 2013 18:27:19 GMT) (full text, mbox, link).

+ +

Message #538 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Tollef Fog Heen <tfheen@debian.org>, Michael Biebl <biebl@debian.org>, Marco d'Itri <md@linux.it>, Thomas Goirand <zigo@debian.org>, Steve Langasek <vorlon@debian.org>, Steven Chamberlain <steven@pyro.eu.org>, Patrick Lauer <patrick@gentoo.org>, Alexander Vershilov <qnikst@gentoo.org>, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: init system question before the technical committee
+
Date: Sun, 10 Nov 2013 10:23:06 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Ian Jackson writes:
+
+>> So I would appreciate it if you (and by "you" I mean each side of the
+>> argument) would make sure that your page represents the best case you
+>> can put forward.
+
+> This seems to have come along very well in the past few days.
+
+> We now have five camps with pages with substantial content:
+
+>   https://wiki.debian.org/Debate/initsystem/multiple
+>   https://wiki.debian.org/Debate/initsystem/openrc
+>   https://wiki.debian.org/Debate/initsystem/systemd
+>   https://wiki.debian.org/Debate/initsystem/sysvinit
+>   https://wiki.debian.org/Debate/initsystem/upstart
+
+> Obviously people will need some time to further flesh this out and
+> particularly to write rebuttals (or incorporate points into their main
+> text which amount to rebuttals).
+
+> If you're in one of these camps you'll probably want to subscribe to
+> the pages of the others, so you can follow what they're doing and make
+> sure to respond appropriately.
+
+> How long do people think finalising this is going to take ?  There are
+> some potential problems with setting a hard deadline in advance but
+> we're hoping to deal with this matter fairly soon now.
+
+We've now gotten confirmation from the maintainers of the systemd position
+statement that they consider their statement basically finished.  I think
+those are the only position statement maintainers we've heard from.
+
+What is the current status of the other position statements from the
+perspective of their maintainers?  Do people have a feel for when they'll
+consider their positions finalized, at least pending Technical Committee
+feedback and questions?
+
+> Perhaps it would be good if the camp leader(s) for each camp would
+> reply with a summary of:
+>   - the status of their own main arguments: are you mostly done,
+>      or do you expect to add more substantial points
+>   - the status of their rebuttals: subject of course, to any future
+>      changes by the other camps, how close are you to having what
+>      you consider a good answer to the other camps' points ?
+
+I think this would still be a good idea.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 10 Nov 2013 23:03:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Peter Dolding <oiaohm@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 10 Nov 2013 23:03:12 GMT) (full text, mbox, link).

+ +

Message #543 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Peter Dolding <oiaohm@gmail.com>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Mon, 11 Nov 2013 09:02:28 +1000
+
+
On Tue, Nov 5, 2013 at 2:02 PM, Russ Allbery <rra@debian.org> wrote:
+> Peter Dolding <oiaohm@gmail.com> writes:
+>
+>> ExecStartPre=, ExecStartPost= can be written many times.
+>
+>> ExecStartPre= rm somewhere
+>> ExecStartPre= touch somewhere
+>
+> That really doesn't help, because...
+>
+>> In fact lot of cases I see one line entries in systemd and I see bad
+>> form.  Unless one line has like if or for statements its really bad
+>> form inside systemd.
+>
+> ...of this.  If you can't write the scripts with proper block structure,
+> it's actually better to just externalize them in a separate file rather
+> than doing something this awful to try to inline them.
+>
+> I don't think you're going to convince me to like this syntax.  :)  But
+> it's a minor issue.
+
+The multi line option in systemd has other uses when debuging.
+>
+>> Basically upstart is lacking one key feature.  If it not fixed it will
+>> come back and bite us.  Really I would like to see this fixed before
+>> debian takes up upstart if debian takes up upstart at all.
+>
+> I'm afraid there is little chance you will manage to convince me that this
+> is a key feature.  I've been writing portable shell scripts for years, and
+> Debian has been dealing with shell portability issues for years.
+> Regardless of what we do with the init system, we will still have to deal
+> with this with maintainer scripts, etc.  I do see why you're concerned,
+> but I just don't see this as critical compared to other issues under
+> discussion.
+>
+Russ I take it from this point of view.  If we cannot get a minor key
+feature for future compatibly taken upstream.  Will means the upstart
+maintainer ship has to be classed as proven hostile.   This is in fact
+a good test to see what init systems Debian can work with to see if
+debian can get minor alterations upstream.  At this point upstart
+maintainer-ship is suspected of being possibly hostile.   Its about
+time we find out if they are.
+
+As you say we have to deal with maintainers scripts.   We also have to
+deal with third party items at times.   Basically upstart is tieing
+one of my hands behind my back to deal with bad upstart files.   The
+worst risk is ubuntu and debian using a different /bin/sh and having
+different portability requirements and I am for some reason forced to
+use a ubuntu .deb package for something.  Remember the case of steam
+binaries.   History tells us that your idea we can write script
+portable is a foolish idea.  Just because you can not everyone else
+can.  Like if I have altered a script from some third party they can
+blame my alteration.  Yes there is a reason why you must be able to
+just change the shell.
+
+This is not exactly a minor issue.   The lack of means to set shell
+effects future possibilities of importing binaries built only for
+Ubuntu and other distributions using upstart.
+
+Also upstart means writing a more complex auditing tool.  Vastly more
+complex.   Systemd single line system is really simple to write a
+script to go through and check everything starting exec after the =
+for ;  so finding where any maintainer gets the idea of in-lining
+foolishly. So is fairly simple to automated a debian test to badly
+designed systemd unit files.   Yes the external shell script files
+will audit with debians existing tools without modifications.
+
+Peter Dolding
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 13 Nov 2013 00:06:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 13 Nov 2013 00:06:05 GMT) (full text, mbox, link).

+ +

Message #548 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, + Tollef Fog Heen <tfheen@debian.org>, + Michael Biebl <biebl@debian.org>, Marco d'Itri <md@linux.it>, + Thomas Goirand <zigo@debian.org>, + Steven Chamberlain <steven@pyro.eu.org>, + Patrick Lauer <patrick@gentoo.org>, + Alexander Vershilov <qnikst@gentoo.org>, + Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: init system question before the technical committee
+
Date: Tue, 12 Nov 2013 16:04:54 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Hi Russ,
+
+On Sun, Nov 10, 2013 at 10:23:06AM -0800, Russ Allbery wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > Ian Jackson writes:
+
+> >> So I would appreciate it if you (and by "you" I mean each side of the
+> >> argument) would make sure that your page represents the best case you
+> >> can put forward.
+
+> > This seems to have come along very well in the past few days.
+
+> > We now have five camps with pages with substantial content:
+
+> >   https://wiki.debian.org/Debate/initsystem/multiple
+> >   https://wiki.debian.org/Debate/initsystem/openrc
+> >   https://wiki.debian.org/Debate/initsystem/systemd
+> >   https://wiki.debian.org/Debate/initsystem/sysvinit
+> >   https://wiki.debian.org/Debate/initsystem/upstart
+
+> > Obviously people will need some time to further flesh this out and
+> > particularly to write rebuttals (or incorporate points into their main
+> > text which amount to rebuttals).
+
+> > If you're in one of these camps you'll probably want to subscribe to
+> > the pages of the others, so you can follow what they're doing and make
+> > sure to respond appropriately.
+
+> > How long do people think finalising this is going to take ?  There are
+> > some potential problems with setting a hard deadline in advance but
+> > we're hoping to deal with this matter fairly soon now.
+
+> We've now gotten confirmation from the maintainers of the systemd position
+> statement that they consider their statement basically finished.  I think
+> those are the only position statement maintainers we've heard from.
+
+> What is the current status of the other position statements from the
+> perspective of their maintainers?  Do people have a feel for when they'll
+> consider their positions finalized, at least pending Technical Committee
+> feedback and questions?
+
+> > Perhaps it would be good if the camp leader(s) for each camp would
+> > reply with a summary of:
+> >   - the status of their own main arguments: are you mostly done,
+> >      or do you expect to add more substantial points
+> >   - the status of their rebuttals: subject of course, to any future
+> >      changes by the other camps, how close are you to having what
+> >      you consider a good answer to the other camps' points ?
+
+> I think this would still be a good idea.
+
+At this point I'm satisfied with
+<https://wiki.debian.org/Debate/initsystem/upstart>, at least as a starting
+point for further discussion with the TC.  I'm sure the systemd folks and I
+could go back and forth interminably polishing our rhetoric, but I'd rather
+turn our attention to actual questions that the other members of the TC find
+relevant. ;)
+
+Thanks,
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 21 Nov 2013 21:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 21 Nov 2013 21:00:04 GMT) (full text, mbox, link).

+ +

Message #553 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, + 727708@bugs.debian.org, Tollef Fog Heen <tfheen@debian.org>, + Michael Biebl <biebl@debian.org>, + Marco d'Itri <md@linux.it>, Thomas Goirand <zigo@debian.org>, + Steve Langasek <vorlon@debian.org>, + Patrick Lauer <patrick@gentoo.org>, + Alexander Vershilov <qnikst@gentoo.org>, + Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: init system question before the technical committee
+
Date: Thu, 21 Nov 2013 20:56:31 +0000
+
+
[Message part 1 (text/plain, inline)]
+
Hi,
+
+On 10/11/13 18:23, Russ Allbery wrote:
+> What is the current status of the other position statements from the
+> perspective of their maintainers?  Do people have a feel for when they'll
+> consider their positions finalized, at least pending Technical Committee
+> feedback and questions?
+
+Sorry to be so late with this.  I've made some small, final changes to
+this position statement and I'd like to call it 'complete':
+https://wiki.debian.org/Debate/initsystem/multiple
+
+I don't really feel that any "contra $initsystem" sections or rebuttals
+are needed on this page and it reads nicer this way.  And I'm too tired
+to argue this much more;  the debate has already taken far more energy
+than I would like.
+
+Thanks,
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 27 Nov 2013 06:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thomas Goirand <zigo@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 27 Nov 2013 06:09:04 GMT) (full text, mbox, link).

+ +

Message #558 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thomas Goirand <zigo@debian.org>
+
To: 727708@bugs.debian.org
+
Cc: Patrick Lauer <patrick@gentoo.org>
+
Subject: Re: Bug#727708: init system question before the technical committee
+
Date: Wed, 27 Nov 2013 14:07:05 +0800
+
+
On 11/22/2013 04:56 AM, Steven Chamberlain wrote:
+> Hi,
+> 
+> On 10/11/13 18:23, Russ Allbery wrote:
+>> What is the current status of the other position statements from the
+>> perspective of their maintainers?  Do people have a feel for when they'll
+>> consider their positions finalized, at least pending Technical Committee
+>> feedback and questions?
+> 
+> Sorry to be so late with this.  I've made some small, final changes to
+> this position statement and I'd like to call it 'complete':
+> https://wiki.debian.org/Debate/initsystem/multiple
+> 
+> I don't really feel that any "contra $initsystem" sections or rebuttals
+> are needed on this page and it reads nicer this way.  And I'm too tired
+> to argue this much more;  the debate has already taken far more energy
+> than I would like.
+> 
+> Thanks,
+> Regards,
+
+Hi,
+
+I have the go-ahead from OpenRC upstream (eg: Patrick Lauer) so please
+consider the OpenRC page as finalized as well.
+
+Cheers,
+
+Thomas Goirand (zigo)
+
+P.S: Sorry for the delay. As I wrote previously, I had personal and
+professional events which delayed this task.
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 27 Nov 2013 10:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Marko Randjelovic <markoran@eunet.rs>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 27 Nov 2013 10:51:04 GMT) (full text, mbox, link).

+ +

Message #563 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Marko Randjelovic <markoran@eunet.rs>
+
To: debian-devel@lists.debian.org
+
Cc: 727708@bugs.debian.org, StevenChamberlain <steven@pyro.eu.org>
+
Subject: Re: sysvinit: moving the contents out of the Essential: yes + package?
+
Date: Wed, 27 Nov 2013 12:49:39 +0100
+
+
On Tue, 26 Nov 2013 18:42:43 +0800
+Thomas Goirand <zigo@debian.org> wrote:
+
+> With the above, it's easy to switch from one to the other. Well, that is
+> before the mess with the version-depends on sysv-rc introduced by the
+> debhelper thing for upstart, which messed-up a few things... I hope many
+> packages have been rebuilt with the new debhelper version since that has
+> been corrected, especially the essential ones (like ifupdown and the
+> others (I can't remember)).
+
+Then I don't understand why on 'multiple' page they say sysvinit+openrc
+is infeasible.
+	
+-- 
+https://en.wikipedia.org/wiki/Little_Red_Riding_Hood
+
+my homepage: http://mr.flossdaily.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 27 Nov 2013 19:54:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 27 Nov 2013 19:54:08 GMT) (full text, mbox, link).

+ +

Message #568 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, + 727708@bugs.debian.org, Tollef Fog Heen <tfheen@debian.org>, + Michael Biebl <biebl@debian.org>, + Marco d'Itri <md@linux.it>, Thomas Goirand <zigo@debian.org>, + Steve Langasek <vorlon@debian.org>, + Patrick Lauer <patrick@gentoo.org>, + Alexander Vershilov <qnikst@gentoo.org>, + Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: init system question before the technical committee
+
Date: Wed, 27 Nov 2013 19:50:54 +0000
+
+
[Message part 1 (text/plain, inline)]
+
The sysvinit page doesn't have a specific maintainer/advocate.  It is a
+collection of opinions from discussion on debian-devel@ and elsewhere.
+Other camps have already responded to parts they don't agree with.
+
+Unless any volunteers want to make last-minute small changes, it can
+probably be taken as 'complete' as soon the tech-ctte is ready to move
+forward with this.  I think maintainers of all the other proposals have
+said they are ready now.
+
+Thanks,
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 28 Nov 2013 12:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Marko Randjelovic <markoran@eunet.rs>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 28 Nov 2013 12:39:05 GMT) (full text, mbox, link).

+ +

Message #573 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Marko Randjelovic <markoran@eunet.rs>
+
To: Steven Chamberlain <steven@pyro.eu.org>
+
Cc: Russ Allbery <rra@debian.org>, + Ian Jackson + <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, + Tollef Fog Heen + <tfheen@debian.org>, Michael Biebl <biebl@debian.org>, + "Marco d'Itri" + <md@linux.it>, Thomas Goirand <zigo@debian.org>, + Steve Langasek + <vorlon@debian.org>, + Patrick Lauer <patrick@gentoo.org>, + Alexander + Vershilov <qnikst@gentoo.org>, + Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: init system question before the technical committee
+
Date: Thu, 28 Nov 2013 14:35:21 +0100
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, 27 Nov 2013 19:50:54 +0000
+Steven Chamberlain <steven@pyro.eu.org> wrote:
+
+> The sysvinit page doesn't have a specific maintainer/advocate.  It is a
+> collection of opinions from discussion on debian-devel@ and elsewhere.
+> Other camps have already responded to parts they don't agree with.
+> 
+> Unless any volunteers want to make last-minute small changes, it can
+> probably be taken as 'complete' as soon the tech-ctte is ready to move
+> forward with this.  I think maintainers of all the other proposals have
+> said they are ready now.
+> 
+> Thanks,
+> Regards,
+
+There were elements in form of conversation, and I have made some
+changes, but didn't want to erase what other people wrote, so now there
+more elements in form of conversation. Should they be merged (calculate resultant)?
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 28 Nov 2013 12:51:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 28 Nov 2013 12:51:09 GMT) (full text, mbox, link).

+ +

Message #578 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Thu, 28 Nov 2013 12:49:26 +0000
+
+
[Message part 1 (text/plain, inline)]
+
A friend of mine mentioned to me in the pub that he had seem alarming
+reports of systemd security bugs.  Naturally I asked for more
+information and he promised me an email with some references.
+
+So, here's what Andrew sent me.  Thanks to Andrew for doing this
+legwork.
+
+I'll reply substantively in a moment.
+
+
+
[Message part 2 (message/rfc822, inline)]
+
+
+ +
From: Andrew Kanaber <akanaber@chiark.greenend.org.uk>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Systemd bugs
+
Date: Wed, 27 Nov 2013 20:55:53 +0000
+
+
Hi Ian,
+
+Here's the email about systemd security holes that I kept forgetting to send
+you. I hope it's (still) useful.
+
+The debian-devel post I was thinking of is <441543.92540.bm@smtp118.mail.ir2.yahoo.com>
+but it actually only mentions three vulnerabilities, there's a more complete
+list of the ones that have affected Debian at
+ https://security-tracker.debian.org/tracker/source-package/systemd
+
+Here's a short summary along with the redhat bug numbers (since the redhat BTS
+seems to be the place to go for systemd information)
+
+CVE		summary					Debian BTS	Redhat
+2012-0871	systemd-logind insecure file creation	?		795853 
+2012-1101	DoS from systemctl status		662029		799902
+2012-1174	TOCTOU deletion race in systemd-logind	664364		803358
+2013-4327	insecure use of polkit			723713		1006680
+2013-4391	systemd journald integer overflow	725357		859051
+2013-4392	TOCTOU race updating file perms		725357		859060
+2013-4393	systemd journald DoS			725357		859104
+2013-4394	improper sanitization of XKB layouts	725357		862324
+
+I think the "really bad one to do with remote connection" the guy on
+debian-devel was thinking of is CVE-2013-4391 which mentions possible
+arbitrary code execution from a "specially crafted packet" but I'm not sure
+under what conditions it would be triggerable over IP, I guess you might have
+had to set up your system as a remote journald server.
+
+The bug I mentioned one where bad data in its binary log files causes journald
+to go mad and eventially fill up /var with junk is
+https://bugzilla.redhat.com/show_bug.cgi?id=974132
+and is apparently still not fixed.
+
+Generally the RedHat BTS at
+https://bugzilla.redhat.com/buglist.cgi?quicksearch=Component:systemd
+and 
+https://bugzilla.redhat.com/buglist.cgi?quicksearch=Component:systemd+Status:CLOSED
+make alarming reading
+
+Hope this helps,
+
+Andrew
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 28 Nov 2013 13:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 28 Nov 2013 13:45:04 GMT) (full text, mbox, link).

+ +

Message #583 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Thu, 28 Nov 2013 13:43:27 +0000
+
+
Andrew Kanaber <akanaber@chiark.greenend.org.uk>:
+> The debian-devel post I was thinking of is <441543.92540.bm@smtp118.mail.ir2.yahoo.com>
+> but it actually only mentions three vulnerabilities, there's a more complete
+> list of the ones that have affected Debian at
+>  https://security-tracker.debian.org/tracker/source-package/systemd
+
+In summary, I agree with Andrew Kanaber's view that the security and
+bug history of systemd is worrying.
+
+
+> Here's a short summary along with the redhat bug numbers (since the
+> redhat BTS seems to be the place to go for systemd information)
+> 
+> CVE		summary					Debian BTS	Redhat
+> 2012-0871	systemd-logind insecure file creation	?		795853 
+> 2012-1101	DoS from systemctl status		662029		799902
+> 2012-1174	TOCTOU deletion race in systemd-logind	664364		803358
+> 2013-4327	insecure use of polkit			723713		1006680
+> 2013-4391	systemd journald integer overflow	725357		859051
+> 2013-4392	TOCTOU race updating file perms		725357		859060
+> 2013-4393	systemd journald DoS			725357		859104
+> 2013-4394	improper sanitization of XKB layouts	725357		862324
+
+It isn't always 100% clear to me from reading these which of them
+apply to systemd's init replacement.  But reading the systemd debate
+page makes it clear that the other components in the systemd upstream
+package are seen by systemd proponents as part of their offering, and
+indeed reasons to pick systemd.  Integration between the different
+parts of the systemd package is touted as an advantage.  For example,
+journald is mentioned in the 2nd bullet point under Functionality.  So
+I think it it is sensible to look at security or other significant
+bugs, even in those other systemd components.
+
+Furthermore, I think it is fair to look at bugs in non-pid-1 parts of
+the systemd codebase when assessing the likely code quality of the pid
+1 parts.
+
+I should say that it is hard to write code with no security bugs at
+all.  But I think our benchmark for security bugs in our init system
+ought to be "very few", particularly if we are making a specific
+implementation effectively mandatory.  And I don't think I would like
+to accept justifications (for a large bug count) along the lines of
+"but systemd does so much more"; I think the security bugs that come
+with a large codebase, or having more functionality exposed to
+ordinary users, are a direct and very relevant downside to such a
+large codebase or large attack surface.
+
+
+I went and looked at the security bugs Andrew lists:
+
+There are a couple of filesystem races (CVE-2012-1174, CVE-2013-4392)
+which I think a concurrent init system author ought really to be
+competent to avoid.  (And the system should be designed, so far as
+possible, to reduce the opportunity for such races.)
+
+The "systemctl status" resource usage DoS (CVE-2012-1101) is an
+understandable resource leak, given systemd's design.  But for me it
+raises this question: why is the system designed in such a way that
+the critical pid 1 is required to implement functionality (and
+unprivileged-facing interfaces) in which such a resource leak is (a) a
+likely programming error and then (b) exposed so as to be exploitable.
+
+AIUI the journald integer overflow (CVE-2013-4391) is a remotely
+exploitable bug, if you have configured journald to allow remote
+logging.  (I assume this isn't the default configuration but haven't
+checked.)
+
+The other journald one (CVE-2013-4393) seems to stem from a poor
+design decision: journald expects to be given an fd and then reads
+from it.  The authors of this obviously-security-critical code failed
+to appreciate the variety of exciting things that can happen to the
+recipient of an fd.  I wonder even whether the code change
+  http://cgit.freedesktop.org/systemd/systemd/commit/?id=1dfa7e79a60de680086b1d93fcc3629b463f58bd
+which is supposed to fix the bug is sufficient.  Even if it does it
+certainly isn't pretty.  But also it is concerning that people who
+have decided to make extensive use of advanced features of the Linux
+system call interface apparently aren't aware of important and
+hopefully well-known dangers in facilities such as cross-trust-domain
+fd passing.
+
+The XKB one (CVE-2013-4394) is concerning too.  I can't quite tell
+exactly in what configurations you would be vulnerable, but the bug
+itself is not reassuring as regards the authors' additude to
+cross-trust-boundary data processing.  It looks like there's a bunch
+of filenames which are taken from the untrusted side and just
+textually stuffed into the X server configuration.  Even after the
+change which is supposed to fix it,
+  http://cgit.freedesktop.org/systemd/systemd/commit/?id=0b507b17a760b21e33fc52ff377db6aa5086c6800
+it looks like the system might still accept editor backup,
+auto-save files, and the like - the filename patterns which are
+accepted seem far too generous.  I wonder if the authors know whether
+whether they are exposing the X server to malicious XKB data.
+
+
+On to non-security bugs:
+
+Andrew again:
+> The bug I mentioned one where bad data in its binary log files causes journald
+> to go mad and eventially fill up /var with junk is
+> https://bugzilla.redhat.com/show_bug.cgi?id=974132
+> and is apparently still not fixed.
+
+I read this and some of the links from it.  This is indeed concerning.
+Mostly my reaction is "why on earth is this all so complicated?"
+
+
+> Generally the RedHat BTS at
+> https://bugzilla.redhat.com/buglist.cgi?quicksearch=Component:systemd
+> and 
+> https://bugzilla.redhat.com/buglist.cgi?quicksearch=Component:systemd+Status:CLOSED
+> make alarming reading
+
+I agree with this sentiment.  I just looked at a few of these.
+Here are a couple of exciting snippets:
+
+https://bugzilla.redhat.com/show_bug.cgi?id=693605#c1
+
+  systemd invents ENOEXEC, resulting in a genuine error due to cycles
+  in the dependency graph being reported as "Exec format error" (!)
+  In April 2011 a commenter suggests using EINVAL instead but the
+  bug unaccountably remains open.
+
+https://bugzilla.redhat.com/show_bug.cgi?id=708537
+
+  Problems with runlevel emulation doing mad things.  It isn't clear
+  to me whether this bug is a symptom of a fundamental problem with
+  systemd's state-based dependency model, or whether it's simply a
+  missing feature or perhaps even wrong default configuration.  But
+  the bug has been open for some time.
+
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 28 Nov 2013 20:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 28 Nov 2013 20:03:04 GMT) (full text, mbox, link).

+ +

Message #588 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Thu, 28 Nov 2013 22:00:23 +0200
+
+
Ian Jackson wrote:
+> It isn't always 100% clear to me from reading these which of them
+> apply to systemd's init replacement.  But reading the systemd debate
+> page makes it clear that the other components in the systemd upstream
+> package are seen by systemd proponents as part of their offering, and
+> indeed reasons to pick systemd.
+
+Yes, the other tools that systemd provides and enables are part of its
+usefulness, so it is appropriate to look into their quality.
+
+
+> I should say that it is hard to write code with no security bugs at
+> all.  But I think our benchmark for security bugs in our init system
+> ought to be "very few", particularly if we are making a specific
+> implementation effectively mandatory.  And I don't think I would like
+> to accept justifications (for a large bug count) along the lines of
+> "but systemd does so much more"; I think the security bugs that come
+> with a large codebase, or having more functionality exposed to
+> ordinary users, are a direct and very relevant downside to such a
+> large codebase or large attack surface.
+
+But this, I think, is completely wrong. You shouldn't count bugs from
+other tools included with systemd against its core init functionality or
+vice versa. If for example systemd and coreutils came from the same
+source package, that should be "allowed" as many bugs as the current two
+separate source packages, not less.
+
+Most of the separate functionality is optional. It's likely that Debian
+would want to use it, but then Debian would want that functionality with
+other init systems too (or miss it). The most appropriate comparison is
+whether it's possible to have similar functionality with less bugs
+(whether provided with init system or completely independently). As far
+as I can see, for most functionality there are no such alternatives.
+
+At least Upstart, and likely other alternatives to systemd also, would
+still use forked versions of at least logind and possibly other tools
+originating from systemd. Such forks are worse for security than using
+the original systemd one. Thus the fact that logind is developed with
+systemd should count in favor of systemd, not against it.
+
+Also, systemd is the system under the most intense scrutiny for security
+and other issues, so it's not easy to compare bug counts with
+alternatives - alternatives likely have a significantly larger portion
+of issues undetected.
+
+
+> Here are a couple of exciting snippets:
+
+> https://bugzilla.redhat.com/show_bug.cgi?id=708537
+> 
+>   Problems with runlevel emulation doing mad things.  It isn't clear
+>   to me whether this bug is a symptom of a fundamental problem with
+>   systemd's state-based dependency model, or whether it's simply a
+
+I think it's completely obvious that there is no "fundamental problem".
+I wonder what could make you consider it a possible symptom of one.
+
+>   missing feature or perhaps even wrong default configuration.  But
+>   the bug has been open for some time.
+
+My guess is that most people do not consider that "exciting" or really
+care - thinking of system states in terms of "runlevels" is mostly
+obsolete, and the flaws do not bother many people in the cases where
+backwards compatibility is still needed.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 28 Nov 2013 22:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Stapelberg <stapelberg@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 28 Nov 2013 22:18:04 GMT) (full text, mbox, link).

+ +

Message #593 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Stapelberg <stapelberg@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, <727708@bugs.debian.org>
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Thu, 28 Nov 2013 23:15:09 +0100
+
+
Hi Ian,
+
+Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+>> CVE		summary					Debian BTS	Redhat
+>> 2012-0871	systemd-logind insecure file creation	?		795853 
+>> 2012-1101	DoS from systemctl status		662029		799902
+>> 2012-1174	TOCTOU deletion race in systemd-logind	664364		803358
+>> 2013-4327	insecure use of polkit			723713		1006680
+>> 2013-4391	systemd journald integer overflow	725357		859051
+>> 2013-4392	TOCTOU race updating file perms		725357		859060
+>> 2013-4393	systemd journald DoS			725357		859104
+>> 2013-4394	improper sanitization of XKB layouts	725357		862324
+>
+> It isn't always 100% clear to me from reading these which of them
+> apply to systemd's init replacement.  But reading the systemd debate
+2012-1101 does, I think 2013-4327 and 2013-4392 might, all the others do
+not affect the init part of src:systemd.
+
+> Furthermore, I think it is fair to look at bugs in non-pid-1 parts of
+> the systemd codebase when assessing the likely code quality of the pid
+> 1 parts.
+I don’t really agree. The code quality of other parts of the systemd
+ecosystem sure are related and probably provide a good trend of the
+overall code quality. However, there are some “subsystems” of systemd,
+which are to a big part written by non-core contributors. Take for
+example networkd, a minimal network configuration for static
+(server-ish) setups, which was largely implemented by Tom Gundersen:
+http://cgit.freedesktop.org/systemd/systemd/log/src/network
+Or take journald, which also has plenty of contributors:
+http://cgit.freedesktop.org/systemd/systemd/log/src/journal?ofs=50
+http://cgit.freedesktop.org/systemd/systemd/log/src/journal?ofs=100
+
+One can compare this to the Linux kernel, I think: looking at any
+subsystem will give you a somewhat useful idea about the overall code
+quality, but it’s not fair to say linux’s syscall security sucks just
+by looking at the filesystem code.
+
+> I should say that it is hard to write code with no security bugs at
+> all.  But I think our benchmark for security bugs in our init system
+> ought to be "very few", particularly if we are making a specific
+> implementation effectively mandatory.  And I don't think I would like
+> to accept justifications (for a large bug count) along the lines of
+> "but systemd does so much more"; I think the security bugs that come
+> with a large codebase, or having more functionality exposed to
+> ordinary users, are a direct and very relevant downside to such a
+> large codebase or large attack surface.
+They sure are. OTOH, chosing the init system that receives the most
+attention in form of development and is adopted by many other
+distributions helps us a lot with security issues. They are no longer
+just our problem, but other distributions also care about getting them
+fixed quickly.
+
+> There are a couple of filesystem races (CVE-2012-1174, CVE-2013-4392)
+> which I think a concurrent init system author ought really to be
+> competent to avoid.  (And the system should be designed, so far as
+> possible, to reduce the opportunity for such races.)
+“a concurrent init system author” sounds strange on multiple counts:
+systemd was not written by one author. It is also not concurrent (in
+fact it is single-threaded and only links to pthreads to call sync
+asynchronously on shutdown), but event-based. As for competency, I am
+sure that everybody involved has learned their lesson and will avoid
+such issues in the future. I am also sure that other init systems have
+(had) similar bugs. And if there is no evidence of that yet, maybe
+nobody looked really closely yet…? :)
+
+> The "systemctl status" resource usage DoS (CVE-2012-1101) is an
+> understandable resource leak, given systemd's design.  But for me it
+> raises this question: why is the system designed in such a way that
+> the critical pid 1 is required to implement functionality (and
+> unprivileged-facing interfaces) in which such a resource leak is (a) a
+> likely programming error and then (b) exposed so as to be exploitable.
+a) I think “a likely programming error” is an exaggeration. Do you have
+   data on how often there were resource leaks in systemd?
+b) I am unclear on how exactly this was exploitable, and the bugs lack
+   explanation unfortunately.
+
+Furthermore, I think Lennart’s explanation of why arbitrary units must
+be able to be created is fair:
+https://bugzilla.redhat.com/show_bug.cgi?id=680122#c1
+
+> AIUI the journald integer overflow (CVE-2013-4391) is a remotely
+> exploitable bug, if you have configured journald to allow remote
+> logging.  (I assume this isn't the default configuration but haven't
+> checked.)
+journald does not provide remote logging. See
+https://lists.fedoraproject.org/pipermail/devel/2013-July/185585.html
+
+> The other journald one (CVE-2013-4393) seems to stem from a poor
+> design decision: journald expects to be given an fd and then reads
+> from it.  The authors of this obviously-security-critical code failed
+> to appreciate the variety of exciting things that can happen to the
+> recipient of an fd.  I wonder even whether the code change
+>   http://cgit.freedesktop.org/systemd/systemd/commit/?id=1dfa7e79a60de680086b1d93fcc3629b463f58bd
+> which is supposed to fix the bug is sufficient.  Even if it does it
+> certainly isn't pretty.  But also it is concerning that people who
+> have decided to make extensive use of advanced features of the Linux
+> system call interface apparently aren't aware of important and
+> hopefully well-known dangers in facilities such as cross-trust-domain
+> fd passing.
+Personally, I don’t know about every little detail in fd passing
+either. If I read you correctly, you seem to be saying one needs to be
+an expert in a given area before being allowed to write code in it. I
+think it works the other way around: by writing code in that area, you
+become an expert in it.
+
+The general statement from your side here seems to be (exaggerating a
+bit for the sake of discussion): “look, this software has bugs, even
+security bugs, so let’s not use it”. While I certainly would not want to
+switch to an extremely buggy software myself either, I think we all know
+that software is never entirely free of bugs. Expecting an absence of
+bugs even before starting to use that software certainly is
+unrealistic.
+
+Moreover, consider that whole classes of bugs existed before, spread out
+in the various init scripts, which are obsolete thanks to systemd’s
+design, these two just being trivial examples off the top of my head:
+
+• improperly sanitized environment, see e.g.
+  https://bugzilla.redhat.com/show_bug.cgi?id=990321
+
+• runaway scripts (e.g. cgi-bin) that spawn children and escape the main
+  daemon (e.g. apache2) being stopped.
+
+Instead of focusing on the actual security issues, what I’d much rather
+look at is the process with which such bugs are fixed. I.e. are security
+problems acknowledged as such, are they fixed clearly and in a timely
+manner? Are there enough eyes looking at the project to uncover, report
+and collaborate in fixing the issues?
+
+Also, and I think that should go without saying, if this branch of the
+discussion is considered as reasoning against systemd in the decision
+process, I’d like to see similar data on the other init systems :).
+
+Thanks.
+
+-- 
+Best regards,
+Michael
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 29 Nov 2013 02:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 29 Nov 2013 02:09:04 GMT) (full text, mbox, link).

+ +

Message #598 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Michael Stapelberg <stapelberg@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Thu, 28 Nov 2013 20:07:16 -0600
+
+
[Message part 1 (text/plain, inline)]
+
On Thu, Nov 28, 2013 at 11:15:09PM +0100, Michael Stapelberg wrote:
+> > I should say that it is hard to write code with no security bugs at
+> > all.  But I think our benchmark for security bugs in our init system
+> > ought to be "very few", particularly if we are making a specific
+> > implementation effectively mandatory.  And I don't think I would like
+> > to accept justifications (for a large bug count) along the lines of
+> > "but systemd does so much more"; I think the security bugs that come
+> > with a large codebase, or having more functionality exposed to
+> > ordinary users, are a direct and very relevant downside to such a
+> > large codebase or large attack surface.
+> They sure are. OTOH, chosing the init system that receives the most
+> attention in form of development and is adopted by many other
+> distributions helps us a lot with security issues. They are no longer
+> just our problem, but other distributions also care about getting them
+> fixed quickly.
+
+All distributions "care" about not having security issues in their code, but
+that's not the same thing as actually doing the work to audit the code.  In
+practice this only happens when dedicated resources are turned on the code
+in question, and having more companies using the code does not magically
+make that happen.
+
+I don't know that the upstart code has been subjected to any sort of
+comprehensive security audit.  I also don't know whether the auditing that's
+been done on systemd qualifies as comprehensive.  I *will* assert that
+upstart development is aimed at avoiding extraneous features precisely to
+reduce the risk of bugs (security or otherwise).
+
+> > There are a couple of filesystem races (CVE-2012-1174, CVE-2013-4392)
+> > which I think a concurrent init system author ought really to be
+> > competent to avoid.  (And the system should be designed, so far as
+> > possible, to reduce the opportunity for such races.)
+> “a concurrent init system author” sounds strange on multiple counts:
+> systemd was not written by one author. It is also not concurrent (in
+> fact it is single-threaded and only links to pthreads to call sync
+> asynchronously on shutdown), but event-based. As for competency, I am
+> sure that everybody involved has learned their lesson and will avoid
+> such issues in the future.
+
+Are the systemd developers novice programmers, that they need to learn to
+program securely by trial and error?
+
+The reality is that the kind of security bugs that we're talking about are
+very subtle, and even experienced developers are going to make mistakes like
+this from time to time, and as one of the arguments advanced for systemd is
+that it has a large community of contributors, not all of those contributors
+are going to be experienced developers.  A project's security record has at
+least as much to do with having a solid design to reduce the attack surface,
+as it does with the developers' skill.
+
+> I am also sure that other init systems have (had) similar bugs.  And if
+> there is no evidence of that yet, maybe nobody looked really closely yet…? 
+> :)
+
+Unless you're offering to do a security audit of upstart, I don't think such
+speculation changes anything.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 29 Nov 2013 12:39:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 29 Nov 2013 12:39:05 GMT) (full text, mbox, link).

+ +

Message #603 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Michael Stapelberg <stapelberg@debian.org>, + 727708@bugs.debian.org, + Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question) [and 1 more messages]
+
Date: Fri, 29 Nov 2013 12:37:23 +0000
+
+
Uoti Urpala writes ("Bug#727708: systemd (security) bugs (was: init system question)"):
+> [Ian Jackson:]
+> > Here are a couple of exciting snippets:
+> > https://bugzilla.redhat.com/show_bug.cgi?id=708537
+> > 
+> >   Problems with runlevel emulation doing mad things.  It isn't clear
+> >   to me whether this bug is a symptom of a fundamental problem with
+> >   systemd's state-based dependency model, or whether it's simply a
+> 
+> I think it's completely obvious that there is no "fundamental problem".
+> I wonder what could make you consider it a possible symptom of one.
+> 
+> >   missing feature or perhaps even wrong default configuration.  But
+> >   the bug has been open for some time.
+> 
+> My guess is that most people do not consider that "exciting" or really
+> care - thinking of system states in terms of "runlevels" is mostly
+> obsolete, and the flaws do not bother many people in the cases where
+> backwards compatibility is still needed.
+
+Statements like this are part of what make me think this might be a
+fundamental problem.  When a systemd proponent tells me that a
+particular use pattern is unimportant or wrongheaded, I tentatively
+infer that systemd cannot support it properly.
+
+It seems to me that the difficulties with the runlevel emulation are
+likely to affect other similar use patterns too.  The problems don't
+seem specific to the nature of runlevels.  Perhaps they are specific
+to the way runlevels are emulated by systemd but in that case that
+emulation should surely be fixed.
+
+
+Michael Stapelberg writes ("Bug#727708: systemd (security) bugs (was: init system question)"):
+> [Ian Jackson:]
+> > There are a couple of filesystem races (CVE-2012-1174, CVE-2013-4392)
+> > which I think a concurrent init system author ought really to be
+> > competent to avoid.  (And the system should be designed, so far as
+> > possible, to reduce the opportunity for such races.)
+>
+> “a concurrent init system author” sounds strange on multiple counts:
+> systemd was not written by one author. It is also not concurrent (in
+> fact it is single-threaded and only links to pthreads to call sync
+> asynchronously on shutdown), but event-based.
+
+systemd, like upstart, is concurrent in that it does more than one
+thing at once.  In particular, it does concurrent startup of
+services.
+
+One of the main potential advantages of a new approach to service
+management is that it is less racy.  This advantage depends on the
+authors of the replacement having thought about the problems in the
+right way, and not written racy code.
+
+> As for competency, I am sure that everybody involved has learned
+> their lesson and will avoid such issues in the future.
+
+My point was that someone who is writing an init system for concurrent
+startup and dynamic service management needs to have a good
+understanding of concurrent system design, and in particular of race
+hazards.  I wouldn't expect a person or people who had such an
+understanding to make many mistakes of the kind seen here.
+
+
+> > The "systemctl status" resource usage DoS (CVE-2012-1101) is an
+> > understandable resource leak, given systemd's design.  But for me it
+> > raises this question: why is the system designed in such a way that
+> > the critical pid 1 is required to implement functionality (and
+> > unprivileged-facing interfaces) in which such a resource leak is (a) a
+> > likely programming error and then (b) exposed so as to be exploitable.
+>
+> a) I think “a likely programming error” is an exaggeration. Do you have
+>    data on how often there were resource leaks in systemd?
+
+AIUI from reading the advisories (I haven't read the code) this was a
+simple memory leak bug.
+
+> b) I am unclear on how exactly this was exploitable, and the bugs lack
+>    explanation unfortunately.
+
+AIUI the exploit works as follows: the attacker runs "systemctl status
+<blah>" where <blah> is a random invented unit name.  They then repeat
+this millions of times.  Each time systemd allocates memory to record
+this phantom unit; this memory is never freed.  Eventually some kind
+of resource is exhaused (e.g. RAM, address space, ulimit) and systemd
+stops working properly.
+
+> Furthermore, I think Lennart’s explanation of why arbitrary units must
+> be able to be created is fair:
+> https://bugzilla.redhat.com/show_bug.cgi?id=680122#c1
+
+How was CVE-2012-1101 fixed ?  That bug doesn't show the patch.
+
+[later:]
+
+I went and looked and found this:
+
+http://cgit.freedesktop.org/systemd/systemd/commit/?id=9a46fc3b9014de1bf0ed1f3004a536b08a19ebb3
+
+It looks like the appropriate gc function was simply not called.  As I
+thought, an understandable programming error, but one which exists
+only because of (perhaps essential) complexity in the code.
+
+More importantly it is one which is exploitable only as a consequence
+of the questionable design decision to expose pid 1 to ordinary users.
+
+
+> > AIUI the journald integer overflow (CVE-2013-4391) is a remotely
+> > exploitable bug, if you have configured journald to allow remote
+> > logging.  (I assume this isn't the default configuration but haven't
+> > checked.)
+>
+> journald does not provide remote logging. See
+> https://lists.fedoraproject.org/pipermail/devel/2013-July/185585.html
+
+Err, so I don't understand then why CVE report this vulnerability as
+follows:
+
+| Integer overflow in the valid_user_field function in
+| journal/journald-native.c in systemd allows remote attackers to
+| cause a denial of service (crash) and possibly execute arbitrary
+| code via a large journal data field, which triggers a heap-based
+| buffer overflow.
+
+If journald doesn't support remote logging, how is this vulnerability
+remotely exploitable ?
+
+
+> Personally, I don’t know about every little detail in fd passing
+> either. If I read you correctly, you seem to be saying one needs to be
+> an expert in a given area before being allowed to write code in it. I
+> think it works the other way around: by writing code in that area, you
+> become an expert in it.
+
+What a startling statement.  This is not some desktop toy we are
+talking about; this is critical core system infrastructure.
+
+I would prefer my pid 1 to have been written by experts.  It appears
+that you are saying that systemd wasn't and that this isn't important!
+
+
+> Instead of focusing on the actual security issues, what I’d much rather
+> look at is the process with which such bugs are fixed. I.e. are security
+> problems acknowledged as such, are they fixed clearly and in a timely
+> manner? Are there enough eyes looking at the project to uncover, report
+> and collaborate in fixing the issues?
+
+I don't think having a functioning security response process is a
+substitute for good system design, and a high initial code quality.
+
+And I don't think that "many eyes" is as helpful as you apparently
+think.  Security code review is bloody hard work.
+
+
+> Also, and I think that should go without saying, if this branch of the
+> discussion is considered as reasoning against systemd in the decision
+> process, I’d like to see similar data on the other init systems :).
+
+You are of course welcome to go and find that information.
+
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 29 Nov 2013 16:57:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 29 Nov 2013 16:57:15 GMT) (full text, mbox, link).

+ +

Message #608 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Fri, 29 Nov 2013 17:55:39 +0100
+
+
Le jeudi 28 novembre 2013 à 13:43 +0000, Ian Jackson a écrit : 
+> In summary, I agree with Andrew Kanaber's view that the security and
+> bug history of systemd is worrying.
+
+Personally, I find the flow of bugs (including security bugs) for
+moderately recent software the sign of a healthy project. A simple look
+at a few packages in the BTS will show that packages with lots of
+reported bugs are packages with lots of users and features, regardless
+of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come
+to mind as being full of bugs, including security bugs.
+
+Indeed, systemd has not been written with security in mind. Neither have
+sysvinit nor upstart, AFAICT. Yes, it would be better if *all*
+developers had a better grasp of secure programming, but on the other
+hand, asking the first people to use some advanced kernel interfaces to
+understand all their security implications is unfair. Just like we don’t
+hold the Mozilla developers responsible for security issues in brand-new
+Javascript engines that maybe 10 developers in the world could
+understand.
+
+As Michael mentioned, systemd has a broader scope than alternatives.
+You’d have to use a system providing similar features as a basis for a
+fair comparison, and such a system doesn’t really exist in the Unix
+world. If you only take into account the features that are also provided
+by upstart or sysvinit/insserv, you won’t find that many of these bugs
+apply. Compare that to the number of unfixable bugs in sysvinit due to
+broken design. 
+
+Cheers,
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 29 Nov 2013 17:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 29 Nov 2013 17:15:04 GMT) (full text, mbox, link).

+ +

Message #613 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Fri, 29 Nov 2013 17:11:52 +0000
+
+
Josselin Mouette writes ("Bug#727708: systemd (security) bugs (was: init system question)"):
+> Personally, I find the flow of bugs (including security bugs) for
+> moderately recent software the sign of a healthy project. A simple look
+> at a few packages in the BTS will show that packages with lots of
+> reported bugs are packages with lots of users and features, regardless
+> of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come
+> to mind as being full of bugs, including security bugs.
+
+All of those components are to a greater or lesser extent optional.
+What we are being asked is to make use of systemd mandatory.
+
+> Indeed, systemd has not been written with security in mind.
+
+What an alarming comment on a program which has ultimate privilege, is
+intended to be universally deployed even in the most demanding
+security environment, crosses security boundaries (without, IMO, a
+sufficient justification), and is being touted as the single
+systemwide manager for security features like cgroups !
+
+> Neither have sysvinit nor upstart, AFAICT.
+
+I will leave the upstart maintainers to comment on this in more
+detail, but sysvinit has had remarkably few security bugs for a
+program of its vintage.  This is because it has very few, and very
+restricted, interfaces to untrusted parts of the system.
+
+>  Just like we don’t hold the Mozilla developers responsible
+> for security issues in brand-new Javascript engines that maybe 10
+> developers in the world could understand.
+
+The security record of web browsers is indeed atrocious.  It is the
+result of a persistent swamp of bad design decisions, hideous
+overcomplexity, plain bad code, and lack of attention to mitigation
+measures.  Google's efforts in this area are to be applauded, even
+though I have serious privacy problems with Google.
+
+It is very alarming that web browsers are being presented as the
+security benchmark for our new init system.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 29 Nov 2013 17:39:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 29 Nov 2013 17:39:05 GMT) (full text, mbox, link).

+ +

Message #618 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Fri, 29 Nov 2013 11:35:20 -0600
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Nov 29, 2013 at 05:55:39PM +0100, Josselin Mouette wrote:
+> Indeed, systemd has not been written with security in mind. Neither have
+> sysvinit nor upstart, AFAICT.
+
+I wouldn't presume to say whether the systemd authors had security in mind
+while writing it.  But I will stand by the overall security design of either
+sysvinit or upstart, namely that the user-accessible interfaces are kept as
+small as possible to make them as auditable as possible.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 29 Nov 2013 18:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 29 Nov 2013 18:21:04 GMT) (full text, mbox, link).

+ +

Message #623 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Fri, 29 Nov 2013 19:18:33 +0100
+
+
Le vendredi 29 novembre 2013 à 17:11 +0000, Ian Jackson a écrit : 
+> Josselin Mouette writes ("Bug#727708: systemd (security) bugs (was: init system question)"):
+> > Personally, I find the flow of bugs (including security bugs) for
+> > moderately recent software the sign of a healthy project. A simple look
+> > at a few packages in the BTS will show that packages with lots of
+> > reported bugs are packages with lots of users and features, regardless
+> > of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come
+> > to mind as being full of bugs, including security bugs.
+> 
+> All of those components are to a greater or lesser extent optional.
+
+Linux is optional?
+X is optional? Not for everyone. (X is a bad example anyway, because,
+unlike the rest, it *has* a bad security design.)
+
+> What we are being asked is to make use of systemd mandatory.
+
+It doesn’t mean that all of systemd’s features should be enabled on all
+machines. The reason why embedded manufacturers are sponsors for
+systemd’s development is that it means less code, and therefore less
+bugs (security or not), than alternatives.
+
+> > Indeed, systemd has not been written with security in mind.
+> 
+> What an alarming comment on a program which has ultimate privilege, is
+> intended to be universally deployed even in the most demanding
+> security environment, crosses security boundaries (without, IMO, a
+> sufficient justification), and is being touted as the single
+> systemwide manager for security features like cgroups !
+
+Only an extreme minority of Debian packages have been written with
+security in mind. Not all packages can be OpenSSH or Postfix, and we
+have to live with that fact, because we need the features in other
+packages (starting with a kernel and libc).
+
+> > Neither have sysvinit nor upstart, AFAICT.
+> 
+> I will leave the upstart maintainers to comment on this in more
+> detail, but sysvinit has had remarkably few security bugs for a
+> program of its vintage.  This is because it has very few, and very
+> restricted, interfaces to untrusted parts of the system.
+
+And of course, there has never been any buggy init script.
+
+Again, your comparison doesn’t make any sense since you don’t compare
+similar functionality scopes.
+
+> >  Just like we don’t hold the Mozilla developers responsible
+> > for security issues in brand-new Javascript engines that maybe 10
+> > developers in the world could understand.
+> 
+> The security record of web browsers is indeed atrocious.  It is the
+> result of a persistent swamp of bad design decisions, hideous
+> overcomplexity, plain bad code, and lack of attention to mitigation
+> measures.  Google's efforts in this area are to be applauded, even
+> though I have serious privacy problems with Google.
+
+I’m afraid you don’t entirely understand why the security record of web
+browsers looks atrocious. Because of a swamp of bad decisions *from web
+developers and designers*, backed by users, browsers have to cover a
+functional scope that far exceeds in complexity any other kind of
+software. A typical browser has to include several virtual machines,
+graphical/layout toolkits, JIT compilers, advanced cryptographic
+software, all of which have to work with heaps of untrusted data. When
+taking all of that into account, as much as I hate dealing with them, I
+have to admit the security record for several browsers is good, and it’s
+because they *are* developed with security in mind.
+
+> It is very alarming that web browsers are being presented as the
+> security benchmark for our new init system.
+
+It is quite alarming that a member of the Technical Committee
+demonstrates lacks in security knowledge while at the same time using
+security bugs as a measure for comparing solutions.
+
+
+This “security” discussion has nothing to do with the case in point,
+though. If you have specific points you want addressed by the systemd
+position (like how systemd’s upstream designs user interfaces to avoid
+security bugs, or handles security alerts), please state them clearly
+and I will do my best to gather information for you and answer them.
+
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 29 Nov 2013 18:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 29 Nov 2013 18:36:04 GMT) (full text, mbox, link).

+ +

Message #628 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Fri, 29 Nov 2013 19:32:32 +0100
+
+
* Josselin Mouette (joss@debian.org) [131129 19:21]:
+> It is quite alarming that a member of the Technical Committee
+> demonstrates lacks in security knowledge
+
+I would prefer if you could stop doing ad-hominem attacks (independend
+on whom - this is not an acceptable behaviour).
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 29 Nov 2013 19:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 29 Nov 2013 19:03:04 GMT) (full text, mbox, link).

+ +

Message #633 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Fri, 29 Nov 2013 13:58:47 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Nov 29, 2013 at 05:11:52PM +0000, Ian Jackson wrote:
+> It is very alarming that web browsers are being presented as the
+> security benchmark for our new init system.
+
+So, I tend to agree with Joss here - Web browsers is the biggest attack
+surface that we have today, bar none. I don't think anyone really
+disputes this.
+
+The safety of modern web browsers is (well, minus a qualifier below), frankly,
+shockingly good.
+
+The amount of exploits from JS is crazy low for something that's able to
+do so much (store data locally, use WebGL / 3D rendering, play audio),
+it is shockingly hard to exploit.
+
+When you look at the entire stack (CSS parsers / evaluators, HTML
+parsers & evaluators, JS parsers and evaluators), the only disaster
+would be stuff like ActiveX. I'm not sure of it's state, since I've
+never run a platform that supports it, but I hear it's getting better.
+
+So, yes, browsers are a cespool, but it's one that runs complete garbage
+on the internet.
+
+I'd be stunningly happy to see an init system that can handle as much
+pure crap as browsers have to put up with :)
+
+
+More on-topic, I do think that the systemd bugs are more likely because
+people are playing with the code, exploring it for holes, and pushing
+them, which is healthy. I'm sure if you poked hard enough, most systems
+would show such bugs. (as has been already said, really)
+
+
+Cheers,
+  Paul
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>
+: :'  : Proud Debian Developer
+`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+ `-     http://people.debian.org/~paultag
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :
+Bug#727708; Package tech-ctte. + (Fri, 29 Nov 2013 20:12:03 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 29 Nov 2013 20:12:03 GMT) (full text, mbox, link).

+ +

Message #638 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question) + [and 1 more messages]
+
Date: Fri, 29 Nov 2013 22:09:29 +0200
+
+
On Fri, 2013-11-29 at 12:37 +0000, Ian Jackson wrote:
+> Uoti Urpala writes ("Bug#727708: systemd (security) bugs (was: init system question)"):
+> > My guess is that most people do not consider that "exciting" or really
+> > care - thinking of system states in terms of "runlevels" is mostly
+> > obsolete, and the flaws do not bother many people in the cases where
+> > backwards compatibility is still needed.
+> 
+> Statements like this are part of what make me think this might be a
+> fundamental problem.  When a systemd proponent tells me that a
+> particular use pattern is unimportant or wrongheaded, I tentatively
+> infer that systemd cannot support it properly.
+
+At least here this logic led you to the wrong conclusion, so you might
+want to reconsider it.
+
+> It seems to me that the difficulties with the runlevel emulation are
+> likely to affect other similar use patterns too.  The problems don't
+> seem specific to the nature of runlevels.  Perhaps they are specific
+> to the way runlevels are emulated by systemd but in that case that
+> emulation should surely be fixed.
+
+The issue was legacy runlevel changes being simply mapped to "isolate
+new_runlevel", which does not have quite the same semantics as sysvinit
+runlevel changes (most importantly, it stops everything not in the
+new_runlevel target, without limiting to only things that were part of
+original runlevel target). There's no reason why the set of services to
+stop could not be calculated in a way closer to sysvinit semantics. But
+there's little reason to deal with "runlevels" at all when using
+systemd, and it seems most people don't. So while the backwards
+compatibility support could be improved (probably rather easily), I
+think it's clear why this has not been a priority for either developers
+or users.
+
+
+> More importantly it is one which is exploitable only as a consequence
+> of the questionable design decision to expose pid 1 to ordinary users.
+
+I think there are good reasons to allow querying status directly. One
+sanity check that IMO should be kept in mind for perspective when
+considering any "even one DoS issue in PID 1 is a catastrophe" arguments
+is that Debian will always require running a kernel, and there have been
+lots of DoS or worse issues there. Unless you expect the majority of
+Debian users to move to minimal microkernels in the near future, there
+is little basis to demand an absolutely minimal init process when the
+kernel contains much more code in a more critical role.
+
+The same applies to this:
+> and is being touted as the single systemwide manager for security
+> features like cgroups !
+
+Parts of the implementation for this are on the kernel side, parts on
+the systemd side. I see no reason to think that the systemd side would
+be the more problematic one.
+
+
+
+
+
+ +

+ + +Information stored +:
+Bug#727708; Package tech-ctte. + (Fri, 29 Nov 2013 20:57:06 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and filed, but not forwarded. + (Fri, 29 Nov 2013 20:57:06 GMT) (full text, mbox, link).

+ +

Message #643 received at 727708-quiet@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: debian-ctte@lists.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Fri, 29 Nov 2013 20:32:16 +0000
+
+
As a system administrator, the idea of a 'kitchen sink' init system
+terrifies me.  I would need exceptionally high confidence in its authors
+and design principles before allowing it to run as root on my systems
+and depend on it to boot even to single user.  I wouldn't even invest
+much time enquiring into this, if I knew I could manage with something
+simpler having less scope for security/reliability bugs.
+
+OTOH I would be much more forgiving if this were being used for, say,
+employees' own desktop machines in a protected corporate IT environment.
+ Lots of systemd's features seem particularly convenient for that use
+case.  And security is enforced in other ways there (the only people
+with access at all, know they risk getting fired for trying to escalate
+privileges or DoS).
+
+Adopting systemd may have been much simpler if it had been separate from
+and launched by the simple init, starting only the services that have
+unit files because they really require its functionality.  If no
+installed software on that system needs it, it wouldn't even need to be
+installed.
+
+But otherwise I think there are GNU/Linux users who want the choice of
+using systemd or being able to use something else.  Preferably without
+having to switch a different distro or third-party derivative.
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :
+Bug#727708; Package tech-ctte. + (Fri, 29 Nov 2013 21:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 29 Nov 2013 21:36:04 GMT) (full text, mbox, link).

+ +

Message #648 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to + in Debian.
+
Date: Fri, 29 Nov 2013 21:32:44 +0000
+
+
The original question was which init system[s] are going to be the
+default.  But there are still some other things I'm curious about:
+
+1. we already have alternate init systems in the archive;  could it be
+some kind of release goal to ensure they are installable?  i.e. make it
+possible for them to satisfy the dependencies of essential packages.
+(Steve Langasek's metapackage idea in [0] seems to be in the right
+direction for accomplishing that, except it wouldn't work for OpenRC or
+indeed for keeping the original sysvinit/sysv-rc).
+
+[0]: http://lists.debian.org/debian-devel/2013/11/msg00389.html
+
+2. would exceptions be permitted;  could some packages explicitly depend
+on a non-default init system if it's the only one providing
+functionality it needs (and still be part of a stable release)?  I'm
+thinking that GNOME might (someday, if replacements for logind or other
+APIs can't be found) want to do this, if systemd isn't chosen as the
+sole default on GNU/Linux.  (It seems similar to a maintainer being able
+to restrict packages to Arch: linux-any if they cannot / do not want to
+support non-Linux ports).
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 30 Nov 2013 08:48:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 30 Nov 2013 08:48:09 GMT) (full text, mbox, link).

+ +

Message #653 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Sat, 30 Nov 2013 09:44:02 +0100
+
+
Le vendredi 29 novembre 2013 à 17:55 +0100, Josselin Mouette a écrit : 
+> Indeed, systemd has not been written with security in mind.
+
+Obviously, such a subjective judgment of valor does not mean the same to
+me as to other developers. It is easy to quote it out of context and say
+“oh, look! some systemd advocate said that it is insecure! of course MY
+init system of choice is more secure!”, but it is merely a fallacy since
+we are not talking about the same thing.
+
+Therefore, I have to retract this statement. 
+
+-- 
+ .''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 30 Nov 2013 11:03:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Stapelberg <stapelberg@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 30 Nov 2013 11:03:10 GMT) (full text, mbox, link).

+ +

Message #658 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Stapelberg <stapelberg@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question) [and 1 more messages]
+
Date: Sat, 30 Nov 2013 12:00:27 +0100
+
+
Hi Ian,
+
+Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> My point was that someone who is writing an init system for concurrent
+> startup and dynamic service management needs to have a good
+> understanding of concurrent system design, and in particular of race
+> hazards.  I wouldn't expect a person or people who had such an
+> understanding to make many mistakes of the kind seen here.
+Neither do I, but there is no evidence for _many_ of these problems.
+
+>> Personally, I don’t know about every little detail in fd passing
+>> either. If I read you correctly, you seem to be saying one needs to be
+>> an expert in a given area before being allowed to write code in it. I
+>> think it works the other way around: by writing code in that area, you
+>> become an expert in it.
+>
+> What a startling statement.  This is not some desktop toy we are
+> talking about; this is critical core system infrastructure.
+>
+> I would prefer my pid 1 to have been written by experts.  It appears
+> that you are saying that systemd wasn't and that this isn't important!
+To clarify: I do think (most?) systemd authors are experts. I am also
+saying that experts can make mistakes, and that having the expectation
+that software has 0 bugs is unreasonable.
+
+I also stand by my statement that one cannot be an expert in a subject
+area before having experience in that subject area. Sure, one can
+prepare, but there is the proverb “practice makes perfect”.
+
+>> Instead of focusing on the actual security issues, what I’d much rather
+>> look at is the process with which such bugs are fixed. I.e. are security
+>> problems acknowledged as such, are they fixed clearly and in a timely
+>> manner? Are there enough eyes looking at the project to uncover, report
+>> and collaborate in fixing the issues?
+>
+> I don't think having a functioning security response process is a
+> substitute for good system design, and a high initial code quality.
+No argument there. I think having all three of them is better, and
+that’s my opinion of systemd, at least of pid 1, which I have looked at
+more closely than at the other parts of the larger system.
+
+>> Also, and I think that should go without saying, if this branch of the
+>> discussion is considered as reasoning against systemd in the decision
+>> process, I’d like to see similar data on the other init systems :).
+>
+> You are of course welcome to go and find that information.
+I may be misunderstanding how this works, but I strongly believe that if
+the ctte looks at the security track record of systemd, it MUST also
+look at the security track record of the other contenders. I.e., I
+consider it unfair to say “we’re not using systemd because it had
+security bugs, we’ll chose X instead, but we didn’t look at its security
+at all”.
+
+That said, I’d love to help, but I don’t have the time to look at the
+security track record of other init systems in detail. Sorry.
+
+-- 
+Best regards,
+Michael
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 30 Nov 2013 15:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Moritz Mühlenhoff <jmm@inutil.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 30 Nov 2013 15:09:04 GMT) (full text, mbox, link).

+ +

Message #663 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Moritz Mühlenhoff <jmm@inutil.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: Michael Stapelberg <stapelberg@debian.org>, 727708@bugs.debian.org, + Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Sat, 30 Nov 2013 16:07:17 +0100
+
+
On Thu, Nov 28, 2013 at 08:07:16PM -0600, Steve Langasek wrote:
+> All distributions "care" about not having security issues in their code, but
+> that's not the same thing as actually doing the work to audit the code.  In
+> practice this only happens when dedicated resources are turned on the code
+> in question, and having more companies using the code does not magically
+> make that happen.
+
+[I took care of the systemd DSA people are referring to]
+
+The issue people are talking about were discovered during a review of
+the Red Hat Product Security Team (most likely triggered by the inclusion
+of systemd into RHEL7).
+So in fact having more companies use the code exactly made that magically
+happen.
+
+For every complex code base a thorough review will unveil security-related
+implementation bugs and the ones found for systemd are not exactly earth-
+shattering.
+
+More review and more usage will lead to more bugs being found, we should
+rather applaud Red Hat for investing resources and be diligent. After all
+Red Hat is the only distro staffing a proactive product security team
+(from which everyone is profiting outside of RH as well). I don't consider
+the lack of reported security issues for the contenders as a credible 
+indication of them being more secure.
+
+FWIW, the main reason I'm personally in favour of adopting systemd is precisely 
+security (in terms of sandboxing and restricting services). See
+http://0pointer.de/blog/projects/security.html for some pointers.
+
+[EOD from me due to a lack of time, but that needed to be said]
+
+Cheers,
+        Moritz
+
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 30 Nov 2013 15:30:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Lars Wirzenius <liw@liw.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 30 Nov 2013 15:30:08 GMT) (full text, mbox, link).

+ +

Message #668 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Lars Wirzenius <liw@liw.fi>
+
To: Moritz Mühlenhoff <jmm@inutil.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Sat, 30 Nov 2013 15:18:40 +0000
+
+
On Sat, Nov 30, 2013 at 04:07:17PM +0100, Moritz Mühlenhoff wrote:
+> [EOD from me due to a lack of time, but that needed to be said]
+
+And thank you for saying it.
+
+-- 
+http://www.cafepress.com/trunktees -- geeky funny T-shirts
+http://gtdfh.branchable.com/ -- GTD for hackers
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 01 Dec 2013 18:12:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 01 Dec 2013 18:12:14 GMT) (full text, mbox, link).

+ +

Message #673 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Moritz Mühlenhoff <jmm@inutil.org>
+
Cc: Michael Stapelberg <stapelberg@debian.org>, 727708@bugs.debian.org, + Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Sun, 1 Dec 2013 12:11:11 -0600
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Nov 30, 2013 at 04:07:17PM +0100, Moritz Mühlenhoff wrote:
+> On Thu, Nov 28, 2013 at 08:07:16PM -0600, Steve Langasek wrote:
+> > All distributions "care" about not having security issues in their code, but
+> > that's not the same thing as actually doing the work to audit the code.  In
+> > practice this only happens when dedicated resources are turned on the code
+> > in question, and having more companies using the code does not magically
+> > make that happen.
+
+> [I took care of the systemd DSA people are referring to]
+
+> The issue people are talking about were discovered during a review of the
+> Red Hat Product Security Team (most likely triggered by the inclusion of
+> systemd into RHEL7).
+> So in fact having more companies use the code exactly made that magically
+> happen.
+
+No, this is a function of one specific company having a proactive security
+review policy (for which they should be commended).  It has nothing to do
+with how many companies are using the software.
+
+> More review and more usage will lead to more bugs being found, we should
+> rather applaud Red Hat for investing resources and be diligent. After all
+> Red Hat is the only distro staffing a proactive product security team
+> (from which everyone is profiting outside of RH as well). I don't consider
+> the lack of reported security issues for the contenders as a credible 
+> indication of them being more secure.
+
+Red Hat shipped upstart as their init system in RHEL 6.  This did not result
+in any CVEs being issued for upstart.  What conclusions should we draw from
+this?
+
+> FWIW, the main reason I'm personally in favour of adopting systemd is
+> precisely security (in terms of sandboxing and restricting services).  See
+> http://0pointer.de/blog/projects/security.html for some pointers.
+
+I think such built-in sandboxing features are interesting, but not decisive.
+They represent an incremental improvement over the status quo for
+sandboxing, and aren't anything that couldn't be delivered as a feature in
+upstart, for example, if there were demand for it.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 01 Dec 2013 18:12:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sune Vuorela <sune@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 01 Dec 2013 18:12:17 GMT) (full text, mbox, link).

+ +

Message #678 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sune Vuorela <sune@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Sun, 01 Dec 2013 18:49:51 +0100
+
+
On Thursday 28 November 2013 13:43:27 Ian Jackson wrote:
+> > CVE		summary					Debian BTS	Redhat
+> > 2012-0871	systemd-logind insecure file creation	?		795853
+
+> Furthermore, I think it is fair to look at bugs in non-pid-1 parts of
+> the systemd codebase when assessing the likely code quality of the pid
+> 1 parts.
+
+Note that the non-pid1-parts of systemd, like logind for example, are pieces 
+we need no matter what init system we choose. The question is more if we can 
+use them as provided by upstream or we need to adapt them in Debian.
+
+/Sune
+-- 
+How to close the space bar?
+
+First from the control drawer inside Office 8.7.5 you should ping the site of 
+the controller for logging on a BIOS.
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 01 Dec 2013 20:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 01 Dec 2013 20:24:04 GMT) (full text, mbox, link).

+ +

Message #683 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org, Moritz Mühlenhoff + <jmm@inutil.org>, Michael Stapelberg <stapelberg@debian.org>
+
Subject: Re: Bug#727708: systemd (security) bugs
+
Date: Sun, 01 Dec 2013 12:22:08 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+> On Sat, Nov 30, 2013 at 04:07:17PM +0100, Moritz Mühlenhoff wrote:
+
+>> The issue people are talking about were discovered during a review of
+>> the Red Hat Product Security Team (most likely triggered by the
+>> inclusion of systemd into RHEL7).  So in fact having more companies use
+>> the code exactly made that magically happen.
+
+> No, this is a function of one specific company having a proactive security
+> review policy (for which they should be commended).  It has nothing to do
+> with how many companies are using the software.
+
+I don't think that's strictly true.  The more organizations use a piece of
+software, the more likely one or more of them will have proactive security
+review policies and will do such reviews.  In other words, the size of the
+community is relevant to how much security verification software gets.
+
+> I think such built-in sandboxing features are interesting, but not
+> decisive.  They represent an incremental improvement over the status quo
+> for sandboxing, and aren't anything that couldn't be delivered as a
+> feature in upstart, for example, if there were demand for it.
+
+I don't think capability is really the discussion that we're having, at
+least in the comparison between systemd and upstart's init components.
+The question is more whether there are sufficient resources in the upstart
+community that such development is likely.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 01 Dec 2013 20:24:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Raphael Hertzog <hertzog@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 01 Dec 2013 20:24:07 GMT) (full text, mbox, link).

+ +

Message #688 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Raphael Hertzog <hertzog@debian.org>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Cc: Moritz Mühlenhoff <jmm@inutil.org>, + Michael Stapelberg <stapelberg@debian.org>
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Sun, 1 Dec 2013 21:22:47 +0100
+
+
Hi,
+
+On Sun, 01 Dec 2013, Steve Langasek wrote:
+> > More review and more usage will lead to more bugs being found, we should
+> > rather applaud Red Hat for investing resources and be diligent. After all
+> > Red Hat is the only distro staffing a proactive product security team
+> > (from which everyone is profiting outside of RH as well). I don't consider
+> > the lack of reported security issues for the contenders as a credible 
+> > indication of them being more secure.
+> 
+> Red Hat shipped upstart as their init system in RHEL 6.
+
+The more interesting information in all this is why RHEL is switching over
+from upstart to systemd?
+
+I mean we have an incentive to switch to something else because we can't
+reliably fix stuff with sysvinit. But if upstart was satisfactory at that
+level, what are the reasons why RHEL is switching again?
+
+Maybe the security features discussed here are part of the answer, I don't
+know.
+
+> > FWIW, the main reason I'm personally in favour of adopting systemd is
+> > precisely security (in terms of sandboxing and restricting services).  See
+> > http://0pointer.de/blog/projects/security.html for some pointers.
+> 
+> I think such built-in sandboxing features are interesting, but not decisive.
+> They represent an incremental improvement over the status quo for
+> sandboxing, and aren't anything that couldn't be delivered as a feature in
+> upstart, for example, if there were demand for it.
+
+I believe that those who need those features just decide to use systemd
+and won't "demand" those features to the upstart upstreams. In particular
+when those features are of particular interest to people who are building
+heavily customized systems (think embedded devices) and are not wary of
+diverging from the defaults.
+
+Cheers,
+-- 
+Raphaël Hertzog ◈ Debian Developer
+
+Discover the Debian Administrator's Handbook:
+→ http://debian-handbook.info/get/
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 01 Dec 2013 21:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 01 Dec 2013 21:54:04 GMT) (full text, mbox, link).

+ +

Message #693 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Sune Vuorela <sune@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Sun, 1 Dec 2013 21:50:49 +0000
+
+
Sune Vuorela writes ("Bug#727708: systemd (security) bugs (was: init system question)"):
+> Note that the non-pid1-parts of systemd, like logind for example, are pieces 
+> we need no matter what init system we choose. The question is more if we can 
+> use them as provided by upstream or we need to adapt them in Debian.
+
+Whether Debian' "uses" something is a lot more granular than that.
+It seems to me that there are plenty of systems which could do without
+logind, at least if we're not using systemd as pid 1.
+
+This leads me to a question which I find myself asking, after reading
+the systemd debate page:
+
+If we were to adopt systemd as pid 1, which sections of the systemd
+source code would we probably want to adopt as well ?  Or to put it
+another way, which other existing programs would be obsoleted ?
+
+This is important for two reasons that I can think of:
+
+Firstly, it is touted as an advantage of systemd that it provides in a
+good and proper way this other functionality; it seems that the
+systemd designers consider that these other ad-hoc programs or
+facilities are crufty and in need of replacement.  So I would like to
+know which these other facilities are, that are going to be improved.
+
+Secondly, if we are, for example, to compare the total LOC count, or
+the bug list, or the CVE history, of systemd, with that of a
+non-systemd system, we need to know which parts of the old system are
+replaced.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 01 Dec 2013 22:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 01 Dec 2013 22:00:04 GMT) (full text, mbox, link).

+ +

Message #698 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: systemd and support for other distros
+
Date: Sun, 1 Dec 2013 21:56:28 +0000
+
+
In the systemd statement we see:
+
+  Systemd's upstream is very accommodating to distributors. They are
+  taking a lot of Debian's needs into account, even though it has not
+  yet been decided to make it the default.
+
+The upstart statement says:
+
+  systemd upstream paints a utopian vision where upstream services all
+  ship with systemd unit files that Just Work everywhere (despite the
+  fact that even trivial failures to comply with Debian policy in
+  systemd units submitted upstream by Red Hat employees result in
+  non-portable systemd configurations).[1]
+
+The link [1] is to
+  https://lists.samba.org/archive/samba-technical/2013-February/090400.html
+in which there is a discussion about whether the Samba project ought
+to ship a systemd unit file which is compatible with Debian, or one
+which only works with distros which have decided to abolish the
+distinction between /usr and /.
+
+It's not clear to me from the discussion there exactly what systemd
+upstream's position on this kind of thing is.
+
+Can someone point us, for example, to a statement by the systemd
+upstreams about their support for separate /usr (or their non-support
+for it) ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 01 Dec 2013 22:15:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sune Vuorela <sune@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 01 Dec 2013 22:15:14 GMT) (full text, mbox, link).

+ +

Message #703 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sune Vuorela <sune@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Sun, 01 Dec 2013 23:11:43 +0100
+
+
On Sunday 01 December 2013 21:50:49 Ian Jackson wrote:
+> This leads me to a question which I find myself asking, after reading
+> the systemd debate page:
+> 
+> If we were to adopt systemd as pid 1, which sections of the systemd
+> source code would we probably want to adopt as well ?  Or to put it
+> another way, which other existing programs would be obsoleted ?
+
+logind is obsoleting consolekit and libpam-xdg. (Consolekit tracks wether or 
+not a user is sitting on the physical console or logged in. libpam-xdg ensures 
+that XDG_RUNTIME_DIR is handled according to the spec). Logind also ensures 
+that a user session actually can be terminated when she logs out.
+
+Logind is the most important one, and within a year or two all desktop 
+environments that wants to be slightly more advanced than TWM is going to need 
+it. Even Ubuntu is using logind and is iirc maintained there by Steve 
+Langasek.
+
+Consolekit was written by the same people as involved in systemd and is now 
+hopefully getting it right. Consolekit is abandoned upstream a couple of years 
+ago. Libpam-xdg was written by Steve Langasek for Ubuntu and has since been 
+abandoned in in Ubuntu favour of the systemd bits .
+
+Beside that, there are among others:
+the timezoned is ensuring a common way that applications can get notified when 
+the hosts timezone changes. KDE does have something for that that would be 
+obsoleted. I think most other systems requires restart of applications or 
+manual magic in each app.
+
+hostnamed is for notifying when hostname changes. KDE does have something for 
+that. I don't know who else.
+
+There are more parts, but that's where my research has ended so far. 
+
+/Sune
+-- 
+How to cancel a mailer to the proxy from Flash and from the folder inside DOS 
+97?
+
+You must log on a driver to debug a monitor.
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 01 Dec 2013 22:15:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 01 Dec 2013 22:15:18 GMT) (full text, mbox, link).

+ +

Message #708 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Sune Vuorela <sune@debian.org>
+
Subject: Re: Bug#727708: systemd (security) bugs
+
Date: Sun, 01 Dec 2013 14:14:45 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> If we were to adopt systemd as pid 1, which sections of the systemd
+> source code would we probably want to adopt as well ?  Or to put it
+> another way, which other existing programs would be obsoleted ?
+
+Yes, that's a good question.  We're already using udev, which is now part
+of systemd as I understand it.  We'll clearly want to use logind for at
+least GNOME (Ubuntu already does that), and I suspect for other desktop
+environments as well.  I think there are some other pieces that may
+replace other currently separate desktop components.
+
+It sounded like the new D-Bus service may also be important for desktop
+environments.
+
+Another point here is that it's sounding like we'll be using a lot of
+those services regardless, at least on systems that need them, which means
+that their security track record and bug rate is somewhat irrelevant for
+this discussion provided that running systemd doesn't force them to be
+running on systems that don't need them.  For example, if desktop
+environments using upstart are still going to be running logind, the
+logind part loses nothing from running systemd and gains something (easier
+integration that we don't have to maintain ourselves).  Similarly for
+udev.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 02 Dec 2013 01:42:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 02 Dec 2013 01:42:07 GMT) (full text, mbox, link).

+ +

Message #713 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Cc: Thomas Goirand <zigo@debian.org>, Josselin Mouette <joss@debian.org>
+
Subject: initsystem decision process: Finalizing position statements before + December 6th.
+
Date: Sun, 1 Dec 2013 17:40:17 -0800
+
+
As discussed in the most recent CTTE meeting, we expect all of the
+position statements to be finalized no later than this week. I believe
+that only the OpenRC statement is not yet finalized.
+
+CTTE members will be asking questions which are unclear from the
+position statements in the next two weeks to make sure that all of the
+technical details are understood by the committee. [Non-CTTE members
+should feel free to suggest questions too.]
+
+Position statement authors: I will attempt to keep
+https://wiki.debian.org/Debate/initsystem updated with links to the
+questions (and their summary) in this bug's (#727708) log, but feel free
+to answer them before I manage to get that updated. [If you are not
+already subscribed to the bug or to debian-ctte, please consider doing
+so too.[1]] (Other CTTE members have carte blanche to update that page
+too.)
+
+Lets try to keep things moving and cordial so we can make the best
+technical decision possible; thanks to everyone for their work so far!
+
+
+1: I apologize if anyone was missing mail to the bug too; I recently
+fixed a bug in EOC which was causing messages not to be sent to all but
+the first subscriber.
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+Nearly all men can stand adversity, but if you really want to test his
+character, give him power.
+ -- Abraham Lincoln
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 02 Dec 2013 05:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thomas Goirand <zigo@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 02 Dec 2013 05:00:05 GMT) (full text, mbox, link).

+ +

Message #718 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thomas Goirand <zigo@debian.org>
+
To: Don Armstrong <don@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: initsystem decision process: Finalizing position statements before + December 6th.
+
Date: Mon, 02 Dec 2013 12:56:37 +0800
+
+
On 12/02/2013 09:40 AM, Don Armstrong wrote:
+> As discussed in the most recent CTTE meeting, we expect all of the
+> position statements to be finalized no later than this week. I believe
+> that only the OpenRC statement is not yet finalized.
+
+Hi Don,
+
+That's not correct, I have stated it was done (after I confirmed that
+with upstream). Sorry if I didn't make this clear enough. So please go
+ahead! :)
+
+Thomas
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 02 Dec 2013 09:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 02 Dec 2013 09:00:05 GMT) (full text, mbox, link).

+ +

Message #723 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd and support for other distros
+
Date: Mon, 02 Dec 2013 09:28:23 +0100
+
+
]] Ian Jackson 
+
+> It's not clear to me from the discussion there exactly what systemd
+> upstream's position on this kind of thing is.
+> 
+> Can someone point us, for example, to a statement by the systemd
+> upstreams about their support for separate /usr (or their non-support
+> for it) ?
+
+http://lists.freedesktop.org/archives/systemd-devel/2013-November/014797.html
+
+So they see it as pointless, but will be supported for a long time.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 02 Dec 2013 11:24:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 02 Dec 2013 11:24:09 GMT) (full text, mbox, link).

+ +

Message #728 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs
+
Date: Mon, 2 Dec 2013 11:22:16 +0000
+
+
Russ Allbery writes ("Re: Bug#727708: systemd (security) bugs"):
+> Another point here is that it's sounding like we'll be using a lot of
+> those services regardless, at least on systems that need them, which means
+> that their security track record and bug rate is somewhat irrelevant for
+> this discussion provided that running systemd doesn't force them to be
+> running on systems that don't need them.  [...]
+
+I don't think that's entirely true.  I think it is fair to look at the
+security history of other parts of the same project as indicative
+regarding code quality.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 02 Dec 2013 16:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 02 Dec 2013 16:48:04 GMT) (full text, mbox, link).

+ +

Message #733 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs
+
Date: Mon, 02 Dec 2013 17:45:08 +0100
+
+
Le lundi 02 décembre 2013 à 11:22 +0000, Ian Jackson a écrit : 
+> I don't think that's entirely true.  I think it is fair to look at the
+> security history of other parts of the same project as indicative
+> regarding code quality.
+
+There are two implied assumptions here: 
+      * that the same people are developing all components; 
+      * that develolpers have the same attention to code quality and
+        security in all components they work on.
+
+I don’t think either of them applies to systemd.
+
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 02 Dec 2013 17:27:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 02 Dec 2013 17:27:05 GMT) (full text, mbox, link).

+ +

Message #738 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Tollef Fog Heen <tfheen@err.no>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd and support for other distros
+
Date: Mon, 2 Dec 2013 11:25:02 -0600
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 02, 2013 at 09:28:23AM +0100, Tollef Fog Heen wrote:
+> ]] Ian Jackson 
+
+> > It's not clear to me from the discussion there exactly what systemd
+> > upstream's position on this kind of thing is.
+
+> > Can someone point us, for example, to a statement by the systemd
+> > upstreams about their support for separate /usr (or their non-support
+> > for it) ?
+
+> http://lists.freedesktop.org/archives/systemd-devel/2013-November/014797.html
+
+> So they see it as pointless, but will be supported for a long time.
+
+Note that the original complaint in the samba upstream discussion was about
+hard-coding of paths to system utilities, which a) is not portable between
+distributions and b) contradicts Debian policy.
+
+So systemd upstream may support separate /usr, but that doesn't change the
+fact that there are still portability issues when one starts writing systemd
+units.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 02 Dec 2013 19:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 02 Dec 2013 19:24:05 GMT) (full text, mbox, link).

+ +

Message #743 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs
+
Date: Mon, 02 Dec 2013 11:21:35 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Russ Allbery writes ("Re: Bug#727708: systemd (security) bugs"):
+
+>> Another point here is that it's sounding like we'll be using a lot of
+>> those services regardless, at least on systems that need them, which
+>> means that their security track record and bug rate is somewhat
+>> irrelevant for this discussion provided that running systemd doesn't
+>> force them to be running on systems that don't need them.  [...]
+
+> I don't think that's entirely true.  I think it is fair to look at the
+> security history of other parts of the same project as indicative
+> regarding code quality.
+
+Oh, sure, I do understand that part.  But when trying to draw inferences
+there, it's also important to realize that several of those components
+were amalgamated after the fact and had different original authors.
+systemd is quite the large tent project right now.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 02 Dec 2013 19:27:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 02 Dec 2013 19:27:07 GMT) (full text, mbox, link).

+ +

Message #748 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org, Tollef Fog Heen <tfheen@err.no>
+
Subject: Re: Bug#727708: systemd and support for other distros
+
Date: Mon, 02 Dec 2013 11:24:41 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> Note that the original complaint in the samba upstream discussion was
+> about hard-coding of paths to system utilities, which a) is not portable
+> between distributions and b) contradicts Debian policy.
+
+> So systemd upstream may support separate /usr, but that doesn't change
+> the fact that there are still portability issues when one starts writing
+> systemd units.
+
+They're fairly trivial ones, though, no?  Maintaining a local patch to
+change the paths in a systemd unit is certainly way less effort than
+maintaining the whole unit.  It's akin to changing the #! paths in
+installed scripts, which we do all the time.
+
+(I should say, for full disclosure, that I have never been a fan of the
+implications of our "always use PATH" policy for init scripts anyway.  I
+feel like init scripts or the equivalent should always start the same
+binary, regardless of what other things the system administrator has
+installed elsewhere on the system, unless explicitly changed by the
+administrator.  Having them honor PATH is too likely to lead to really
+strange and difficult-to-diagnose problems, since you get different
+behavior when manually running the init script versus when it's started at
+boot.)
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 02 Dec 2013 20:42:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 02 Dec 2013 20:42:15 GMT) (full text, mbox, link).

+ +

Message #753 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs
+
Date: Mon, 02 Dec 2013 13:41:41 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Josselin Mouette <joss@debian.org> writes:
+
+> There are two implied assumptions here: 
+>       * that the same people are developing all components; 
+>       * that develolpers have the same attention to code quality and
+>         security in all components they work on.
+>
+> I don’t think either of them applies to systemd.
+
+Right, this succinctly captures one of my biggest concerns about systemd.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 02 Dec 2013 22:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 02 Dec 2013 22:33:04 GMT) (full text, mbox, link).

+ +

Message #758 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in + Debian.
+
Date: Mon, 2 Dec 2013 16:28:46 -0600
+
+
[Message part 1 (text/plain, inline)]
+
Hi Russ,
+
+On Fri, Nov 01, 2013 at 08:11:38PM -0700, Russ Allbery wrote:
+> Steve Langasek <vorlon@debian.org> writes:
+
+> > For the TC decision, what kind of information are you looking for about
+> > the plans, beyond "the Ubuntu developers expect to need to address this
+> > before upgrading from systemd logind 204 and will hold at 204 until a
+> > correct solution is known"?
+
+> I think the right way to put this is that systemd has significant
+> development resources behind it and is working in fairly close cooperation
+> with both kernel developers and GNOME developers to make available new
+> kernel functionality and to provide implementations of various other
+> interfaces.  Multiple implementations are good, but there's potentially an
+> ongoing stream of development to keep up with, and (putting aside
+> arguments about coupling and appropriate ways to integrate that
+> functionality) I believe there is a general agreement that functionality
+> is desirable and will be used by other software that Debian wants to
+> provide.
+
+> So, one question is whether anyone outside of Canonical is in a position
+> to help with the heavy development (as opposed to the occasional patch).
+> Red Hat is clearly committed to systemd, and there's some convergence
+> towards it among other RPM-based distributions, so long-term resources for
+> systemd don't seem to be in doubt.  Canonical is a smaller company, and
+> does not always have the resources to keep projects for which it is the
+> sole upstream vibrant and growing, even when it seems strongly committed
+> to them (c.f. bzr).
+
+While it's fair to note that Canonical is a smaller company with fewer
+resources than Red Hat, Canonical is certainly not the only company working
+on technologies that don't fit into systemd upstream's model.  On the
+question of cgroup management for instance, while there's broad consensus
+that we want to move to a single-writer model, there is not consensus about
+what that single writer should be; at the last on-line Ubuntu Developer
+Summit, developers from Canonical and Google discussed how to collaborate
+around their respective cgroup technologies (lxc, lcmtfy) to address the
+single-writer requirement for non-systemd systems.
+
+  http://summit.ubuntu.com/uds-1311/meeting/21982/core-1311-cgroup-manager/
+
+We're not talking here about whether Google will contribute to upstart
+upstream, because this is code which is separate from upstart by design. 
+But in the wider ecosystem of projects that exist in parallel to (and are
+incompatible with) systemd, there are other players besides Canonical.
+
+For logind, which is the main point of contention with respect to systemd
+205 being usable on systems that don't use systemd as init, the main blocker
+is, again, around logind's use of init as the cgroup manager.  In that same
+UDS session, a decision was taken to provide cgroup manager API
+compatibility with systemd via the systemd-shim package, which is a small
+Canonical-maintained compatibility layer (not yet in Debian, but that's
+easily addressed).  This will enable use of logind 205 on systems running
+upstart (or, for that matter, sysvinit).
+
+I don't believe we need to worry about sufficient manpower to keep up with
+systemd development.  There are a fair number of people who have resigned
+themselves to systemd because they've been led to believe it's the only
+option.  If Debian standardizes on upstart, some of these developers will be
+interested in collaborating with Debian to provide equivalent functionality
+/ compatible interfaces.  It may not be many developers in absolute terms,
+but the rate of development for an init system should not be high in
+absolute terms either.  The greater Free Software community does not have
+inexhaustible patience for projects that are constantly breaking
+backwards-compatibility; whether Debian adopts systemd or not, we are going
+to care about things like being able to run current systems in
+chroots/containers on older (stable) kernels, and we're going to care about
+being able to cleanly upgrade from one stable release to the next, and a
+revolving door of rapidly changing kernel interface requirements is bad for
+the ecosystem as a whole - and will therefore be self-limiting.
+
+> If Canonical *is* the sole upstream, the upstream future here is troubling
+> to me, particularly given Canonical's current strategic direction towards
+> Unity.  To give a specific example of the sort of thing that I'm worried
+> about, suppose that GNOME Shell wants a new piece of functionality that
+> is, on Red Hat, provided via kernel functionality managed by systemd, but
+> Unity has no need for that functionality.  Is Canonical going to develop
+> an upstart equivalent in support of GNOME Shell, when it is pushing Unity
+> over GNOME Shell?
+
+> Maybe this example is very artificial; I know it's not clear what piece of
+> functionality would be required from the init system and surrounding
+> infrastructure that would be required by GNOME Shell and not Unity.  But I
+> think it's at least conceivable given different priorities around such
+> things as multiseat, and in any case it provides a concrete example of the
+> sort of scenario I'm worried about.
+
+Well, I guess you wouldn't expect me to say "yes" here, or if I did, you
+wouldn't believe me; it's unrealistic for Canonical to commit to
+implementing some arbitrary - and hypothetical - future functionality.
+Canonical is committed to being a good steward for upstart for as long as
+Ubuntu itself uses it, and welcomes its use by other distributions.  But
+this isn't an act of altruism, it's enlightened self-interest.  Canonical
+isn't going to make an indefinite committment to maintain features it
+doesn't have need for itself.
+
+But I think the same can be said of systemd.  If Debian concluded that
+systemd's cgroup manager design was wrong because it embeds it in PID 1,
+and wanted systemd to be compatible with other container solutions like lxc
+and lmctfy, I don't think we would expect Red Hat to make this happen for
+us.
+
+All that said, I think your example /is/ very artificial.  logind is
+unquestionably the best solution for seat management today, and there's no
+reason to implement a competing solution.  Systemd upstream doesn't want to
+support logind on non-systemd systems, but we can reasonably provide the
+necessary compatibility layer so that it just works everywhere, for
+everyone's benefit.  So in practice, I don't foresee a case where divergent
+requirements of Unity vs. GNOME Shell would leave Debian holding the bag.
+
+
+> In other words, it's not so much a specific roadmap as it is a roadmap
+> approach and resource committment.  Debian, by choosing a default init
+> system, is potentially investing a lot of developer effort on supporting
+> that platform for packaged daemons, somewhat akin to an organization
+> choosing a product on which to base a required piece of internal
+> functionality.  I'm therefore asking the same sort of question that I
+> would ask of a vendor whose products we were evaluating for my day job:
+> what guarantees do we have that this product will continue to be developed
+> and supported going forward?
+
+> The situation with free software is a bit different from a vendor, of
+> course, since Debian could always patch or even pick up development of the
+> software ourselves, but I think we'd all agree that Debian ending up
+> committed to a system service family (since that's really what we're
+> talking about here -- not just the init system itself, but also how the
+> equivalents, forks, or refactorings of logind, D-Bus, cgroups, udev, and
+> so forth will be handled) whose pace of development has slowed to the
+> extent that bzr's has would be a very bad outcome.
+
+bzr lost the DVCS war not because Canonical was unwilling to invest in bzr,
+but because git had an early lead in performance and flexibility that made
+it the runaway choice for developers, and by the time bzr was catching up in
+functionality, network effects meant it was too late.  Once it became clear
+that bzr would not deliver on its promise of being a universal DVCS because
+the world had already adopted git as a de facto standard, it was reasonable
+for Canonical to stop investing in bzr development.
+
+So I don't think there's much similarity between what happened with bzr, and
+what would happen with upstart if Debian adopted it.  If Debian adopted
+systemd instead of upstart, /then/ there would be hard questions about the
+future of upstart, in light of a clear consensus that systemd is the
+technically superior option.  But if Debian /does/ adopt upstart, Debian +
+Ubuntu represents a critical mass to keep the project going for the
+foreseeable future.
+
+> At least superficially, that outcome looks more likely to me with upstart
+> than it does with systemd, so I'm looking for some reassurance for why the
+> risk of ending up in that situation is low.
+
+Hopefully I've addressed this concern.  If not, please let me know.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 02 Dec 2013 22:45:22 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 02 Dec 2013 22:45:22 GMT) (full text, mbox, link).

+ +

Message #763 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: Tollef Fog Heen <tfheen@err.no>
+
Subject: Re: Bug#727708: systemd and support for other distros
+
Date: Mon, 2 Dec 2013 16:43:37 -0600
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 02, 2013 at 11:24:41AM -0800, Russ Allbery wrote:
+> Steve Langasek <vorlon@debian.org> writes:
+
+> > Note that the original complaint in the samba upstream discussion was
+> > about hard-coding of paths to system utilities, which a) is not portable
+> > between distributions and b) contradicts Debian policy.
+
+> > So systemd upstream may support separate /usr, but that doesn't change
+> > the fact that there are still portability issues when one starts writing
+> > systemd units.
+
+> They're fairly trivial ones, though, no?  Maintaining a local patch to
+> change the paths in a systemd unit is certainly way less effort than
+> maintaining the whole unit.  It's akin to changing the #! paths in
+> installed scripts, which we do all the time.
+
+In this case, the porting requirements are trivial, yes.  My point is that
+porting is still required, and systemd units aren't "write once, run
+everywhere" the way systemd advocates have claimed.  In my experience, the
+cost of a packaging delta is in *maintaining* the delta over time, not in
+creating it initially, and a one-line delta to something like a systemd unit
+is not measurably less of a maintenance burden than, say, a 20-line delta to
+an init script.
+
+> (I should say, for full disclosure, that I have never been a fan of the
+> implications of our "always use PATH" policy for init scripts anyway.  I
+> feel like init scripts or the equivalent should always start the same
+> binary, regardless of what other things the system administrator has
+> installed elsewhere on the system, unless explicitly changed by the
+> administrator.  Having them honor PATH is too likely to lead to really
+> strange and difficult-to-diagnose problems, since you get different
+> behavior when manually running the init script versus when it's started at
+> boot.)
+
+Sure.  Both systemd and upstart manage to avoid the problem of inconsistent
+behavior due to tainted admin environments, because daemons are always
+started as children of init and not of the admin's login shell.  That being
+the case, hard-coding the path to an executable in your initscript
+equivalent doesn't buy you much added protection, compared with just using
+the system $PATH, and does cause gratuitous incompatibilities in exactly
+those cases that Debian Policy's prohibition on hard-coded paths is meant to
+address.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 02 Dec 2013 22:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 02 Dec 2013 22:51:04 GMT) (full text, mbox, link).

+ +

Message #768 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org, Tollef Fog Heen <tfheen@err.no>
+
Subject: Re: Bug#727708: systemd and support for other distros
+
Date: Mon, 02 Dec 2013 14:48:52 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+> On Mon, Dec 02, 2013 at 11:24:41AM -0800, Russ Allbery wrote:
+
+>> They're fairly trivial ones, though, no?  Maintaining a local patch to
+>> change the paths in a systemd unit is certainly way less effort than
+>> maintaining the whole unit.  It's akin to changing the #! paths in
+>> installed scripts, which we do all the time.
+
+> In this case, the porting requirements are trivial, yes.  My point is
+> that porting is still required, and systemd units aren't "write once,
+> run everywhere" the way systemd advocates have claimed.  In my
+> experience, the cost of a packaging delta is in *maintaining* the delta
+> over time, not in creating it initially, and a one-line delta to
+> something like a systemd unit is not measurably less of a maintenance
+> burden than, say, a 20-line delta to an init script.
+
+Hm.  I guess what I can say there is that this doesn't match my
+experience, mostly because the deltas that I've had to maintain to init
+scripts are much more serious than path changes.  Path changes are pretty
+easy to maintain over time.  Init scripts have historically required more
+serious changes for different helper function libraries, using
+Debian-specific tools like start-stop-daemon, and so forth.  In fact, most
+of my upstreams have long since given up on trying to write a portable
+init script and just have separate ones for each major UNIX variant.
+
+By comparison, path differences are trivial.  As far as I'm concerned,
+that still counts as "write once, run everywhere."
+
+> Sure.  Both systemd and upstart manage to avoid the problem of
+> inconsistent behavior due to tainted admin environments, because daemons
+> are always started as children of init and not of the admin's login
+> shell.  That being the case, hard-coding the path to an executable in
+> your initscript equivalent doesn't buy you much added protection,
+> compared with just using the system $PATH, and does cause gratuitous
+> incompatibilities in exactly those cases that Debian Policy's
+> prohibition on hard-coded paths is meant to address.
+
+I have never seen a gratuitous incompatibility caused by this.  Do you
+have any examples?
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 02 Dec 2013 23:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 02 Dec 2013 23:00:05 GMT) (full text, mbox, link).

+ +

Message #773 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Sune Vuorela <sune@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Mon, 2 Dec 2013 16:56:57 -0600
+
+
[Message part 1 (text/plain, inline)]
+
On Sun, Dec 01, 2013 at 11:11:43PM +0100, Sune Vuorela wrote:
+> On Sunday 01 December 2013 21:50:49 Ian Jackson wrote:
+> > This leads me to a question which I find myself asking, after reading
+> > the systemd debate page:
+
+> > If we were to adopt systemd as pid 1, which sections of the systemd
+> > source code would we probably want to adopt as well ?  Or to put it
+> > another way, which other existing programs would be obsoleted ?
+
+> logind is obsoleting consolekit and libpam-xdg. (Consolekit tracks wether
+> or not a user is sitting on the physical console or logged in.  libpam-xdg
+> ensures that XDG_RUNTIME_DIR is handled according to the spec).  Logind
+> also ensures that a user session actually can be terminated when she logs
+> out.
+
+> Logind is the most important one, and within a year or two all desktop
+> environments that wants to be slightly more advanced than TWM is going to
+> need it.  Even Ubuntu is using logind and is iirc maintained there by
+> Steve Langasek.
+
+It's collectively maintained in Ubuntu; I do help with it, but Martin Pitt
+does most of the routine maintenance for the systemd source package (udev,
+logind).
+
+> Beside that, there are among others:
+> the timezoned is ensuring a common way that applications can get notified
+> when the hosts timezone changes.  KDE does have something for that that
+> would be obsoleted.  I think most other systems requires restart of
+> applications or manual magic in each app.
+
+'timedated'
+
+> hostnamed is for notifying when hostname changes. KDE does have something
+> for that.  I don't know who else.
+
+> There are more parts, but that's where my research has ended so far. 
+
+The other one that GNOME uses, and that should be adopted, is localed.
+
+But these dbus services (logind, timedated, hostnamed, localed) are things
+that we should adopt, /independently/ of whether systemd is used as pid 1.
+
+I don't know that there are any systemd services that we would want to adopt
+IFF we switched to systemd for pid 1.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 02 Dec 2013 23:06:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 02 Dec 2013 23:06:05 GMT) (full text, mbox, link).

+ +

Message #778 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs
+
Date: Tue, 03 Dec 2013 00:03:48 +0100
+
+
Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit : 
+> Josselin Mouette <joss@debian.org> writes:
+> 
+> > There are two implied assumptions here: 
+> >       * that the same people are developing all components; 
+> >       * that develolpers have the same attention to code quality and
+> >         security in all components they work on.
+> >
+> > I don’t think either of them applies to systemd.
+> 
+> Right, this succinctly captures one of my biggest concerns about systemd.
+
+Could you please elaborate on this concern? Is it about the large number
+of developers, or about the fact they treat important pieces of code
+more carefully?
+
+-- 
+ .''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 02 Dec 2013 23:36:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 02 Dec 2013 23:36:09 GMT) (full text, mbox, link).

+ +

Message #783 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs
+
Date: Mon, 2 Dec 2013 15:32:33 -0800
+
+
On Tue, 03 Dec 2013, Josselin Mouette wrote:
+> Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit : 
+> > Josselin Mouette <joss@debian.org> writes:
+> > 
+> > > There are two implied assumptions here: 
+> > >       * that the same people are developing all components; 
+> > >       * that develolpers have the same attention to code quality and
+> > >         security in all components they work on.
+> > >
+> > > I don’t think either of them applies to systemd.
+> > 
+> > Right, this succinctly captures one of my biggest concerns about systemd.
+> 
+> Could you please elaborate on this concern? Is it about the large number
+> of developers, or about the fact they treat important pieces of code
+> more carefully?
+
+Projects which have multiple components, each of which has different
+security/interface surfaces without stable defined interfaces, can lead
+to problems when one set of developers doesn't understand the security
+implications of the parts that they do not work on.
+
+The combination of components into a single monolith is sometimes
+necessary, but it's not clear that it is so in the case of systemd.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+THERE IS NO GRAVITY THE WORLD SUCKS
+ -- Vietnam War Penquin Lighter
+http://gallery.donarmstrong.com/clippings/vietnam_there_is_no_gravity.jpg
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 06:21:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 03 Dec 2013 06:21:05 GMT) (full text, mbox, link).

+ +

Message #788 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs
+
Date: Tue, 03 Dec 2013 08:17:44 +0200
+
+
On Mon, 2013-12-02 at 15:32 -0800, Don Armstrong wrote:
+> On Tue, 03 Dec 2013, Josselin Mouette wrote:
+> > Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit : 
+> > > Josselin Mouette <joss@debian.org> writes:
+> > > 
+> > > > There are two implied assumptions here: 
+> > > >       * that the same people are developing all components; 
+> > > >       * that develolpers have the same attention to code quality and
+> > > >         security in all components they work on.
+> > > >
+> > > > I don’t think either of them applies to systemd.
+> > > 
+> > > Right, this succinctly captures one of my biggest concerns about systemd.
+> > 
+> > Could you please elaborate on this concern? Is it about the large number
+> > of developers, or about the fact they treat important pieces of code
+> > more carefully?
+> 
+> Projects which have multiple components, each of which has different
+> security/interface surfaces without stable defined interfaces, can lead
+> to problems when one set of developers doesn't understand the security
+> implications of the parts that they do not work on.
+> 
+> The combination of components into a single monolith is sometimes
+> necessary, but it's not clear that it is so in the case of systemd.
+
+IMO "single monolith" is bad terminology - to me that sounds something
+like everything in a single process, while the systemd components are
+quite modular.
+
+"Not clear it's necessary" seems like an overly negative attitude. There
+doesn't seem to be much disagreement about the fact that many of the
+systemd components are very useful and would be used even with a
+different init. The above security considerations seem purely
+theoretical, with no sign that they'd be an issue with systemd in
+practice. And IIRC no other actual technical problems resulting from
+developing the components together have been brought up in this thread
+either. So why should it be done any differently, when this way appears
+highly successful?
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 06:42:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 03 Dec 2013 06:42:05 GMT) (full text, mbox, link).

+ +

Message #793 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs
+
Date: Mon, 02 Dec 2013 22:39:09 -0800
+
+
Don Armstrong <don@debian.org> writes:
+
+> Projects which have multiple components, each of which has different
+> security/interface surfaces without stable defined interfaces, can lead
+> to problems when one set of developers doesn't understand the security
+> implications of the parts that they do not work on.
+
+It's unclear to me that this is a correct characterization of systemd.  Do
+the separate components of systemd not have stable, defined interfaces?  I
+know they largely don't have other implementations, but that's not the
+same thing.
+
+> The combination of components into a single monolith is sometimes
+> necessary, but it's not clear that it is so in the case of systemd.
+
+systemd is a large package from a source code perspective, but it's not my
+impression that the result of building that source is a monolith.  Rather,
+it's a variety of separate, interoperating services, which strikes me as a
+good general model.  In fact, that design is what makes it possible to
+consider using upstart and still support GNOME, since it means that logind
+is separable from systemd with some effort.  That strongly implies that
+systemd is not a monolith.
+
+I think the concern on the systemd side is not stemming from unstable
+interfaces but from *evolving* interfaces, which is not the same thing.
+In other words, the current systemd services do not implement all the
+functionality that will be eventually needed, particularly by desktops, so
+those interfaces will grow with time, and may require further D-Bus, udev,
+cgroups, and similar integrations.
+
+Let me put it this way.  I think there are a couple of givens here, some
+of which have been expressed by both the GNOME maintainers and the KDE
+maintainers and which are also reflected by the current state of Ubuntu:
+
+* We use udev as the default device management platform and will continue
+  to do so regardless of the init system we choose.
+
+* Many of the other systemd services, particularly logind but also several
+  of the others, are quite desirable or even necessary for desktop
+  environments, so we will need to adopt those services in Debian
+  regardless of what init system we choose.  Obviously, if we adopt
+  systemd, integrating those services into the distribution is quite
+  straightforward.  If we don't adopt systemd, there are some critical
+  missing integrations (relative to the normal systemd infrastructure)
+  that will have to be replaced.  The cgroups manager appears to be the
+  most significant one at the moment.
+
+If the interfaces for those supplemental components are actually unstable,
+that's going to pose problems all around, but I'm not sure how directly
+relevant to this discussion that is since we're going to have to deal
+with those components *anyway*.  Choosing a different init system than
+systemd is not going to let us ignore logind, since it's going to be a
+required component for a modern desktop.  (Although it would still be good
+to know if this is the case.)
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 06:57:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 03 Dec 2013 06:57:05 GMT) (full text, mbox, link).

+ +

Message #798 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
+
Date: Mon, 02 Dec 2013 22:55:46 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> While it's fair to note that Canonical is a smaller company with fewer
+> resources than Red Hat, Canonical is certainly not the only company
+> working on technologies that don't fit into systemd upstream's model.
+> On the question of cgroup management for instance, while there's broad
+> consensus that we want to move to a single-writer model, there is not
+> consensus about what that single writer should be; at the last on-line
+> Ubuntu Developer Summit, developers from Canonical and Google discussed
+> how to collaborate around their respective cgroup technologies (lxc,
+> lcmtfy) to address the single-writer requirement for non-systemd
+> systems.
+
+>   http://summit.ubuntu.com/uds-1311/meeting/21982/core-1311-cgroup-manager/
+
+> We're not talking here about whether Google will contribute to upstart
+> upstream, because this is code which is separate from upstart by design.
+> But in the wider ecosystem of projects that exist in parallel to (and
+> are incompatible with) systemd, there are other players besides
+> Canonical.
+
+> For logind, which is the main point of contention with respect to
+> systemd 205 being usable on systems that don't use systemd as init, the
+> main blocker is, again, around logind's use of init as the cgroup
+> manager.  In that same UDS session, a decision was taken to provide
+> cgroup manager API compatibility with systemd via the systemd-shim
+> package, which is a small Canonical-maintained compatibility layer (not
+> yet in Debian, but that's easily addressed).  This will enable use of
+> logind 205 on systems running upstart (or, for that matter, sysvinit).
+
+This is useful, thank you.  So you believe that the necessary cgroup
+functionality will be easy to maintain going forward in collaboration with
+a different cgroup manager?  How far away is this functionality from being
+production-ready?  My understanding is that this will need to be tested
+and working for jessie.
+
+> I don't believe we need to worry about sufficient manpower to keep up
+> with systemd development.  There are a fair number of people who have
+> resigned themselves to systemd because they've been led to believe it's
+> the only option.  If Debian standardizes on upstart, some of these
+> developers will be interested in collaborating with Debian to provide
+> equivalent functionality / compatible interfaces.  It may not be many
+> developers in absolute terms, but the rate of development for an init
+> system should not be high in absolute terms either.
+
+Well, I partly agree with this, but I'll point out that upstart is
+currently significantly behind in functionality.  Contrary to some other
+expressed opinions here, I personally do not consider systemd's support
+for such things as private /tmp or other security and isolation features
+to be minor side features or only marginally interesting.  I think these
+sorts of features are where the Linux ecosystem is moving, quite quickly,
+and Debian badly needs those features as soon as we can get them.  It's
+going to take some time to adapt all of our software to use those
+features, so the sooner our init system can provide them and we can get
+started, the better.
+
+I have a similar question about OpenRC: the lack of this sort of
+functionality is, for me, a very serious issue, although one that would be
+mitigated by a clear plan to add it that seems likely to happen.
+
+> Well, I guess you wouldn't expect me to say "yes" here, or if I did, you
+> wouldn't believe me; it's unrealistic for Canonical to commit to
+> implementing some arbitrary - and hypothetical - future functionality.
+> Canonical is committed to being a good steward for upstart for as long
+> as Ubuntu itself uses it, and welcomes its use by other distributions.
+> But this isn't an act of altruism, it's enlightened self-interest.
+> Canonical isn't going to make an indefinite committment to maintain
+> features it doesn't have need for itself.
+
+> But I think the same can be said of systemd.  If Debian concluded that
+> systemd's cgroup manager design was wrong because it embeds it in PID 1,
+> and wanted systemd to be compatible with other container solutions like
+> lxc and lmctfy, I don't think we would expect Red Hat to make this
+> happen for us.
+
+The problem for upstart is that these are not comparable, precisely
+because Canonical plays such a smaller role in the broader ecosystem.  For
+better or worse, integration with Red Hat and Fedora is extremely
+important to most of our upstream projects, and Red Hat provides
+significant development resources itself to many upstream projects.  This
+means that systemd integration is far more likely to happen without
+Debian's assistance than upstart integration.
+
+I think the argument for upstart relies on the assumption that such
+integration is not horribly important or normally won't be a serious
+issue.  In essence, my understanding of how you view a world with upstart
+(and the world that Ubuntu is implementing) is that we will use most of
+the systemd services but not its init engine, replacing that and the
+cgroup manager with upstart, and still participating in the rest of the
+systemd ecosystem.  This sounds quite reasonable provided that it's
+relatively straightforward to do this, which is going to depend heavily on
+how much core functionality is provided by the init component and how much
+is provided by separable services.
+
+> bzr lost the DVCS war not because Canonical was unwilling to invest in
+> bzr, but because git had an early lead in performance and flexibility
+> that made it the runaway choice for developers, and by the time bzr was
+> catching up in functionality, network effects meant it was too late.
+> Once it became clear that bzr would not deliver on its promise of being
+> a universal DVCS because the world had already adopted git as a de facto
+> standard, it was reasonable for Canonical to stop investing in bzr
+> development.
+
+True.  However, I'll point out that a similar argument can be made for
+systemd.
+
+> So I don't think there's much similarity between what happened with bzr,
+> and what would happen with upstart if Debian adopted it.  If Debian
+> adopted systemd instead of upstart, /then/ there would be hard questions
+> about the future of upstart, in light of a clear consensus that systemd
+> is the technically superior option.  But if Debian /does/ adopt upstart,
+> Debian + Ubuntu represents a critical mass to keep the project going for
+> the foreseeable future.
+
+And this is exactly the assumption that worries me.  Debian certainly has
+a lot of great developers, but we're perpetually understaffed to do the
+things we've *already* committed to, and the desktop maintenance teams
+(for which these issues are the most critical) are also some of the most
+under-staffed.  It's not at all clear to me that KDE or GNOME upstream
+will be that heavily influenced, in terms of where they put development
+resources, by which init system Debian chooses.  I love Debian too, but
+it's not clear to me that we swing that much influence with those
+particular projects.
+
+Now, that doesn't matter if Debian can use upstart and still "look like
+systemd" from the perspective of the features that the desktop systems
+care about, such as logind and some of the other services.  And it sounds
+like that's what you're saying can happen.  I'm trying to feel out how
+plausible that outcome is.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 07:21:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 03 Dec 2013 07:21:05 GMT) (full text, mbox, link).

+ +

Message #803 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org, joss@debian.org, tfheen@err.no
+
Subject: systemd code documentation
+
Date: Mon, 02 Dec 2013 23:17:56 -0800
+
+
I should say up-front that I don't consider this to be a decisive issue,
+but since it was raised and I did a bit of investigation, I wanted to
+report my initial conclusions and see if I missed anything or got anything
+wrong.
+
+I did a quick code inspection of the code base for both upstart and
+systemd.  This was quite far from any sort of audit, and was necessarily
+quite limited.  The goal was to get a quick feel for the code "smell" and
+style, and to see how comfortable I would be working on the source base.
+
+First, I'll say that both projects seem like generally well-written C.
+They both use well-defined small functions, there isn't a lot of
+deeply-nested structure, they both have published coding styles and
+clearly adhere to them, and in general both packages strike me as written
+by people who knew what they were doing and have been kept up to date.
+(By comparison, sysvinit looks like old and somewhat crufty UNIX code and
+makes me nervous and uncomfortable, even though it's much simpler.)
+
+That said, on first impression the upstart code struck me as significantly
+superior to the systemd code in terms of orientation for a new developer
+or someone attempting to isolate bugs, primarily due to substantial
+differences in internal documentation.  In systemd, each function seems
+well-designed and isolated and does document some of its assumptions with
+asserts, which is good style, but there are almost no comments.  Functions
+usually don't have leading comments describing when to call them, header
+files don't comment functions, files don't have leading comments to orient
+the reader towards the purpose of the file, and most of the internal
+comments were cryptic to a first-time reader and struck me more as
+marginalia than commentary.
+
+By comparison, upstart was lovely code to read.  It uses Doxygen, which I
+can take or leave, but more importantly it documents the internal
+interfaces and functions and provides much more internal orientation
+(although it could still use leading commentary for each file).
+
+My question here is: am I missing something in systemd?  Did I just look
+at the wrong files, or not look deeply enough, or is there orientation
+documentation somewhere else where I didn't see it?  Is there something
+about this comparison that's unfair?
+
+I'll admit that this is a debated point of style, and some programmers
+think that regular commentary make the code less readable and tend to
+become out-of-date.  I'm in the other camp; I prefer orientation
+commentary on each logical block of code, and probably write code that
+some people would consider excessively commented.  I think code should
+tell a story to someone who is reading it and invite understanding.  (I've
+probably read too much Knuth, although I don't think Knuth's method of
+doing this worked.)
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 08:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 03 Dec 2013 08:03:04 GMT) (full text, mbox, link).

+ +

Message #808 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs
+
Date: Tue, 03 Dec 2013 08:59:36 +0100
+
+
]] Russ Allbery 
+
+> Don Armstrong <don@debian.org> writes:
+> 
+> > Projects which have multiple components, each of which has different
+> > security/interface surfaces without stable defined interfaces, can lead
+> > to problems when one set of developers doesn't understand the security
+> > implications of the parts that they do not work on.
+> 
+> It's unclear to me that this is a correct characterization of systemd.  Do
+> the separate components of systemd not have stable, defined interfaces?  I
+> know they largely don't have other implementations, but that's not the
+> same thing.
+
+http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
+
+has a table with the various interfaces and their status.
+
+[...]
+
+> Let me put it this way.  I think there are a couple of givens here, some
+> of which have been expressed by both the GNOME maintainers and the KDE
+> maintainers and which are also reflected by the current state of Ubuntu:
+> 
+> * We use udev as the default device management platform and will continue
+>   to do so regardless of the init system we choose.
+
+Agreed.
+
+> * Many of the other systemd services, particularly logind but also several
+>   of the others, are quite desirable or even necessary for desktop
+>   environments, so we will need to adopt those services in Debian
+>   regardless of what init system we choose.  Obviously, if we adopt
+>   systemd, integrating those services into the distribution is quite
+>   straightforward.  If we don't adopt systemd, there are some critical
+>   missing integrations (relative to the normal systemd infrastructure)
+>   that will have to be replaced.  The cgroups manager appears to be the
+>   most significant one at the moment.
+>
+> If the interfaces for those supplemental components are actually unstable,
+> that's going to pose problems all around, but I'm not sure how directly
+> relevant to this discussion that is since we're going to have to deal
+> with those components *anyway*.  Choosing a different init system than
+> systemd is not going to let us ignore logind, since it's going to be a
+> required component for a modern desktop.  (Although it would still be good
+> to know if this is the case.)
+
+TTBOMK, the page listed above is accurate, and yes, I think there are
+components we should adopt no matter if we go for systemd or not.
+Things like tmpfiles.d aren't terribly complex, but it adds complexity
+to each and every init script that needs a writable directory in /run to
+handle permissions, ownership and creation, rather than just having a
+single declarative file listing what it needs and the bootup process
+ensuring that exists.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 08:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 03 Dec 2013 08:12:05 GMT) (full text, mbox, link).

+ +

Message #813 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org, joss@debian.org
+
Subject: Re: Bug#727708: systemd code documentation
+
Date: Tue, 03 Dec 2013 09:09:13 +0100
+
+
]] Russ Allbery 
+
+
+> My question here is: am I missing something in systemd?  Did I just look
+> at the wrong files, or not look deeply enough, or is there orientation
+> documentation somewhere else where I didn't see it?  Is there something
+> about this comparison that's unfair?
+
+Did you see the «Documentation for Developers» section on
+http://www.freedesktop.org/wiki/Software/systemd/ ?  It's more of an
+overview/design doc than function documentation, but it might be some of
+what you're looking for.
+
+I've also forwarded your question to Lennart on IRC, he might have even
+more pointers.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 08:33:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 03 Dec 2013 08:33:08 GMT) (full text, mbox, link).

+ +

Message #818 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Tollef Fog Heen <tfheen@err.no>
+
Cc: 727708@bugs.debian.org, joss@debian.org
+
Subject: Re: Bug#727708: systemd code documentation
+
Date: Tue, 03 Dec 2013 00:28:52 -0800
+
+
Tollef Fog Heen <tfheen@err.no> writes:
+
+> Did you see the «Documentation for Developers» section on
+> http://www.freedesktop.org/wiki/Software/systemd/ ?  It's more of an
+> overview/design doc than function documentation, but it might be some of
+> what you're looking for.
+
+> I've also forwarded your question to Lennart on IRC, he might have even
+> more pointers.
+
+This documentation is really, really nice, but it's a bit different than
+what I was talking about.  I should be clear, though (and please also do
+mention this to Lennart): the user-facing and the integration
+documentation for systemd seems quite good.  This is more the code-level,
+helping the programmer sort of documentation, which is a bit lower-level.
+
+Both upstart and systemd seem to have excellent manuals and high-level
+design and interface documentation.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 13:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to skirpichev@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 03 Dec 2013 13:18:04 GMT) (full text, mbox, link).

+ +

Message #823 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sergey B Kirpichev <skirpichev@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Tue, 3 Dec 2013 17:14:54 +0400
+
+
On Sun, Dec 01, 2013 at 09:50:49PM +0000, Ian Jackson wrote:
+> If we were to adopt systemd as pid 1, which sections of the systemd
+> source code would we probably want to adopt as well ?  Or to put it
+> another way, which other existing programs would be obsoleted ?
+
+Again, very good question.  And answer to this on the debate page is
+very worrying, assuming that security concerns were unresolved yet.
+(e.g.: CVE-2012-1101 or CVE-2013-4393 examples in
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#583)
+
+Personally, as maintainer of the monit package I have objections
+against statement:
+> Systemd’s service monitoring replaces most uses of daemontools,
+> runit, monit, and maybe other similar packages.
+This may be correct for daemontools/runit, but not for monit or any
+other application-level utility ("if failed port 80 protocol http and
+request ... then restart") for proactive monitoring (for example,
+zabbix has similar functional).
+
+But systemd can cause conflicts (this depends on the adopted
+systemd's default configuration) and so, can create hard-to-debug problems here.
+
+Another questionable statement:
+> Most of these bugs have been found by the Red Hat Product security
+> team conducting an audit of the code as part of its inclusion in
+> their enterprise distribution. Therefore, systemd's security record
+> cannot reasonably be compared with implementations that didn’t
+> undergo similar audits.
+
+Both upstart and sysvinit were part of RHEL.  Please explain
+the difference.
+
+PS:
+And just a side note.  It's only my own impression,
+that there is too many hate/love around systemd?
+Personally, during conversation with the systemd's
+wiki page maintainer, I was impressed how many prejudments
+he can made and how fast (already after the first letter).
+This public disscussion is not an exception:
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#628
+
+Why nginx author doesn't have any needs to explain why his
+software is superior to apache/lighttpd/etc in vast range
+of usecases and so on?  And this is not unusual for other
+projects.  Why?
+
+If this situation is so specific for systemd, we
+should count this as an argument against.  Is there
+any similar example from the debian history?
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 15:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Eugene Zhukov <jevgeni.zh@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 03 Dec 2013 15:15:05 GMT) (full text, mbox, link).

+ +

Message #828 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Eugene Zhukov <jevgeni.zh@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd code documentation
+
Date: Tue, 3 Dec 2013 17:12:52 +0200
+
+
Russ Allbery <rra@debian.org> writes:
+
+> This documentation is really, really nice, but it's a bit different than
+> what I was talking about.  I should be clear, though (and please also do
+> mention this to Lennart): the user-facing and the integration
+> documentation for systemd seems quite good. This is more the code-level,
+> helping the programmer sort of documentation, which is a bit lower-level.
+
+The frequency of comments sometimes reflects poor quality of code.
+When you feel compelled to add a comment, consider rewriting the code
+to make it clearer.
+
+Just my two cents,
+Eugene
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 15:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 03 Dec 2013 15:36:05 GMT) (full text, mbox, link).

+ +

Message #833 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd code documentation
+
Date: Tue, 3 Dec 2013 15:33:01 +0000
+
+
Eugene Zhukov writes ("Bug#727708: systemd code documentation"):
+> The frequency of comments sometimes reflects poor quality of code.
+> When you feel compelled to add a comment, consider rewriting the code
+> to make it clearer.
+
+Please can we avoid arguing about this particular bikeshed here.
+
+Thanks are due to Russ for his research.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 17:51:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 03 Dec 2013 17:51:09 GMT) (full text, mbox, link).

+ +

Message #838 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Eugene Zhukov <jevgeni.zh@gmail.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd code documentation
+
Date: Tue, 03 Dec 2013 09:46:50 -0800
+
+
Eugene Zhukov <jevgeni.zh@gmail.com> writes:
+
+> The frequency of comments sometimes reflects poor quality of code.  When
+> you feel compelled to add a comment, consider rewriting the code to make
+> it clearer.
+
+That would indeed be a succinct statement of the other perspective on code
+comments, which as mentioned in my original message is a perspective that
+I understand but disagree with.  :)
+
+The fact that this is disputed and to some degree a matter of style is a
+large part of why I mentioned that I don't consider this difference
+decisive.
+
+That said, I really do recommend upstart as an example of a nicely-written
+and readable code base, although that's partly because much of it is
+written the way I would have written that code.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 18:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 03 Dec 2013 18:45:04 GMT) (full text, mbox, link).

+ +

Message #843 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: upstart (security) bugs
+
Date: Tue, 03 Dec 2013 19:42:39 +0100
+
+
Hi,
+
+a friend of mine mentioned (not in a pub, but in a serious discussion
+about systemd & upstart) that he looked into upstart bugs more closely,
+and found an alarming trend of security bugs that were not flagged as
+such. 
+
+I do not share his accusations of bad faith; after all, Ubuntu being
+both upstream and downstream for this piece of software, it is
+understandable that some developers focus on fixing bugs quickly rather
+than asking for CVE numbers. However, I find this habit of not
+registering CVEs worrying for two reasons.
+
+     1. It is the sign of insufficient security awareness from some
+        developers. Even if Debian were to adopt upstart and make these
+        habits change, it is plausible that some developers would not
+        take appropriate measures, should new bugs be found. 
+     2. If we are to consider past security issues (which again, is
+        normal in any software package, even well designed) as a metric
+        for the current security status of available init systems, I am
+        afraid we are lacking data on upstart.
+
+I don’t know whether Jef’s list is complete. It would be nice if someone
+had the time to dig into old upstart bugs to see which ones would have
+mandated a security label.
+
+
+        -------- Message transféré --------
+        De: Jef Spaleta <jspaleta@gmail.com>
+        À: Josselin Mouette <joss@debian.org>
+        Sujet: Re: FYI: for the systemd security debate.
+        Date: Mon, 2 Dec 2013 23:39:59 -0900
+        
+        Evening,
+        
+        So looking deeper into the upstart bug tracker..... I just don't think
+        people have bothered filing CVE requests against upstart at
+        all..ever...for anything..even though there have clearly been some
+        SERIOUS system security impacting bugs that have reached users in
+        Ubuntu releases.
+        
+        here's an example of a file descriptor leak in upstart, with exploit
+        code which could cause a service level DoS be chewing up all available
+        file descriptors. Canonical did an internal review...didn't request a
+        cve or external impact accessment..and decided it was a normal bug
+        fix.
+        https://bugs.launchpad.net/upstart/+bug/83099
+        The severity of this is basically the same level of the journald
+        related CVE-2013-4393
+        
+        here is an example of a simple programming mistake that lead to a user
+        space upstart job causing the pid 1 process to fall over and die.
+        Fixed in an update... no CVE requested.
+        https://bugs.launchpad.net/upstart/+bug/807293
+        This is pretty severe. unprivledge user job taking down pid 1 entirely.
+        
+        Here's an example of a FULL ROOT ACCESS exploit from console.  Fixed
+        release in Ubuntu with an update... no CVE.
+        https://bugs.launchpad.net/upstart/+bug/63852
+        
+        So here's the big problem with looking at CVEs.  Single distribution
+        solutions... like upstart...are much much less likely to use the CVE
+        system at all to register security issues.
+        
+        You deep dive into upstart's bug tracker on launchpad, and your going
+        to keep finding more and more examples of classic security impact
+        bugs..just noone is actually labelling them as security impacters. The
+        worrisome thing here is that Canonical and the Ubuntu release
+        management have NOT felt the need to classify the problems as security
+        impactors. If  had a dog in the debian fight, I'd be very very tempted
+        to call the lack of CVEs on these past security issues bad faith...as
+        if Canonical was trying to purposely avoid calling attention to the
+        severity of these problems.  But I do love bug 63852...its a very
+        elegant backdoor on the console.
+        
+        
+        -jef
+
+
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 19:15:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 03 Dec 2013 19:15:08 GMT) (full text, mbox, link).

+ +

Message #848 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Josselin Mouette <joss@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart (security) bugs
+
Date: Tue, 3 Dec 2013 19:11:45 +0000
+
+
Josselin Mouette writes ("Bug#727708: upstart (security) bugs"):
+> I do not share his accusations of bad faith; [...]
+
+It is not appropriate to post these accusations of bad faith to Debian
+forums, even if you are quoting an email from someone else, and
+whether you add a rider of this kind or not.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 19:51:20 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 03 Dec 2013 19:51:20 GMT) (full text, mbox, link).

+ +

Message #853 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart (security) bugs
+
Date: Tue, 03 Dec 2013 12:50:11 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Josselin Mouette <joss@debian.org> writes:
+
+> a friend of mine mentioned (not in a pub, but in a serious discussion
+> about systemd & upstart) that he looked into upstart bugs more closely
+
+Thanks to Jef for this work, the results and his comparison of some bugs
+to systemd CVEs is quite interesting.
+
+> However, I find this habit of not registering CVEs worrying...
+
+Your point is taken.  I think no matter what decision we make here,
+there will always be some bugs that fall on either side of the "to CVE
+or not to CVE" line that we could choose to quibble about in hindsight.
+
+> It would be nice if someone had the time to dig into old upstart bugs
+> to see which ones would have mandated a security label.
+
+Perhaps.  I think the point has been made, however, so spending more
+time on this might not really add anything new to the discussion.  What
+we really care about is the current quality of the code and the
+probability of issues in the future, after all, not so much what's in
+the past.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 20:03:05 GMT) (full text, mbox, link).

+ +

Message #856 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: debian-ctte@lists.debian.org
+
Subject: Re: Bug#727708: systemd (security) bugs
+
Date: Tue, 3 Dec 2013 11:16:17 -0800
+
+
On Tue, 03 Dec 2013, Tollef Fog Heen wrote:
+> ]] Russ Allbery 
+> > Don Armstrong <don@debian.org> writes:
+> > 
+> > > Projects which have multiple components, each of which has
+> > > different security/interface surfaces without stable defined
+> > > interfaces, can lead to problems when one set of developers
+> > > doesn't understand the security implications of the parts that
+> > > they do not work on.
+> > 
+> > It's unclear to me that this is a correct characterization of
+> > systemd. Do the separate components of systemd not have stable,
+> > defined interfaces? I know they largely don't have other
+> > implementations, but that's not the same thing.
+> 
+> http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
+> 
+> has a table with the various interfaces and their status.
+
+This was useful; thanks for linking to this.
+
+[...]
+
+> > If the interfaces for those supplemental components are actually
+> > unstable, that's going to pose problems all around, but I'm not sure
+> > how directly relevant to this discussion that is since we're going
+> > to have to deal with those components *anyway*.
+
+Right; I think we definitely should integrate many of the components
+that are being developed. I'm just concerned that the
+component<->systemd interface is still changing, and because the
+codebase is integrated, there's less of a requirement to communicate and
+document what that interface is than there would be if they were
+distinct projects.
+
+This concern isn't very strong, but it was piqued when udev development
+was brought into systemd; I'm still not certain why that was necessary.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+It is easier to build strong children than to repair broken men.
+ -- Frederick Douglass
+
+
+-- 
+To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
+with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
+Archive: http://lists.debian.org/20131203191617.GR4756@rzlab.ucr.edu
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 03 Dec 2013 21:09:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Moritz Muehlenhoff <jmm@inutil.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 03 Dec 2013 21:09:07 GMT) (full text, mbox, link).

+ +

Message #861 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Moritz Muehlenhoff <jmm@inutil.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: Michael Stapelberg <stapelberg@debian.org>, 727708@bugs.debian.org, + Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: systemd (security) bugs (was: init system question)
+
Date: Tue, 3 Dec 2013 22:00:29 +0100
+
+
On Sun, Dec 01, 2013 at 12:11:11PM -0600, Steve Langasek wrote:
+> > More review and more usage will lead to more bugs being found, we should
+> > rather applaud Red Hat for investing resources and be diligent. After all
+> > Red Hat is the only distro staffing a proactive product security team
+> > (from which everyone is profiting outside of RH as well). I don't consider
+> > the lack of reported security issues for the contenders as a credible 
+> > indication of them being more secure.
+> 
+> Red Hat shipped upstart as their init system in RHEL 6.  This did not result
+> in any CVEs being issued for upstart.  What conclusions should we draw from
+> this?
+
+None. The RH Product Security Team didn't exist back then (founded 1.5 years ago).
+
+Cheers,
+        Moritz
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 04 Dec 2013 00:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 04 Dec 2013 00:57:04 GMT) (full text, mbox, link).

+ +

Message #866 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart (security) bugs
+
Date: Tue, 3 Dec 2013 18:54:51 -0600
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Dec 03, 2013 at 07:42:39PM +0100, Josselin Mouette wrote:
+
+>         -------- Message transféré --------
+>         De: Jef Spaleta <jspaleta@gmail.com>
+>         À: Josselin Mouette <joss@debian.org>
+>         Sujet: Re: FYI: for the systemd security debate.
+>         Date: Mon, 2 Dec 2013 23:39:59 -0900
+>         
+>         Evening,
+>         
+>         So looking deeper into the upstart bug tracker..... I just don't think
+>         people have bothered filing CVE requests against upstart at
+>         all..ever...for anything..even though there have clearly been some
+>         SERIOUS system security impacting bugs that have reached users in
+>         Ubuntu releases.
+
+>         here's an example of a file descriptor leak in upstart, with
+>         exploit code which could cause a service level DoS be chewing up
+>         all available file descriptors.  Canonical did an internal
+>         review...didn't request a cve or external impact accessment..and
+>         decided it was a normal bug fix.
+>         https://bugs.launchpad.net/upstart/+bug/83099
+>         The severity of this is basically the same level of the journald
+>         related CVE-2013-4393
+
+It does appear to me that this bug should have been treated as a security
+bug, but for some reason the developers who did the analysis at the time
+felt that "the potential impact on [the affected Ubuntu release] is
+negligible".  I don't know why, but all other things being equal, I would
+assume that they're right that it wasn't exploitable in the release in
+question and therefore didn't warrant a CVE.
+
+This bug is also six years old.  I don't think it makes sense to judge any
+project by how bugs were being handled 6 years ago.
+
+>         here is an example of a simple programming mistake that lead to a
+>         user space upstart job causing the pid 1 process to fall over and
+>         die.  Fixed in an update...  no CVE requested.
+>         https://bugs.launchpad.net/upstart/+bug/807293
+>         This is pretty severe. unprivledge user job taking down pid 1
+>         entirely.
+
+It is a severe error, but it was only exploitable in a configuration that no
+one ever shipped.  RHEL6 shipped with upstart 0.6.5, which predated the
+changes upstream to allow user sessions (first introduced in release 0.9.0).
+SuSE shipped upstart 0.3.9.  Ubuntu shipped 0.9.7, which did have the bug,
+but with a dbus configuration that prohibited non-root access to the
+problematic calls.  As there were no known downstreams affected by this
+issue in practice, we did not consider this to warrant a CVE.
+
+>         Here's an example of a FULL ROOT ACCESS exploit from console. 
+>         Fixed release in Ubuntu with an update...  no CVE. 
+>         https://bugs.launchpad.net/upstart/+bug/63852
+
+This bug only affected a pre-release version of Ubuntu... seven years ago. 
+The bug is marked as being present only in the Ubuntu-specific packaging. 
+We are generally not in the habit of requesting CVEs for prerelease-only
+issues.
+
+> I do not share his accusations of bad faith; after all, Ubuntu being
+> both upstream and downstream for this piece of software, it is
+> understandable that some developers focus on fixing bugs quickly rather
+> than asking for CVE numbers. However, I find this habit of not
+> registering CVEs worrying for two reasons.
+
+>      1. It is the sign of insufficient security awareness from some
+>         developers. Even if Debian were to adopt upstart and make these
+>         habits change, it is plausible that some developers would not
+>         take appropriate measures, should new bugs be found. 
+>      2. If we are to consider past security issues (which again, is
+>         normal in any software package, even well designed) as a metric
+>         for the current security status of available init systems, I am
+>         afraid we are lacking data on upstart.
+
+A careful analysis of the presented bugs does not support this conclusion.
+If a security-relevant bug had turned up in upstart that affected a release
+that was being used downstream, we would certainly take that seriously and
+follow all the relevant procedures (CVE request, cross-vendor notification,
+etc.)  In practice, TTBOMK this has never been the case.
+
+Certainly, any bug that had warranted a security update in an Ubuntu stable
+release would have received a CVE assignment.  There haven't been any of
+those.
+
+> I don’t know whether Jef’s list is complete. It would be nice if someone
+> had the time to dig into old upstart bugs to see which ones would have
+> mandated a security label.
+
+I think that would be a great waste of the tech committee's time and
+attention.  When you start digging for security issues in prerelease code
+that doesn't /warrant/ a CVE, this is no longer an apples-to-apples
+comparison.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 04 Dec 2013 09:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Marko Randjelovic <markoran@eunet.rs>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 04 Dec 2013 09:33:04 GMT) (full text, mbox, link).

+ +

Message #871 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Marko Randjelovic <markoran@eunet.rs>
+
To: 727708@bugs.debian.org
+
Subject: Abstract Init Scripts
+
Date: Wed, 4 Dec 2013 10:28:06 +0100
+
+
[Message part 1 (text/plain, inline)]
+
I made an example script that could serve as a starting point for
+controlling all services. User/Admin can override functions from this
+script to make custom behavior and configure it in a config file.
+
+It probably doesn't work, but for now it's enough to read it because
+it's self-explaining and illustrate the thesis that features that are
+missing from sysvinit/initscripts can be implemented in a relatively
+simple way.
+
[example.conf (application/octet-stream, attachment)]
+
[service (application/octet-stream, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 07 Dec 2013 08:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 07 Dec 2013 08:18:05 GMT) (full text, mbox, link).

+ +

Message #876 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: [Lennart Poettering] Re: [Russ Allbery] systemd code documentation
+
Date: Sat, 07 Dec 2013 09:15:35 +0100
+
+
[Message part 1 (text/plain, inline)]
+
+I forwarded your question about code documentation to Lennart, and the
+attached mail is his answer.
+
+
+
[Message part 2 (message/rfc822, inline)]
+
+
+ +
From: Lennart Poettering <lennart@poettering.net>
+
To: Tollef Fog Heen <tfheen@err.no>
+
Subject: Re: [Russ Allbery] systemd code documentation
+
Date: Fri, 6 Dec 2013 15:35:21 +0100
+
+
On Thu, 05.12.13 22:19, Tollef Fog Heen (tfheen@err.no) wrote:
+
+> 
+> Hiya,
+> 
+> I poked you on IRC about this, but I suspect it disappeared in the
+> noise.  Any chance you could point Russ at any other resources that he
+> should use?  You can read the entire bug log at
+> http://bugs.debian.org/727708 ; Russ's message is
+> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#803 .
+> 
+> (Feel free to respond to the bug at 727708@bugs.debian.org too, of
+> course.)
+
+Our general approach there is that comments shouldn't drown code. Hence:
+comments for everything that cannot be obviously read from the sources,
+but not comments for everything we ever write. For example, if you have
+a function that is called let's say "unit_load()" then this is already
+indicative enough of what the thing does (loads a unit), that we
+explicitly do not put a comment there.
+
+Note that our public APIs are documented in man pages, and those are not
+placed in the code. You could probably make our statistics look better
+in the eyes of the the-more-comments-the-better fraction if we'd not
+build those man pages from docbook but rather from inline source code
+comments. (I'd even be willing to do that, but I know of no tool that
+would allow embedding docbook man XML in C files)
+
+Anyway, no doubt Upstart has more comments. And no doubt we probably
+could add mor to our sources. But ultimately this doesn't affect our
+contributor base too much as it turns out, since we have so many more
+contributors to our code than Upstart got... ;-)
+
+Also, I am pretty sure that Knuth' commenting style is rather extreme
+(and didn't drown one of Debian's own projects, ifupdown so that nobody
+wanted to hack on it anymore?) I am pretty sure Knuth commenting makes
+sense for writing books and for inner core algorithms, but our code is
+not like that. The identifiers we use should mostly be sufficient to
+indicate things.
+
+Ultimately it's a matter of taste I figure...
+
+Lennart
+
+-- 
+Lennart Poettering, Red Hat
+
+
+
+
[Message part 3 (text/plain, inline)]
+
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 12 Dec 2013 23:30:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve McIntyre <steve@einval.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 12 Dec 2013 23:30:08 GMT) (full text, mbox, link).

+ +

Message #881 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve McIntyre <steve@einval.com>
+
To: 727708@bugs.debian.org
+
Subject: Aribtrarily breaking working interfaces?
+
Date: Thu, 12 Dec 2013 23:26:29 +0000
+
+
Hi, committee members!
+
+I've been following #725714 with interest in the last few days. It
+seems that the arbitrary breakage of the module/firmware loading
+interface in udev last year [1] is now causing major issues for us and
+our users in debian-installer.
+
+I'm very concerned that exactly this kind of long-term breakage is
+likely to be a future problem with systemd...
+
+[1] http://lwn.net/Articles/518942/
+-- 
+Steve McIntyre, Cambridge, UK.                                steve@einval.com
+"Every time you use Tcl, God kills a kitten." -- Malcolm Ray
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 13 Dec 2013 07:24:21 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Stapelberg <stapelberg@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 13 Dec 2013 07:24:21 GMT) (full text, mbox, link).

+ +

Message #886 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Stapelberg <stapelberg@debian.org>
+
To: Steve McIntyre <steve@einval.com>, <727708@bugs.debian.org>
+
Subject: Re: Aribtrarily breaking working interfaces?
+
Date: Fri, 13 Dec 2013 08:23:55 +0100
+
+
Hi Steve,
+
+Steve McIntyre <steve@einval.com> writes:
+> I've been following #725714 with interest in the last few days. It
+> seems that the arbitrary breakage of the module/firmware loading
+> interface in udev last year [1] is now causing major issues for us and
+> our users in debian-installer.
+I take offense with the fact that you write “arbitrary breakage”.
+
+It implies that Kay et al. (udev upstream) _arbitrarily_ decided (as
+opposed to “with good reason, after careful consideration”) to break
+that interface.
+
+I do not have the impression that this is the case. And I certainly do
+not see any evidence supporting that.
+
+So please, can we assume good faith when talking about other human
+beings that are involved in our community?
+
+-- 
+Best regards,
+Michael
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 13 Dec 2013 11:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 13 Dec 2013 11:30:04 GMT) (full text, mbox, link).

+ +

Message #891 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve McIntyre <steve@einval.com>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Aribtrarily breaking working interfaces?
+
Date: Fri, 13 Dec 2013 11:27:01 +0000
+
+
Steve McIntyre writes ("Bug#727708: Aribtrarily breaking working interfaces?"):
+> [1] http://lwn.net/Articles/518942/
+
+Blimey.  I hadn't been aware of that.  Have there been more of these
+disputes between the kernel and udev maintainers ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 13 Dec 2013 18:54:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 13 Dec 2013 18:54:17 GMT) (full text, mbox, link).

+ +

Message #896 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Steve McIntyre <steve@einval.com>
+
Subject: Re: Bug#727708: Aribtrarily breaking working interfaces?
+
Date: Fri, 13 Dec 2013 10:52:40 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Steve McIntyre writes:
+
+>> [1] http://lwn.net/Articles/518942/
+
+> Blimey.  I hadn't been aware of that.  Have there been more of these
+> disputes between the kernel and udev maintainers ?
+
+I think it's worth noting that the very first comment on that news article
+is a note that the issue was already fixed in udev, independent of the
+move of firmware loading to the kernel, with a link to a perfectly
+reasonable-looking fix in Git.
+
+LWN, like most journalists, have a vested interest in making stories
+sensational.  I'm not a fan of the way Linux development discussion is
+handled (most issues turn into these ranting contests), but by and large
+they do converge on some reasonable solution rather quickly.
+
+This whole thing looks like a tempest in a teapot to me.  Linux kernel
+development is very good at creating those; the project is rather
+pathological that way.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 14 Dec 2013 12:33:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 14 Dec 2013 12:33:14 GMT) (full text, mbox, link).

+ +

Message #901 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: upstart user jobs
+
Date: Sat, 14 Dec 2013 12:31:57 +0000
+
+
I have some questions about these.  Forgive me if I could just have
+looked up the answers:
+
+Are they enabled by default in jessie/sid ?
+(If the answer is "no" then feel free not to answer the rest...)
+
+In the manpage I read:
+  | Note that a user job configuration file cannot have the same name
+  | as a system job configuration file.
+I don't understand this restriction.  It's sounds like it's referring
+to the pathnames in which case it's trivially true, so I assume it's
+referring to job names.  In which case surely this is a troublesome
+restriction: what, for example, if a user, knowing that the sysadmin
+is going to install something that creates job "foo", creates a job
+"foo" themselves first ?  Can two different users create two jobs with
+the same name ?  The underlying purpose of the restriction would seem
+to probably be to make job names unqualified by username but unique
+across users, but that seems wrong to me.
+
+Does anything that user jobs do depend on upstart being pid 1, or
+being root ?  Does the thing which reads (and watches) the user's
+configuration files run as root, or as the user ?  I.e., what is the
+privilege separation ?
+
+The docs say:
+ | Files in this directory will be read and an inotify(7) watch
+ | created the first time a user runs initctl(8).
+Does this really mean that if I'm fiddling around with writing some
+jobs, but not quite ready yet, and say "initctl --help", my jobs will
+start to run ?  Also, it would appear to imply that user jobs aren't
+started automatically at boot.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 14 Dec 2013 13:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 14 Dec 2013 13:39:05 GMT) (full text, mbox, link).

+ +

Message #906 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: upstart proposed policy in Debian
+
Date: Sat, 14 Dec 2013 13:36:59 +0000
+
+
Having read the docs there I have some apparently unanswered questions
+about how the upstart proponents think we would use upstart in Debian.
+
+How will we cope with removed-but-not-purged services ?
+
+Do we advise people in favour of socket activation ?
+
+Do we deprecate "expect fork" and "expect daemon" ?  (I would favour
+this - the approach there is pretty horrible.)
+
+Perhaps there is some ubuntu docs on this.  I confess I didn't try
+very hard to find it, hoping we might have a suitable Ubuntu upstart
+expert on hand :-).
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 14 Dec 2013 20:30:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 14 Dec 2013 20:30:05 GMT) (full text, mbox, link).

+ +

Message #911 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: upstart proposed policy in Debian
+
Date: Sat, 14 Dec 2013 20:28:25 +0000
+
+
Ian Jackson writes ("upstart proposed policy in Debian"):
+> Having read the docs there I have some apparently unanswered questions
+> about how the upstart proponents think we would use upstart in Debian.
+
+I found policy 9.11.1 which I had unaccountably failed to notice
+before.  It answer the question of how to do the transition from
+sysvinit to upstart, with a hideous shell rune.  Perhaps the upstart
+package could provide a cooked command and then we could all say
+
+  if init-is-upstart 2>/dev/null; then exit 1; fi
+
+or something.  (IIRC some comments earlier in this thread about some
+corner cases during upgrades; perhaps my suggestionn would help there
+too.)
+
+It didn't answer my other questions.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 14 Dec 2013 21:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 14 Dec 2013 21:48:04 GMT) (full text, mbox, link).

+ +

Message #916 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: systemd socket activation protocol rationale
+
Date: Sat, 14 Dec 2013 21:45:48 +0000
+
+
I've just been reading sd_listen_fds(3).  It's vaguely similar to
+upstart's socket activation protocol.  It supports multiple sockets
+(which is obviously important).
+
+But I have a few questions about the details:
+
+Why do only some of the environment variables start "SD_" ?
+We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START.
+
+What is the rationale behind the use of the LISTEN_PID variable and
+the pid check ?  It seems to me that at the very least this might make
+it hard to wrap up a socket-activated daemon in a shell script.
+
+I think it would be good, regardless of what the TC decides on the
+init system question for Debian, for systemd and upstart to converge
+on a single reasonable protocol.
+
+I observe that upstart's UPSTART_FDS, if extended to multiple sockets,
+would require the daemon to do whitespace-separated parsing to extract
+the (perhaps noncontiguous) fds.  Whereas systemd's two separate
+variables and use of a contiguous fd range is slightly easier to deal
+with.
+
+AFAICT it might be possible for both daemons to implement both
+protocols.  upstart would have to arrange to make sure that if there
+were multiple fds they were consecutive.
+
+Observations and/or opinions from either upstart or systemd welcome.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 14 Dec 2013 22:03:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 14 Dec 2013 22:03:05 GMT) (full text, mbox, link).

+ +

Message #921 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: systemd and upstart (mostly docs) bugs submitted
+
Date: Sat, 14 Dec 2013 21:59:18 +0000
+
+
I've been RTFMing upstart and systemd.  This has generated a number of
+bug reports.  In case these are at of any interest here's a list.  If
+anything particularly interesting happens in them, I'll mention it.
+
+#732127 [n| ]  Does setuid also set the group(s) ? It should.
+#732122 [m| ]  semantics of boolean event specification not defined in init(5)
+#732123 [m| ]  usage of "stanza" not compatible with ordinary English
+#732125 [m| ]  upstart-events(7) title is misleading
+#732126 [m| ]  state machine semantics of "initctl restart" are unclear
+#732128 [m| ]  Manpages missing cross-references to socket stuff
+#732130 [m| ]  Please document event/job/process environment variables properly
+#732131 [m| ]  Please document apparmor directives
+
+#732156 [m| ]  Precise documentation for ExecStart command syntax
+#732157 [w| ]  Want SIGSTOP-style daemon/service readiness notification
+
+I haven't yet finished with systemd's docs but I'm going to be doing
+something else today soon so I'll send this mail now.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 14 Dec 2013 22:03:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 14 Dec 2013 22:03:08 GMT) (full text, mbox, link).

+ +

Message #926 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: systemd and upstart (mostly docs) bugs submitted
+
Date: Sat, 14 Dec 2013 22:01:20 +0000
+
+
Ian Jackson writes ("systemd and upstart (mostly docs) bugs submitted"):
+> I've been RTFMing upstart and systemd.  This has generated a number of
+> bug reports.  In case these are at of any interest here's a list.  If
+> anything particularly interesting happens in them, I'll mention it.
+
+I missed two:
+
+> #732127 [n|] Does setuid also set the group(s) ? It should.
+> #732122 [m|] semantics of boolean event specification not defined in init(5)
+> #732123 [m|] usage of "stanza" not compatible with ordinary English
+> #732125 [m|] upstart-events(7) title is misleading
+> #732126 [m|] state machine semantics of "initctl restart" are unclear
+> #732128 [m|] Manpages missing cross-references to socket stuff
+> #732130 [m|] Please document event/job/process environment variables properly
+> #732131 [m|] Please document apparmor directives
+  #732124 [w|] "initctl reload" behaviour should be configurable in job file
+  #732132 [w|] Want support for multiple-socket activation
+
+> #732156 [m|] Precise documentation for ExecStart command syntax
+> #732157 [w|] Want SIGSTOP-style daemon/service readiness notification
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 14 Dec 2013 22:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 14 Dec 2013 22:39:05 GMT) (full text, mbox, link).

+ +

Message #931 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: systemd socket activation protocol rationale
+
Date: Sun, 15 Dec 2013 00:36:45 +0200
+
+
On Sat, 2013-12-14 at 21:45 +0000, Ian Jackson wrote:
+> I've just been reading sd_listen_fds(3).  It's vaguely similar to
+> upstart's socket activation protocol.  It supports multiple sockets
+> (which is obviously important).
+> 
+> But I have a few questions about the details:
+> 
+> Why do only some of the environment variables start "SD_" ?
+> We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START.
+
+You misread it: there is no environment variable SD_LISTEN_FDS_START.
+The API defines the start value as the constant 3. There is a
+corresponding #define in sd-daemon.h, but it is not communicated at
+runtime.
+
+
+> What is the rationale behind the use of the LISTEN_PID variable and
+> the pid check ?  It seems to me that at the very least this might make
+> it hard to wrap up a socket-activated daemon in a shell script.
+
+To ensure that the environment values are never accidentally inherited
+by any child process.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 14 Dec 2013 22:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Stapelberg <stapelberg@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 14 Dec 2013 22:57:04 GMT) (full text, mbox, link).

+ +

Message #936 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Stapelberg <stapelberg@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, <727708@bugs.debian.org>
+
Cc: "Helmut Grohne" <helmut@subdivi.de>
+
Subject: Re: systemd socket activation protocol rationale
+
Date: Sat, 14 Dec 2013 23:53:42 +0100
+
+
Hi Ian,
+
+[still sending this after Uoti’s reply, because my version has some more
+detail]
+
+Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Why do only some of the environment variables start "SD_" ?
+> We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START.
+SD_LISTEN_FDS_START is a #define from sd-daemon.h, not an environment
+variable.
+
+> What is the rationale behind the use of the LISTEN_PID variable and
+> the pid check ?  It seems to me that at the very least this might make
+“In addition we set $LISTEN_PID to the PID of the daemon that shall
+ receive the fds, because environment variables are normally inherited
+ by sub-processes and hence could confuse processes further down the
+ chain” ¹
+
+> it hard to wrap up a socket-activated daemon in a shell script.
+I am not entirely sure what use cases you have in mind, but typically a
+wrapper script at some point just execs the daemon itself, right? In
+that case, it’s not a problem.
+
+> I think it would be good, regardless of what the TC decides on the
+> init system question for Debian, for systemd and upstart to converge
+> on a single reasonable protocol.
+Helmut Grohne has done some work in that direction², speaking to the
+relevant people at DebConf 13 in person. I am not entirely sure about
+the current status of these efforts, maybe Helmut can comment…?
+
+① http://0pointer.de/blog/projects/systemd.html, feature 8
+② https://lists.debian.org/debian-devel/2013/06/msg00007.html
+
+-- 
+Best regards,
+Michael
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 15 Dec 2013 08:30:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Helmut Grohne <helmut@subdivi.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 15 Dec 2013 08:30:05 GMT) (full text, mbox, link).

+ +

Message #941 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Helmut Grohne <helmut@subdivi.de>
+
To: Michael Stapelberg <stapelberg@debian.org>
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: systemd socket activation protocol rationale
+
Date: Sun, 15 Dec 2013 09:26:21 +0100
+
+
On Sat, Dec 14, 2013 at 11:53:42PM +0100, Michael Stapelberg wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > I think it would be good, regardless of what the TC decides on the
+> > init system question for Debian, for systemd and upstart to converge
+> > on a single reasonable protocol.
+> Helmut Grohne has done some work in that direction², speaking to the
+> relevant people at DebConf 13 in person. I am not entirely sure about
+> the current status of these efforts, maybe Helmut can comment????
+
+See http://bugs.debian.org/732179. (Afaik you cannot create a new bug
+and CC another at the same time. That's why I split the messages.)
+
+Helmut
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 16 Dec 2013 04:21:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 16 Dec 2013 04:21:05 GMT) (full text, mbox, link).

+ +

Message #946 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: systemd socket activation protocol rationale
+
Date: Mon, 16 Dec 2013 05:01:59 +0100
+
+
> hard to wrap up a socket-activated daemon in a shell script
+There's always systemd-activate, if you really need to do it from the shell :)
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 16 Dec 2013 15:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 16 Dec 2013 15:57:04 GMT) (full text, mbox, link).

+ +

Message #951 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Josselin Mouette <joss@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: systemd jessie -> jessie+1 upgrade problems
+
Date: Mon, 16 Dec 2013 17:52:24 +0200
+
+
Hi Josselin,
+
+reading through the systemd position statement [1], I ran into a 
+statement that is either incomplete or incorrect:
+
+
+The upstart position statement [2] states:
+
+<--  snip  -->
+
+systemd is hasty. ... While we are committed to having sane upgrade 
+paths and not depend on such kernel features prematurely.
+
+<-- snip  -->
+
+
+The answer in the systemd position statement says:
+
+<--  snip  -->
+
+... Compatibility at upgrade time should not be a concern either, since 
+the real outside interfaces (D-Bus, unit files, Debian configuration 
+files) have always been stable (forward compatible) and will remain so. 
+There will, most probably, be locked-in upgrades with udev from time to 
+time, but it does not have any impact on the ability to upgrade systems.
+
+<--  snip  -->
+
+
+Can you give a pointer to what guarantees systemd upstream makes 
+regarding supporting older kernels?
+
+
+One example:
+
+Assume kdbus gets merged into the upstream kernel after the kernel that 
+ships with jessie.
+
+Would it be guaranteed that the systemd in jessie+1 will still be able 
+to work with the jessie kernel, or is there even the slightest risk that 
+systemd upstream might at some point make kdbus a mandatory requirement?
+
+
+And with systemd absorbing functionality like module loading I could 
+even imagine nightmare scenarios where additionally the jessie+1 kernel 
+would only work with a jessie+1 systemd.
+
+
+Please clarify whether there is just a pointer to a statement from 
+systemd upstream missing, or whether the statement "Compatibility at 
+upgrade time should not be a concern either" is incorrect.
+
+
+Thanks in advance
+Adrian
+
+[1] https://wiki.debian.org/Debate/initsystem/systemd
+[2] https://wiki.debian.org/Debate/initsystem/upstart
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 17 Dec 2013 11:42:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 17 Dec 2013 11:42:05 GMT) (full text, mbox, link).

+ +

Message #956 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: systemd jessie -> jessie+1 upgrade problems
+
Date: Tue, 17 Dec 2013 12:38:50 +0100
+
+
Hi Adrian,
+
+Le lundi 16 décembre 2013 à 17:52 +0200, Adrian Bunk a écrit : 
+> Can you give a pointer to what guarantees systemd upstream makes 
+> regarding supporting older kernels?
+
+Systemd is a userspace program. As such, it can has the same problems as
+any other userspace programs. A notable similar example is eglibc: some
+features require a newer kernel, and fallback code is needed when the
+kernel is not recent enough.
+
+So it really boils down to the time that passes between the integration
+of a feature to the kernel and its use in systemd. For example, systemd
+has a hard dependency on cgroups, but this feature has been in the
+kernel from some time.
+
+Problematic examples will not be frequent, and you are right to quote
+kdbus as one of them.
+
+> Assume kdbus gets merged into the upstream kernel after the kernel that 
+> ships with jessie.
+> 
+> Would it be guaranteed that the systemd in jessie+1 will still be able 
+> to work with the jessie kernel, or is there even the slightest risk that 
+> systemd upstream might at some point make kdbus a mandatory requirement?
+
+Upstream systemd will probably make kdbus a requirement:
+http://lists.freedesktop.org/archives/systemd-devel/2013-March/009797.html
+
+At this point, if the kernel in jessie does not support kdbus already,
+we have several alternatives I can think of: 
+     1. Maintain a code path to detect whether kdbus is available and
+        fall back to dbus-daemon in this case (better if we can convince
+        upstream to integrate the change) 
+     2. Make a kdbus DKMS package and make it a dependency for systemd 
+     3. Include kdbus in the jessie kernel in a point release 
+     4. As a last resort, entirely disable kdbus in jessie+1
+
+Note that if kdbus is adopted, we will need it regardless in glib2.0 and
+libdbus. If we do not adopt systemd, we will have to make similar plans
+of our own to provide a kdbus-enabled system bus and use it if the
+kernel is recent enough. So this problem will exist, with the same
+categories of solutions, even if we don’t switch to systemd.
+
+> And with systemd absorbing functionality like module loading I could 
+> even imagine nightmare scenarios where additionally the jessie+1 kernel 
+> would only work with a jessie+1 systemd.
+
+This would definitely be considered a bug in the kernel.
+
+> Please clarify whether there is just a pointer to a statement from 
+> systemd upstream missing, or whether the statement "Compatibility at 
+> upgrade time should not be a concern either" is incorrect.
+
+Maybe this was wrongly phrased: of course we should be concerned by
+compatibility at upgrade time. But using systemd doesn’t cause more
+compatibility problems than those we already have (e.g. with udev).
+
+Cheers,
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 17 Dec 2013 13:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 17 Dec 2013 13:30:04 GMT) (full text, mbox, link).

+ +

Message #961 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Josselin Mouette <joss@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: systemd jessie -> jessie+1 upgrade problems
+
Date: Tue, 17 Dec 2013 15:26:19 +0200
+
+
On Tue, Dec 17, 2013 at 12:38:50PM +0100, Josselin Mouette wrote:
+> Hi Adrian,
+
+Hi Josselin,
+
+> Le lundi 16 décembre 2013 à 17:52 +0200, Adrian Bunk a écrit : 
+> > Can you give a pointer to what guarantees systemd upstream makes 
+> > regarding supporting older kernels?
+> 
+> Systemd is a userspace program. As such, it can has the same problems as
+> any other userspace programs. A notable similar example is eglibc: some
+> features require a newer kernel, and fallback code is needed when the
+> kernel is not recent enough.
+> 
+> So it really boils down to the time that passes between the integration
+> of a feature to the kernel and its use in systemd. For example, systemd
+> has a hard dependency on cgroups, but this feature has been in the
+> kernel from some time.
+
+this hits exactly the core of the problem:
+
+The minimum supported Linux kernel version in glibc is currently 2.6.16, 
+released in 2006. And I'd trust glibc upstreamt that this requirement 
+won't suddenly be bumped to a quite recent version.
+
+Is there any explicit commitment from systemd upstream that releases of 
+systemd releases around 2017 will still contain fallback code to work
+on kernels from 2013/2014?
+
+
+> Problematic examples will not be frequent, and you are right to quote
+> kdbus as one of them.
+> 
+> > Assume kdbus gets merged into the upstream kernel after the kernel that 
+> > ships with jessie.
+> > 
+> > Would it be guaranteed that the systemd in jessie+1 will still be able 
+> > to work with the jessie kernel, or is there even the slightest risk that 
+> > systemd upstream might at some point make kdbus a mandatory requirement?
+
+
+First of all, I want to emphasize that kdbus is just an example.
+
+kdbus might even be in the jessie kernel so that this specific problem 
+might not show up.
+
+But other systemd/kernel dependencies might get added at any point.
+
+
+> Upstream systemd will probably make kdbus a requirement:
+> http://lists.freedesktop.org/archives/systemd-devel/2013-March/009797.html
+> 
+> At this point, if the kernel in jessie does not support kdbus already,
+> we have several alternatives I can think of: 
+>      1. Maintain a code path to detect whether kdbus is available and
+>         fall back to dbus-daemon in this case
+
+Is there any explicit commitment from systemd upstream that systemd
+would not get a hard dependency on anything only available in kdbus?
+
+
+>         (better if we can convince
+>         upstream to integrate the change) 
+
+Feel free to prove me wrong, but the very core of this problem is that 
+I'd expect Lennart to give to a question
+  Will 2017 systemd releases support 2013 kernels?
+the answer
+  Of course not!
+
+
+>      2. Make a kdbus DKMS package and make it a dependency for systemd 
+>      3. Include kdbus in the jessie kernel in a point release 
+
+This might be possible in the kdbus example where the kernel code is a 
+standalone module (but 2. or 3. would cause much pain e.g. for correctly 
+handling custom kernels).
+
+If systemd depends on new kernel features/changes that touch kernel 
+internals, these would not be options.
+
+
+>      4. As a last resort, entirely disable kdbus in jessie+1
+
+Is there any explicit commitment from systemd upstream that systemd
+in 2016/2017 will not have a hard dependency on features not in kernels
+available today?
+
+jessie+1 will be released around 2017/2018, and I would not be surprised 
+if systemd will start on 2014 to depend on kdbus with no other option
+possible.
+
+What would you do in such a situation?
+Ship a 2014 systemd in jessie+1?
+Even if GNOME decides to depend on features from more recent systemd 
+releases?
+
+
+> Note that if kdbus is adopted, we will need it regardless in glib2.0 and
+> libdbus.
+
+But without systemd Debian is free to make the decision when and how to 
+adopt kdbus. If you add a systemd version that required kdbus into the 
+mix, the upgrade becomes messy.
+
+glib2.0 and libdbus are not Linux-only, so their upstream will have to 
+provide and support the current non-kdbus codepaths.
+
+That would make it an easily feasible option to solve any
+jessie -> jessie+1 upgrade issues by not enabling kdbus in
+glib2.0 and libdbus for jessie+1 at all, or by enabling both
+kdbus and non-kdbus codepaths and choose one at runtime.
+
+
+> If we do not adopt systemd, we will have to make similar plans
+> of our own to provide a kdbus-enabled system bus and use it if the
+> kernel is recent enough. So this problem will exist, with the same
+> categories of solutions, even if we don’t switch to systemd.
+
+Software like glib2.0 and libdbus that supports non-Linux kernels will 
+anyway have to continue to support non-kdbus systems.
+
+Is there any explicit commitment from systemd upstream that systemd
+in 2016/2017 will not have a hard dependency on features not in kernels
+available today?
+
+
+> > And with systemd absorbing functionality like module loading I could 
+> > even imagine nightmare scenarios where additionally the jessie+1 kernel 
+> > would only work with a jessie+1 systemd.
+> 
+> This would definitely be considered a bug in the kernel.
+
+I don't think problems are likely in this direction, but I wouldn't rule 
+that out completely.
+
+
+> > Please clarify whether there is just a pointer to a statement from 
+> > systemd upstream missing, or whether the statement "Compatibility at 
+> > upgrade time should not be a concern either" is incorrect.
+> 
+> Maybe this was wrongly phrased: of course we should be concerned by
+> compatibility at upgrade time. But using systemd doesn’t cause more
+> compatibility problems than those we already have (e.g. with udev).
+
+The exact opposite it true.
+
+udev used to be the one package causing huge upgrade headaches back in 
+it's early days when the ABI between udev and the kernel was changing.
+
+Later (at least until it was moved into systemd) it was mature and did 
+not cause such problems.
+
+systemd is the former udev problems on steroids.
+
+The potential upgrade problems I am talking about come from the fact 
+that systemd is relatively new software under heavy developement.
+In a few years when systemd will be mature and and not require
+new kernel ABIs these upgrade such problems will likely disappear
+just as they did with udev.
+
+
+> Cheers,
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 17 Dec 2013 18:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 17 Dec 2013 18:33:05 GMT) (full text, mbox, link).

+ +

Message #966 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Tue, 17 Dec 2013 10:29:35 -0800
+
+
Adrian Bunk <bunk@stusta.de> writes:
+
+> this hits exactly the core of the problem:
+
+> The minimum supported Linux kernel version in glibc is currently 2.6.16,
+> released in 2006. And I'd trust glibc upstreamt that this requirement
+> won't suddenly be bumped to a quite recent version.
+
+> Is there any explicit commitment from systemd upstream that releases of 
+> systemd releases around 2017 will still contain fallback code to work
+> on kernels from 2013/2014?
+
+I'd really like to keep this bug and this discussion focused on what's
+relevant to Debian as a project, so let's put this in that perspective.
+The oldest kernel that Debian supports is 2.6.32, released in 2009.  But
+the oldest kernel that we support for upgrades, which is the only point at
+which systemd backward compatibility matters for Debian's support model,
+is 3.2.0, released in 2012.  The window of backward compatibility that we
+need is roughly a release cycle plus six months (due to the releases that
+miss the release window).  That's much less than the seven years of the
+eglibc example.
+
+We explicitly don't need to worry about whether systemd in unstable works
+with the oldstable kernel since we don't support that degree of
+cross-release compatibility.
+
+If we're going to ask systemd upstream questions about this, we should use
+the actual time period that we care about (about two and a half to three
+years), not four years and certainly not seven years.
+
+> But without systemd Debian is free to make the decision when and how to
+> adopt kdbus. If you add a systemd version that required kdbus into the
+> mix, the upgrade becomes messy.
+
+That's only true to the extent that we can hold all other packages back,
+so it's true exactly to the degree that we can choose when and how to
+adopt kdbus if we standardized on systemd.  If we're holding back upstream
+packages, we can hold back systemd as well.  This situation doesn't
+change, which is Josselin's point.
+
+As an additional note:
+
+> Is there any explicit commitment from systemd upstream that systemd in
+> 2016/2017 will not have a hard dependency on features not in kernels
+> available today?
+
+Repeating the same question multiple times in the same mail message is
+extremely irritating.  In the future, when discussing things on the
+technical committee mailing list, please refrain from doing this.  You can
+assume that everyone reading your message understands which questions you
+think are important and doesn't require this sort of artificial emphasis.
+It comes across as badgering.
+
+>> Maybe this was wrongly phrased: of course we should be concerned by
+>> compatibility at upgrade time. But using systemd doesn’t cause more
+>> compatibility problems than those we already have (e.g. with udev).
+
+> The exact opposite it true.
+
+> udev used to be the one package causing huge upgrade headaches back in 
+> it's early days when the ABI between udev and the kernel was changing.
+
+> Later (at least until it was moved into systemd) it was mature and did 
+> not cause such problems.
+
+> systemd is the former udev problems on steroids.
+
+I see no evidence to support this contention apart from a bunch of
+speculation on your part about what *might* happen four years in the
+future if particular features missed a release window.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 17 Dec 2013 19:42:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 17 Dec 2013 19:42:09 GMT) (full text, mbox, link).

+ +

Message #971 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Tue, 17 Dec 2013 21:38:56 +0200
+
+
On Tue, Dec 17, 2013 at 10:29:35AM -0800, Russ Allbery wrote:
+> Adrian Bunk <bunk@stusta.de> writes:
+> 
+> > this hits exactly the core of the problem:
+> 
+> > The minimum supported Linux kernel version in glibc is currently 2.6.16,
+> > released in 2006. And I'd trust glibc upstreamt that this requirement
+> > won't suddenly be bumped to a quite recent version.
+> 
+> > Is there any explicit commitment from systemd upstream that releases of 
+> > systemd releases around 2017 will still contain fallback code to work
+> > on kernels from 2013/2014?
+> 
+> I'd really like to keep this bug and this discussion focused on what's
+> relevant to Debian as a project, so let's put this in that perspective.
+> The oldest kernel that Debian supports is 2.6.32, released in 2009.  But
+> the oldest kernel that we support for upgrades, which is the only point at
+> which systemd backward compatibility matters for Debian's support model,
+> is 3.2.0, released in 2012.
+
+Nitpick:
+3.2.0 was released on January 5th 2012, so nearly 2011
+
+
+> The window of backward compatibility that we
+> need is roughly a release cycle plus six months (due to the releases that
+> miss the release window).  That's much less than the seven years of the
+> eglibc example.
+> 
+> We explicitly don't need to worry about whether systemd in unstable works
+> with the oldstable kernel since we don't support that degree of
+> cross-release compatibility.
+> 
+> If we're going to ask systemd upstream questions about this, we should use
+> the actual time period that we care about (about two and a half to three
+> years), not four years and certainly not seven years.
+
+I never talked about a seven years requirement, I was just listing the 
+glibc status quo when Josselin said "A notable similar example is eglibc".
+
+I agree with you that around 3 years is a reasonable estimate for what 
+would be required from systemd.
+
+
+> > But without systemd Debian is free to make the decision when and how to
+> > adopt kdbus. If you add a systemd version that required kdbus into the
+> > mix, the upgrade becomes messy.
+> 
+> That's only true to the extent that we can hold all other packages back,
+> so it's true exactly to the degree that we can choose when and how to
+> adopt kdbus if we standardized on systemd.  If we're holding back upstream
+> packages, we can hold back systemd as well.  This situation doesn't
+> change, which is Josselin's point.
+
+The "holding back upstream packages" would only be true for Linux-only 
+software that additionally chooses to drop the non-kdbus codepaths.
+
+As I already explained, software like glib2.0 and libdbus that supports 
+non-Linux kernels will anyway have to continue to support non-kdbus 
+systems forever.
+
+Is there actually any implementation other than glib2.0 and libdbus that 
+would be affected by a switch to kdbus?
+
+
+>...
+> >> Maybe this was wrongly phrased: of course we should be concerned by
+> >> compatibility at upgrade time. But using systemd doesn’t cause more
+> >> compatibility problems than those we already have (e.g. with udev).
+> 
+> > The exact opposite it true.
+> 
+> > udev used to be the one package causing huge upgrade headaches back in 
+> > it's early days when the ABI between udev and the kernel was changing.
+> 
+> > Later (at least until it was moved into systemd) it was mature and did 
+> > not cause such problems.
+> 
+> > systemd is the former udev problems on steroids.
+> 
+> I see no evidence to support this contention apart from a bunch of
+> speculation on your part about what *might* happen four years in the
+> future if particular features missed a release window.
+
+As an example, in the email from Josselin I was answering to he linked 
+to an email from Lennart [1] that states:
+
+<--  snip  -->
+
+At the same time we will no longer support dbus-daemon for the system. 
+This will add a hard dependency of systemd on a very new kernel version. 
+However, to make this palatable we will try hard to keep kdbus.ko 
+compilable out-of-tree and easily backportable.
+
+<--  snip  -->
+
+That is an explicit statement by upstream regarding what will happen in 
+the near future.
+
+That makes it e.g. pretty clear that options 1. and 4. Josselin listed
+for a jessie -> jessie+1 upgrade would definitely not be feasible if
+kdbus won't be in the jessie kernel.
+
+
+Yes, it is speculation that other new features (or even bugfixes) 
+might appear in the kernel and might become mandatory in systemd
+between jessie and jessie+1.
+
+But that is a risk, and it is a risk that is unique to the systemd 
+option since none of the alternatives is Linux-only. [2]
+
+My whole point is not about kdbus specifically (which might even end up 
+in the jessie kernel), but about that (IMHO substantial) risk.
+
+Whether or not this risk exists at all should be settled by asking 
+systemd upstream. If the answer is that for the required ~3 years
+period compatibility with older kernels is guaranteed, then please
+disregard my emails.
+
+
+
+> Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+cu
+Adrian
+
+[1] http://lists.freedesktop.org/archives/systemd-devel/2013-March/009797.html
+[2] any alternative that is not Linux-only cannot hard depend on 
+    Linux-only kernel features
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 17 Dec 2013 20:12:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 17 Dec 2013 20:12:04 GMT) (full text, mbox, link).

+ +

Message #976 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Adrian Bunk <bunk@stusta.de>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Tue, 17 Dec 2013 21:09:07 +0100
+
+
On Tue, Dec 17, 2013 at 09:38:56PM +0200, Adrian Bunk wrote:
+> On Tue, Dec 17, 2013 at 10:29:35AM -0800, Russ Allbery wrote:
+> > Adrian Bunk <bunk@stusta.de> writes:
+> > 
+> > > this hits exactly the core of the problem:
+> > 
+> > > The minimum supported Linux kernel version in glibc is currently 2.6.16,
+> > > released in 2006. And I'd trust glibc upstreamt that this requirement
+> > > won't suddenly be bumped to a quite recent version.
+> > 
+> > > Is there any explicit commitment from systemd upstream that releases of 
+> > > systemd releases around 2017 will still contain fallback code to work
+> > > on kernels from 2013/2014?
+> > 
+> > I'd really like to keep this bug and this discussion focused on what's
+> > relevant to Debian as a project, so let's put this in that perspective.
+> > The oldest kernel that Debian supports is 2.6.32, released in 2009.  But
+> > the oldest kernel that we support for upgrades, which is the only point at
+> > which systemd backward compatibility matters for Debian's support model,
+> > is 3.2.0, released in 2012.
+> 
+> Nitpick:
+> 3.2.0 was released on January 5th 2012, so nearly 2011
+
+And that is why it's up to 3 years.
+
+We release about every 2 years, but the kernel we have in wheezy
+was already about 16 months old when wheezy was released.  Jessie
+will freeze in november 2014, so that the kernel will then be about
+3 years old.  I'm going to assume that the release team is not
+going to accept new systemd versions from that point on, so
+systemd should only support a kernel that's 3 years old.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 17 Dec 2013 20:27:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 17 Dec 2013 20:27:09 GMT) (full text, mbox, link).

+ +

Message #981 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Kurt Roeckx <kurt@roeckx.be>
+
Cc: Adrian Bunk <bunk@stusta.de>, 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Tue, 17 Dec 2013 12:25:04 -0800
+
+
Kurt Roeckx <kurt@roeckx.be> writes:
+
+> We release about every 2 years, but the kernel we have in wheezy was
+> already about 16 months old when wheezy was released.  Jessie will
+> freeze in november 2014, so that the kernel will then be about 3 years
+> old.  I'm going to assume that the release team is not going to accept
+> new systemd versions from that point on, so systemd should only support
+> a kernel that's 3 years old.
+
+Right, exactly.
+
+It's a real concern, but we should be clear about what our time horizon of
+concern is.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 17 Dec 2013 20:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 17 Dec 2013 20:30:05 GMT) (full text, mbox, link).

+ +

Message #986 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Tue, 17 Dec 2013 12:26:30 -0800
+
+
Adrian Bunk <bunk@stusta.de> writes:
+
+> The "holding back upstream packages" would only be true for Linux-only
+> software that additionally chooses to drop the non-kdbus codepaths.
+
+> As I already explained, software like glib2.0 and libdbus that supports
+> non-Linux kernels will anyway have to continue to support non-kdbus
+> systems forever.
+
+> Is there actually any implementation other than glib2.0 and libdbus that
+> would be affected by a switch to kdbus?
+
+This is an interesting question.  Josselin, is GNOME (for example) likely
+to acquire a hard dependency on kdbus through some mechanism?  I don't
+understand the plumbing of this stuff well enough to know where the
+dependencies could surface.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 17 Dec 2013 21:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 17 Dec 2013 21:06:04 GMT) (full text, mbox, link).

+ +

Message #991 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Tue, 17 Dec 2013 22:03:10 +0100
+
+
Hi Russ,
+
+Le mardi 17 décembre 2013 à 12:26 -0800, Russ Allbery a écrit :
+> > Is there actually any implementation other than glib2.0 and libdbus that
+> > would be affected by a switch to kdbus?
+> 
+> This is an interesting question.  Josselin, is GNOME (for example) likely
+> to acquire a hard dependency on kdbus through some mechanism?  I don't
+> understand the plumbing of this stuff well enough to know where the
+> dependencies could surface.
+
+That doesn’t seem very likely to me. In terms of library API, kdbus
+doesn’t change anything, so there is no need for applications to depend
+on it.
+
+There could be indirect problems, though.
+      * The session bus daemon will probably be started by systemd
+        (using kdbus) when GNOME migrate to systemd user sessions. The
+        old code should still work for some time, but we might have to
+        hold back some packages, and lose some benefits.
+      * Since kdbus is much faster, applications might start to rely on
+        that and lose performance on systems without kdbus.
+
+Cheers,
+-- 
+.''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 17 Dec 2013 23:15:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sam Hartman <hartmans@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 17 Dec 2013 23:15:07 GMT) (full text, mbox, link).

+ +

Message #996 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sam Hartman <hartmans@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Tue, 17 Dec 2013 18:02:50 -0500
+
+
>>>>> "Adrian" == Adrian Bunk <bunk@stusta.de> writes:
+
+
+    Adrian> Yes, it is speculation that other new features (or even
+    Adrian> bugfixes) might appear in the kernel and might become
+    Adrian> mandatory in systemd between jessie and jessie+1.
+
+    Adrian> But that is a risk, and it is a risk that is unique to the
+    Adrian> systemd option since none of the alternatives is
+    Adrian> Linux-only. [2]
+
+    Adrian> My whole point is not about kdbus specifically (which might
+    Adrian> even end up in the jessie kernel), but about that (IMHO
+    Adrian> substantial) risk.
+
+I'm confused, when I hear you say that this risk is unique to the
+systemd option and not shared by other options.  I would understand that
+statement if we thought we could avoid systemd entirely.  It sounds like
+we may be able to avoid systemd as pid 1 but systemd is very likely to
+play an important role in the Debian desktop storpy even if we adopt
+another pid 1.
+
+It seems like if systemd starts depending on a new kernel feature then
+it might well need that feature even when not running as pid 1.
+
+So, when evaluating the opportunity costs of this risk in the pid 1
+debate it seems like there are two important mitigating circumstances:
+
+* The extent to which upstream will provide stability, reducing the risk
+
+* The extent to which we cannot avoid the risk even if we choose another
+  pid 1, reducing the portion of the cost of this risk properly in-scope
+  for this bug.
+
+I understand some systems may not need systemd if we choose one of the
+other options.  However saying "if you installed Gnome you cannot
+upgrade," seems like a fairly unfortunate statement.
+
+At some level, we also need to be community players.  Since upgrade
+stability is important to us, we should advocate for it in open-source
+projects that we depend on.  On the flip side, if enough of the rest of
+the community after having carefully considered our arguments decides
+that our desire for stability is too expensive, perhaps we need to
+reconsider our position.  I hope we don't need to do that, but sometimes
+when enough of the rest of the world disagrees with you, you need to
+move on.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 17 Dec 2013 23:45:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 17 Dec 2013 23:45:15 GMT) (full text, mbox, link).

+ +

Message #1001 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Sam Hartman <hartmans@debian.org>
+
Cc: Adrian Bunk <bunk@stusta.de>, 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Tue, 17 Dec 2013 15:43:01 -0800
+
+
Sam Hartman <hartmans@debian.org> writes:
+
+> I'm confused, when I hear you say that this risk is unique to the
+> systemd option and not shared by other options.  I would understand that
+> statement if we thought we could avoid systemd entirely.  It sounds like
+> we may be able to avoid systemd as pid 1 but systemd is very likely to
+> play an important role in the Debian desktop storpy even if we adopt
+> another pid 1.
+
+> It seems like if systemd starts depending on a new kernel feature then
+> it might well need that feature even when not running as pid 1.
+
+> So, when evaluating the opportunity costs of this risk in the pid 1
+> debate it seems like there are two important mitigating circumstances:
+
+> * The extent to which upstream will provide stability, reducing the risk
+
+> * The extent to which we cannot avoid the risk even if we choose another
+>   pid 1, reducing the portion of the cost of this risk properly in-scope
+>   for this bug.
+
+> I understand some systems may not need systemd if we choose one of the
+> other options.  However saying "if you installed Gnome you cannot
+> upgrade," seems like a fairly unfortunate statement.
+
+> At some level, we also need to be community players.  Since upgrade
+> stability is important to us, we should advocate for it in open-source
+> projects that we depend on.  On the flip side, if enough of the rest of
+> the community after having carefully considered our arguments decides
+> that our desire for stability is too expensive, perhaps we need to
+> reconsider our position.  I hope we don't need to do that, but sometimes
+> when enough of the rest of the world disagrees with you, you need to
+> move on.
+
++1 to all of this.
+
+Sam expresses here roughly what I've been trying to express, but much
+better than I have managed to express it.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 11:39:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 11:39:09 GMT) (full text, mbox, link).

+ +

Message #1006 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Sam Hartman <hartmans@debian.org>
+
Cc: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>, + Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 13:34:49 +0200
+
+
On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote:
+> >>>>> "Adrian" == Adrian Bunk <bunk@stusta.de> writes:
+> 
+> 
+>     Adrian> Yes, it is speculation that other new features (or even
+>     Adrian> bugfixes) might appear in the kernel and might become
+>     Adrian> mandatory in systemd between jessie and jessie+1.
+> 
+>     Adrian> But that is a risk, and it is a risk that is unique to the
+>     Adrian> systemd option since none of the alternatives is
+>     Adrian> Linux-only. [2]
+> 
+>     Adrian> My whole point is not about kdbus specifically (which might
+>     Adrian> even end up in the jessie kernel), but about that (IMHO
+>     Adrian> substantial) risk.
+> 
+> I'm confused, when I hear you say that this risk is unique to the
+> systemd option and not shared by other options.  I would understand that
+> statement if we thought we could avoid systemd entirely.  It sounds like
+> we may be able to avoid systemd as pid 1 but systemd is very likely to
+> play an important role in the Debian desktop storpy even if we adopt
+> another pid 1.
+> 
+> It seems like if systemd starts depending on a new kernel feature then
+> it might well need that feature even when not running as pid 1.
+> 
+> So, when evaluating the opportunity costs of this risk in the pid 1
+> debate it seems like there are two important mitigating circumstances:
+> 
+> * The extent to which upstream will provide stability, reducing the risk
+> 
+> * The extent to which we cannot avoid the risk even if we choose another
+>   pid 1, reducing the portion of the cost of this risk properly in-scope
+>   for this bug.
+
+Thanks for the explanation, and apologies to Josselin and Russ that
+I completely misread their point regarding udev:
+
+I was misreading that as referring to the headaches udev had caused in 
+the past for Debian upgrades, not that the systemd udev might be the 
+cause of future upgrade headaches.
+
+But I do not buy this "We already switched to systemd as upstream of 
+udev, so we also have swallow the rest of it":
+
+When not using systemd as pid 1, that risk would be confined to the 
+parts of systemd Debian would be using (currently only udev).
+
+And since Ubuntu will also be in the "no systemd and supports upgrades 
+from 2 year old releases" camp, chances are that there would be 
+solutions available that Debian could use.
+
+As an example, if the systemd udev gets a hard dependency on a too 
+recent kernel or on systemd internals, there might be a fork of udev
+that provides a standalone udev that is suitable for Ubuntu and Debian.
+
+
+>...
+> At some level, we also need to be community players.  Since upgrade
+> stability is important to us, we should advocate for it in open-source
+> projects that we depend on.  On the flip side, if enough of the rest of
+> the community after having carefully considered our arguments decides
+> that our desire for stability is too expensive, perhaps we need to
+> reconsider our position.  I hope we don't need to do that, but sometimes
+> when enough of the rest of the world disagrees with you, you need to
+> move on.
+
+That point you bring up is semi-orthogonal to the upgrade decision,
+but it also brings up two important points that have to be considered:
+
+1. What is the governance model of the systemd community?
+
+This might be a bit polemic, but I'd fear that your "enough of the rest 
+of the community after having carefully considered our arguments decides"
+might end up being the same as "if Lennart decides it does not match his 
+vision of how things should work".
+
+This is a real issue since systemd is attempting to absorb a lot of 
+essential Linux functionality, giving whoever makes the decisions in
+systemd a lot of power over policies affecting all distributions
+using systemd.
+
+And
+
+2. Does anyone have a complete overview of what Debian policies might
+   have to be changed now or possibly at some later time as a result
+   of making systemd pid 1?
+
+systemd does not support non-Linux kernels [1], and realistically using 
+systemd as pid 1 in jessie will kill all non-Linux ports of Debian. [2]
+
+systemd upstream only reluctantly supports the option to have a separate
+/usr (as currently mandated by Debian policy), and I would not be 
+surprised if that gets dropped any time if it becomes an obstacle
+for development of any part of systemd.
+
+And now you bring up the point that Debian should reconsider the 
+lenght of it's release cycles if systemd upstream decides to not
+support upgrades between distribution releases as far apart as Debian's. [3]
+
+There are likely more areas where Debian would have to adapt if using 
+systemd.
+
+
+The more I think about it, the more I wish the TC would decide:
+  * jessie will continue to use sysvinit, and the TC will re-evaluate
+    the situation after the release of jessie
+
+Rationale:
+- as time passes, the kernel<->systemd interface will become more
+  stable [4], reducing potential upgrade problems and
+- the full consequences of a switch to systemd on various areas
+  of Debian will become more clear
+
+
+cu
+Adrian
+
+[1] which is not an unreasonable design decision considering what
+    systemd aims to do
+[2] with 1200 init scripts in Debian, I do not see how it would be
+    feasible to ensure that several different implementations of each
+    will be of equal quality in the long run - especially considering
+    that soon only very few Debian developers would not be using systemd
+    on their machines
+[3] I would definitely appreciate if Debian would have a new release
+    once or twice a year, but I think that is not a decision that
+    should possibly be dictated by systemd upstream
+[4] new features systemd wants like kdbus will already be in the kernel
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 12:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 12:21:04 GMT) (full text, mbox, link).

+ +

Message #1011 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 13:19:48 +0100
+
+
Hi Adrian,
+
+Le mercredi 18 décembre 2013 à 13:34 +0200, Adrian Bunk a écrit : 
+> That point you bring up is semi-orthogonal to the upgrade decision,
+> but it also brings up two important points that have to be considered:
+> 
+> 1. What is the governance model of the systemd community?
+> 
+> This might be a bit polemic, but I'd fear that your "enough of the rest 
+> of the community after having carefully considered our arguments decides"
+> might end up being the same as "if Lennart decides it does not match his 
+> vision of how things should work".
+
+This is a red herring that has been recurrently agitated, on the basis
+of the PulseAudio experience, but so far it has never proven to have any
+basis in reality. Just because Lennart is a developer in both projects,
+doesn’t mean they have the same governance model.
+
+Systemd’s development is driven by the needs of its users. It has even
+incorporated a lot of Debian’s needs, despite our choice so far to delay
+its inclusion. It has used some of Debian’s good practices
+(e.g. /etc/hostname or /etc/timezone) as a basis for standardization
+across other distributions.
+
+> This is a real issue since systemd is attempting to absorb a lot of 
+> essential Linux functionality, giving whoever makes the decisions in
+> systemd a lot of power over policies affecting all distributions
+> using systemd.
+
+Things work the other way round. Debian will have more weight in the
+future of systemd if we adopt it. It is unreasonable to ask an upstream
+project to conform to your policies if you don’t even use it. We need to
+play with the community: embrace systemd, and use that weight in the
+decisions affecting its future.
+
+Let’s consider the kdbus example in this light. If Debian is a major
+systemd player, it is more likely that upstream will support a fallback
+to the old dbus-daemon until a kdbus-enabled kernel makes it to a stable
+Debian release, or at least makes it easier for us to maintain that
+fallback. If Debian does not pick systemd, what is the point for
+upstream in making their software more complex for the benefit of
+nobody?
+
+Maybe it will not work. Maybe the cost for upstream will be too high
+regardless. I might have to remind you that the sarge→etch upgrade had a
+locked-in upgrade of udev and the kernel. The world did not crumble, and
+we didn’t abandon our policies just because we had to make an exception.
+(Actually this upgrade was much smoother than the python shit in
+squeeze→wheezy.) We made it work that time, and if, despite our efforts,
+we have to make another exception, we will make it work again. Leaving
+out important features until a hypothetical date, just because we fear
+our own skills and ability to provide smooth upgrades, doesn’t sound
+like a great plan to me.
+
+> systemd upstream only reluctantly supports the option to have a separate
+> /usr (as currently mandated by Debian policy), and I would not be 
+> surprised if that gets dropped any time if it becomes an obstacle
+> for development of any part of systemd.
+
+This is another red herring. The Debian code to support a split /usr by
+mounting it from the initrd is simple, and not likely to be broken by
+any new developments.
+
+I see much irony in seeing people fear for non-Linux ports, for one of
+which we have maintained easy patches for years allowing for a
+merged /usr, and at the same time argue that maintaining a split /usr
+for Linux will be hard.
+
+> And now you bring up the point that Debian should reconsider the 
+> lenght of it's release cycles if systemd upstream decides to not
+> support upgrades between distribution releases as far apart as Debian's. [3]
+
+Well, of course we should reconsider the length of our release cycle
+(and make it 3 years like major OS players do), but this is irrelevant
+to the choice of an init system.
+
+> The more I think about it, the more I wish the TC would decide:
+>   * jessie will continue to use sysvinit, and the TC will re-evaluate
+>     the situation after the release of jessie
+
+This option does not look realistic to me. At least the upstart
+proponents have outlined a strategy to keep software depending on
+systemd interfaces working in jessie.
+
+Cheers,
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 13:12:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 13:12:07 GMT) (full text, mbox, link).

+ +

Message #1016 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 15:10:19 +0200
+
+
On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote:
+> On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote:
+> > I'm confused, when I hear you say that this risk is unique to the
+> > systemd option and not shared by other options.  I would understand that
+> > statement if we thought we could avoid systemd entirely.  It sounds like
+> > we may be able to avoid systemd as pid 1 but systemd is very likely to
+> > play an important role in the Debian desktop storpy even if we adopt
+> > another pid 1.
+
+> Thanks for the explanation, and apologies to Josselin and Russ that
+> I completely misread their point regarding udev:
+> 
+> I was misreading that as referring to the headaches udev had caused in 
+> the past for Debian upgrades, not that the systemd udev might be the 
+> cause of future upgrade headaches.
+> 
+> But I do not buy this "We already switched to systemd as upstream of 
+> udev, so we also have swallow the rest of it":
+> 
+> When not using systemd as pid 1, that risk would be confined to the 
+> parts of systemd Debian would be using (currently only udev).
+
+I think you still misread the argument: IMO it's clear that it
+considered more than udev as likely to be required, even if udev is the
+only one in current Debian. So if you disagree, you should at least
+address the question of why you believe udev will stay the only one.
+
+
+> > At some level, we also need to be community players.  Since upgrade
+> > stability is important to us, we should advocate for it in open-source
+> > projects that we depend on.  On the flip side, if enough of the rest of
+> > the community after having carefully considered our arguments decides
+> > that our desire for stability is too expensive, perhaps we need to
+> > reconsider our position.  I hope we don't need to do that, but sometimes
+> > when enough of the rest of the world disagrees with you, you need to
+> > move on.
+
+
+> systemd upstream only reluctantly supports the option to have a separate
+> /usr (as currently mandated by Debian policy), and I would not be 
+> surprised if that gets dropped any time if it becomes an obstacle
+> for development of any part of systemd.
+
+You're mixing two separate issues (or at least not clearly indicating
+which one you're talking about). Systemd fully supports having a
+separate /usr partition, and that is in no way deprecated AFAIK. What
+has changed compared to "old practice" is that /usr needs to be mounted
+together with root (requiring initramfs if you have a separate /usr;
+where you had "mount /" before you now have "mount / and /usr"). Whether
+the old way of later /usr mounting could keep working with any other
+init either is questionable.
+
+Then there is the move of binaries from /bin to /usr/bin, which does
+have some backwards compatibility logic for different paths in systemd.
+This is not directly connected to /usr being a separate partition or not
+(but having everything in /usr/bin obviously requires /usr mounted
+early). Does someone in Debian seriously oppose this move as a long term
+goal?
+
+
+> And now you bring up the point that Debian should reconsider the 
+> lenght of it's release cycles if systemd upstream decides to not
+> support upgrades between distribution releases as far apart as Debian's. [3]
+
+I don't think anyone said that. Nobody talked about long release cycles
+not being supported, and nobody said that upgrades would not be
+supported either. However, "supporting upgrade from the old release"
+does not equal things like being able to run the new userland on the 3+
+year old kernel from the previous release.
+
+A development model where you have to wait 3+ years before you can have
+hard dependencies on the new features you write now is obviously very
+problematic. IMO such restraints should never be taken for granted;
+upgrade schemes should always be planned to at least make it possible to
+have newer dependencies without too much trouble.
+
+In the kdbus case, systemd upstream already mentioned the possibility of
+shipping kdbus as a new module for older kernels. More generally, you
+can have solutions like applying some upgrades at boot rather than
+trying to switch parts from under a fully live system. This does still
+count as fully supporting upgrades.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 13:27:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve McIntyre <steve@einval.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 13:27:09 GMT) (full text, mbox, link).

+ +

Message #1021 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve McIntyre <steve@einval.com>
+
To: Uoti Urpala <uoti.urpala@pp1.inet.fi>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 13:24:25 +0000
+
+
On Wed, Dec 18, 2013 at 03:10:19PM +0200, Uoti Urpala wrote:
+>
+>In the kdbus case, systemd upstream already mentioned the possibility of
+>shipping kdbus as a new module for older kernels. More generally, you
+>can have solutions like applying some upgrades at boot rather than
+>trying to switch parts from under a fully live system. This does still
+>count as fully supporting upgrades.
+
+You might think so. To me, that sounds like a hacky workaround for
+needlessly inflexible software. Much like Windows.
+
+-- 
+Steve McIntyre, Cambridge, UK.                                steve@einval.com
+"The problem with defending the purity of the English language is that
+ English is about as pure as a cribhouse whore. We don't just borrow words; on
+ occasion, English has pursued other languages down alleyways to beat them
+ unconscious and rifle their pockets for new vocabulary."  -- James D. Nicoll
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 14:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sam Hartman <hartmans@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 14:06:04 GMT) (full text, mbox, link).

+ +

Message #1026 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sam Hartman <hartmans@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 08:53:04 -0500
+
+
Adrian, I'm frustrated when I read your message because you put words in
+my mouth that I did not speak.
+I never said that Debian should allow systemd to dictate policy for
+multiple distributions nor did I say that Debian should allow one
+upstream systemd maintainer to dictate decisions for Debian.
+I spoke of community both in terms of a systemd community and in terms
+of  a community of Linux distributions.
+
+
+You may believe that some of these boil down to the same thing.  I
+request that you distinguish what you believe is a conclusion from
+things I've said from the things I actually say.
+
+Thanks,
+
+--Sam
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 14:18:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 14:18:08 GMT) (full text, mbox, link).

+ +

Message #1031 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 15:15:33 +0100
+
+
]] Uoti Urpala 
+
+> In the kdbus case, systemd upstream already mentioned the possibility of
+> shipping kdbus as a new module for older kernels. More generally, you
+> can have solutions like applying some upgrades at boot rather than
+> trying to switch parts from under a fully live system. This does still
+> count as fully supporting upgrades.
+
+I have no intention of implementing an upgrade-on-boot scheme in
+the systemd package.  One of the many problems with such a scheme is
+that recovery becomes much harder, since your system no longer boots and
+you don't have a working shell or network or anything at that point.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 14:30:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 14:30:09 GMT) (full text, mbox, link).

+ +

Message #1036 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Josselin Mouette <joss@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 16:26:44 +0200
+
+
On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote:
+> Hi Adrian,
+
+Hi Josselin,
+
+> Le mercredi 18 décembre 2013 à 13:34 +0200, Adrian Bunk a écrit : 
+> > That point you bring up is semi-orthogonal to the upgrade decision,
+> > but it also brings up two important points that have to be considered:
+> > 
+> > 1. What is the governance model of the systemd community?
+> > 
+> > This might be a bit polemic, but I'd fear that your "enough of the rest 
+> > of the community after having carefully considered our arguments decides"
+> > might end up being the same as "if Lennart decides it does not match his 
+> > vision of how things should work".
+> 
+> This is a red herring that has been recurrently agitated, on the basis
+> of the PulseAudio experience, but so far it has never proven to have any
+> basis in reality. Just because Lennart is a developer in both projects,
+> doesn’t mean they have the same governance model.
+
+the *so far* is the worrisome part, considering how much power to 
+enforce policy whoever controls systemd has.
+
+Switching to systemd also implies to trust that Lennart will do the 
+right things.
+
+I am not in a position to judge whether or not Lennart should be 
+trusted, but everyone should be aware that this trust in Lennart
+is a requirement for a switch to systemd.
+
+
+>...
+> Maybe it will not work. Maybe the cost for upstream will be too high
+> regardless. I might have to remind you that the sarge→etch upgrade had a
+> locked-in upgrade of udev and the kernel. The world did not crumble, and
+> we didn’t abandon our policies just because we had to make an exception.
+> (Actually this upgrade was much smoother than the python shit in
+> squeeze→wheezy.) We made it work that time, and if, despite our efforts,
+> we have to make another exception, we will make it work again.
+
+We already seem to agree that the statement in the systemd position 
+statement that "does not have any impact on the ability to upgrade 
+systems" is not correct.
+
+There might potentially be non-trivial jessie -> jessie+1 upgrade 
+problems with systemd, and even though such issues will likely be 
+work-aroundable with an unknown amount of effort, they are something
+to take into consideration.
+
+
+> Leaving out important features until a hypothetical date,
+
+What exactly is the list of features that are lost as of today if Debian 
+uses in jessie the logind from the systemd 204 package in unstable and 
+perhaps work Ubuntu has done for a non-systemd system?
+
+This won't solve the issue long-term, but it would give us 2 more years 
+to observe how the whole init system situation develops.
+
+
+> > systemd upstream only reluctantly supports the option to have a separate
+> > /usr (as currently mandated by Debian policy), and I would not be 
+> > surprised if that gets dropped any time if it becomes an obstacle
+> > for development of any part of systemd.
+> 
+> This is another red herring. The Debian code to support a split /usr by
+> mounting it from the initrd is simple, and not likely to be broken by
+> any new developments.
+
+Are you saying that Debian will not use the --enable-split-usr configure 
+option of systemd, and therefore won't have to change policy if it ever 
+goes away?
+
+
+> I see much irony in seeing people fear for non-Linux ports, for one of
+> which we have maintained easy patches for years allowing for a
+> merged /usr, and at the same time argue that maintaining a split /usr
+> for Linux will be hard.
+
+See my question above.
+
+On a general note, neither non-Linux kernels nor a split /usr are 
+something I consider extremely important myself. But these are examples
+for policy decisions that might be caused by a switch to systemd.
+
+
+> > And now you bring up the point that Debian should reconsider the 
+> > lenght of it's release cycles if systemd upstream decides to not
+> > support upgrades between distribution releases as far apart as Debian's. [3]
+> 
+> Well, of course we should reconsider the length of our release cycle
+> (and make it 3 years like major OS players do),
+
+You miss the critical difference:
+
+Red Hat does not support upgrades between major releases of their 
+enterprise distribution.
+
+
+> but this is irrelevant to the choice of an init system.
+
+It is not, when the init system might cause upgrade problems.
+
+
+> > The more I think about it, the more I wish the TC would decide:
+> >   * jessie will continue to use sysvinit, and the TC will re-evaluate
+> >     the situation after the release of jessie
+> 
+> This option does not look realistic to me.
+
+See my question on that issue above.
+
+
+> At least the upstart
+> proponents have outlined a strategy to keep software depending on
+> systemd interfaces working in jessie.
+
+The worst case would be that Debian switches init systems in jessie
+(e.g. to upstart) and then again in jessie+1 (e.g. if systemd then
+turns out to be the best solution, or if Canonical abandons upstart).
+
+
+> Cheers,
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 14:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 14:51:04 GMT) (full text, mbox, link).

+ +

Message #1041 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>, 727708@bugs.debian.org
+
Cc: Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 09:46:31 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Dec 18, 2013 at 04:26:44PM +0200, Adrian Bunk wrote:
+> the *so far* is the worrisome part, considering how much power to 
+> enforce policy whoever controls systemd has.
+> 
+> Switching to systemd also implies to trust that Lennart will do the 
+> right things.
+> 
+> I am not in a position to judge whether or not Lennart should be 
+> trusted, but everyone should be aware that this trust in Lennart
+> is a requirement for a switch to systemd.
+
+
+Firstly, we don't have to trust Lennart, we have to trust the team
+working on systemd. I believe there to be a distinction there, and I do
+trust that team won't break all the systemdistros to get their jollies.
+
+Secondly, systemd is free software. If and when systemd diverges from
+what we need it to do, we can consider a fork. I don't want a fork, and
+I'm willing to bet the systemd folks won't either. It's not like we're
+locked into whatever Lennart decides.
+
+Cheers,
+  Paul
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
+: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+`. `'`  http://people.debian.org/~paultag
+ `-     http://people.debian.org/~paultag/conduct-statement.txt
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 14:51:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 14:51:07 GMT) (full text, mbox, link).

+ +

Message #1046 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Sam Hartman <hartmans@debian.org>
+
Cc: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>, + Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 16:49:15 +0200
+
+
On Wed, Dec 18, 2013 at 08:53:04AM -0500, Sam Hartman wrote:
+> Adrian, I'm frustrated when I read your message because you put words in
+> my mouth that I did not speak.
+
+Hi Sam,
+
+> I never said that Debian should allow systemd to dictate policy for
+> multiple distributions nor did I say that Debian should allow one
+> upstream systemd maintainer to dictate decisions for Debian.
+
+I assume you are referring to
+  That point you bring up is semi-orthogonal to the upgrade decision,
+  but it also brings up two important points that have to be considered:
+
+The second line was not intended to imply that you said that, just very 
+poorly worded by me.
+
+The second line might have been better worded like
+  Possible problems I see when following this "we also need to be 
+  community players":
+
+> I spoke of community both in terms of a systemd community and in terms
+> of  a community of Linux distributions.
+
+The problematic parts are where Debian differs from other distributions.
+
+E.g. Debian has been the only big Linux distribution that did support 
+non-Linux kernels. If Debian wants to be closely aligned to the 
+consensus among other distributions it might have to drop non-Linux 
+kernels, and switching to systemd basically enforces that.
+
+> You may believe that some of these boil down to the same thing.  I
+> request that you distinguish what you believe is a conclusion from
+> things I've said from the things I actually say.
+
+See above regarding my poor wording.
+
+> Thanks,
+> 
+> --Sam
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 14:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 14:54:04 GMT) (full text, mbox, link).

+ +

Message #1051 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 15:50:33 +0100
+
+
Hi,
+
+Le mercredi 18 décembre 2013 à 16:26 +0200, Adrian Bunk a écrit : 
+> We already seem to agree that the statement in the systemd position 
+> statement that "does not have any impact on the ability to upgrade 
+> systems" is not correct.
+
+No, we do not. I have already explained why I believe the kdbus question
+(and maybe similar ones) will arise whether we switch to systemd or not.
+I do not consider keeping an arbitrary number of packages at the wheezy
+version an appropriate answer, regardless of the choice of init systems.
+
+You also deliberately omitted to quote the part where I explained why
+this is less likely to happen if we actually become part of the systemd
+community instead of judging their work on our standards.
+
+> What exactly is the list of features that are lost as of today if Debian 
+> uses in jessie the logind from the systemd 204 package in unstable and 
+> perhaps work Ubuntu has done for a non-systemd system?
+
+Quoting myself from the debate page:
+“Many discussions are centered on systemd-logind as in being the only
+problem to address by other proposals, wildly proposing seemingly
+easy-to-develop replacements.”
+
+If you have other questions relevant for the discussion at hand, please
+go ahead, but I will not jump into arguments running in circles. We
+systemd proponents have spent a lot of time summing up the functional
+reasons why we want systemd on our Debian systems, with logind being one
+reason among dozens; you could have read them before asking the same
+question again.
+
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 15:21:09 GMT) (full text, mbox, link).

+ +

Message #1054 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 16:10:19 +0100
+
+
Hi,
+
+Adrian Bunk <bunk@stusta.de> writes:
+> On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote:
+>> > And now you bring up the point that Debian should reconsider the 
+>> > lenght of it's release cycles if systemd upstream decides to not
+>> > support upgrades between distribution releases as far apart as Debian's. [3]
+>> 
+>> Well, of course we should reconsider the length of our release cycle
+>> (and make it 3 years like major OS players do),
+>
+> You miss the critical difference:
+>
+> Red Hat does not support upgrades between major releases of their 
+> enterprise distribution.
+
+Except they do: "Red Hat Enterprise Linux 7 will offer an in-place
+upgrade feature for common server deployment types, allowing data
+centers to migrate existing Red Hat Enterprise Linux 6.5 systems to Red
+Hat Enterprise Linux 7"[1].
+
+Ansgar
+
+   [1] <http://www.redhat.com/about/news/archive/2013/12/red-hat-announces-availability-of-red-hat-enterprise-linux-7-beta>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 15:24:21 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 15:24:21 GMT) (full text, mbox, link).

+ +

Message #1059 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 17:23:22 +0200
+
+
On Wed, Dec 18, 2013 at 03:10:19PM +0200, Uoti Urpala wrote:
+> On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote:
+>...
+> > When not using systemd as pid 1, that risk would be confined to the 
+> > parts of systemd Debian would be using (currently only udev).
+> 
+> I think you still misread the argument: IMO it's clear that it
+> considered more than udev as likely to be required, even if udev is the
+> only one in current Debian. So if you disagree, you should at least
+> address the question of why you believe udev will stay the only one.
+
+I think you misread what I wrote.
+
+I wrote "part*s* of systemd", and that *currently* udev is the only one.
+
+
+> > > At some level, we also need to be community players.  Since upgrade
+> > > stability is important to us, we should advocate for it in open-source
+> > > projects that we depend on.  On the flip side, if enough of the rest of
+> > > the community after having carefully considered our arguments decides
+> > > that our desire for stability is too expensive, perhaps we need to
+> > > reconsider our position.  I hope we don't need to do that, but sometimes
+> > > when enough of the rest of the world disagrees with you, you need to
+> > > move on.
+> 
+> 
+> > systemd upstream only reluctantly supports the option to have a separate
+> > /usr (as currently mandated by Debian policy), and I would not be 
+> > surprised if that gets dropped any time if it becomes an obstacle
+> > for development of any part of systemd.
+> 
+> You're mixing two separate issues (or at least not clearly indicating
+> which one you're talking about). Systemd fully supports having a
+> separate /usr partition, and that is in no way deprecated AFAIK. What
+> has changed compared to "old practice" is that /usr needs to be mounted
+> together with root
+
+Thanks for the clarification, I missed that this useful part of having a 
+separate /usr (mounting it later) is already broken with systemd.
+
+
+> Whether
+> the old way of later /usr mounting could keep working with any other
+> init either is questionable.
+
+I am not seeing any reason why it should suddenly stop working with 
+sysvinit.
+
+
+> A development model where you have to wait 3+ years before you can have
+> hard dependencies on the new features you write now is obviously very
+> problematic. IMO such restraints should never be taken for granted;
+> upgrade schemes should always be planned to at least make it possible to
+> have newer dependencies without too much trouble.
+
+For normal dependencies there is no such restraint.
+
+Only when the dependency is on a new kernel there is a problem and the 
+upgrade becomes complicated.
+
+
+cu
+Adrian
+
+BTW: Please Cc me on replies - even though I am subscribed to the bug,
+     I don't seem to get the mails.
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 15:30:03 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 15:30:04 GMT) (full text, mbox, link).

+ +

Message #1064 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 16:27:55 +0100
+
+
Hi Uorti,
+
+Le mercredi 18 décembre 2013 à 15:10 +0200, Uoti Urpala a écrit : 
+> I don't think anyone said that. Nobody talked about long release cycles
+> not being supported, and nobody said that upgrades would not be
+> supported either. However, "supporting upgrade from the old release"
+> does not equal things like being able to run the new userland on the 3+
+> year old kernel from the previous release.
+> 
+> A development model where you have to wait 3+ years before you can have
+> hard dependencies on the new features you write now is obviously very
+> problematic. IMO such restraints should never be taken for granted;
+> upgrade schemes should always be planned to at least make it possible to
+> have newer dependencies without too much trouble.
+
+Such stances are untenable whenever the kernel is concerned. We need to
+be able to use a kernel from the previous stable distribution, or from
+the next one, to support proper chroots. This part of the support for
+upgrades is needed for our own infrastructure as well as for many of our
+users.
+
+It is possible to handle the situation with udev or with systemd,
+because they do not make sense in a chroot environment, but they are the
+exception, not the rule. And unless things go hectic, we *will* be able
+to treat them normally and provide an upgrade path that doesn’t force
+users to do locked upgrades.
+
+All of this looks very far away from the init system discussion,
+though. 
+
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 15:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 15:48:04 GMT) (full text, mbox, link).

+ +

Message #1069 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Ansgar Burchardt <ansgar@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 17:44:58 +0200
+
+
On Wed, Dec 18, 2013 at 04:10:19PM +0100, Ansgar Burchardt wrote:
+> Hi,
+> 
+> Adrian Bunk <bunk@stusta.de> writes:
+> > On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote:
+> >> > And now you bring up the point that Debian should reconsider the 
+> >> > lenght of it's release cycles if systemd upstream decides to not
+> >> > support upgrades between distribution releases as far apart as Debian's. [3]
+> >> 
+> >> Well, of course we should reconsider the length of our release cycle
+> >> (and make it 3 years like major OS players do),
+> >
+> > You miss the critical difference:
+> >
+> > Red Hat does not support upgrades between major releases of their 
+> > enterprise distribution.
+> 
+> Except they do: "Red Hat Enterprise Linux 7 will offer an in-place
+> upgrade feature for common server deployment types, allowing data
+> centers to migrate existing Red Hat Enterprise Linux 6.5 systems to Red
+> Hat Enterprise Linux 7"[1].
+
+That is good news (RHEL5->RHEL6 was not supported).
+
+If anyone finds (or asks) what backwards compatibility future systemd 
+versions will offer with 3 year old kernels that would settle my initial 
+upgrade issue point. [1]
+
+> Ansgar
+
+cu
+Adrian
+
+[1] Personally, I am sceptical whether it is a good idea to switch to a
+    different init system for jessie. But I am not on a desperate rant 
+    against systemd, and if something I bring up can be addressed that
+    is positive for me.
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 16:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 16:33:04 GMT) (full text, mbox, link).

+ +

Message #1074 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Josselin Mouette <joss@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 18:31:09 +0200
+
+
On Wed, Dec 18, 2013 at 03:50:33PM +0100, Josselin Mouette wrote:
+> Hi,
+
+Hi Josselin,
+
+>...
+> I do not consider keeping an arbitrary number of packages at the wheezy
+> version an appropriate answer, regardless of the choice of init systems.
+>...
+
+how many and which packages would have to be kept at the wheezy version 
+if Debian does not switch to systemd?
+
+> -- 
+>  .''`.        Josselin Mouette
+> : :' :
+> `. `'
+>   `-
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 16:51:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 16:51:09 GMT) (full text, mbox, link).

+ +

Message #1079 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 18:49:06 +0200
+
+
On Wed, 2013-12-18 at 16:27 +0100, Josselin Mouette wrote:
+> Such stances are untenable whenever the kernel is concerned. We need to
+> be able to use a kernel from the previous stable distribution, or from
+> the next one, to support proper chroots. This part of the support for
+> upgrades is needed for our own infrastructure as well as for many of our
+> users.
+> 
+> It is possible to handle the situation with udev or with systemd,
+> because they do not make sense in a chroot environment, but they are the
+> exception, not the rule. And unless things go hectic, we *will* be able
+> to treat them normally and provide an upgrade path that doesn’t force
+> users to do locked upgrades.
+> 
+> All of this looks very far away from the init system discussion,
+> though. 
+
+I agree this is moving away from init discussion, but I want to address
+the part about "locked upgrades". Just depending on new kernel features
+is not the same as "lockstep" as in needing to upgrade everything
+together (like the case where old udev didn't work with new kernel _and_
+new kernel didn't work with old udev). If you upgrade to a kernel with
+backported features, that obviously should not cause any special issues.
+And the kernel typically tries fairly hard to keep old userspace
+working, so even upgrading to a completely new kernel version doesn't
+mean you have to upgrade the whole userspace. If running the next
+release in a chroot on your stable machine requires an upgraded kernel
+package with backported features, or even a completely new kernel
+version, that's much less of a problem than needing to upgrade the whole
+OS.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 20:30:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 20:30:05 GMT) (full text, mbox, link).

+ +

Message #1084 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 21:26:44 +0100
+
+
]] Adrian Bunk 
+
+> > You're mixing two separate issues (or at least not clearly indicating
+> > which one you're talking about). Systemd fully supports having a
+> > separate /usr partition, and that is in no way deprecated AFAIK. What
+> > has changed compared to "old practice" is that /usr needs to be mounted
+> > together with root
+> 
+> Thanks for the clarification, I missed that this useful part of having a 
+> separate /usr (mounting it later) is already broken with systemd.
+
+No, it's not.  systemd will emit a warning that some services might be
+broken because of this, systemd itself works just fine.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 22:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 22:48:04 GMT) (full text, mbox, link).

+ +

Message #1089 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: Sam Hartman <hartmans@debian.org>, 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 14:44:03 -0800
+
+
Adrian Bunk <bunk@stusta.de> writes:
+
+> I was misreading that as referring to the headaches udev had caused in 
+> the past for Debian upgrades, not that the systemd udev might be the 
+> cause of future upgrade headaches.
+
+> But I do not buy this "We already switched to systemd as upstream of 
+> udev, so we also have swallow the rest of it":
+
+I don't think anyone is making that argument.
+
+However, there is a valid related argument that, since we're already using
+much of systemd, our integrations will be easier if we also use systemd as
+the init system.  I don't think anyone considers that single argument
+alone to be conclusive, but it's relevant.
+
+Note that one can make, and people have made, an argument that we should
+intentionally make our integrations harder if by doing so we can weaken
+coupling between subsystems that we feel should be unrelated.  I'm not
+intending to comment on that argument in this message, just to note that
+it isn't a counterargument to the point above, but rather an argument
+about relative priority.  It's saying that a different goal -- weak
+coupling -- is more important than reduced Debian integration workload.
+
+> When not using systemd as pid 1, that risk would be confined to the
+> parts of systemd Debian would be using (currently only udev).
+
+There appears to be near-unanimous agreement that Debian will also be
+using logind in the near future.
+
+I think "only" in this context is misleading, given that the components
+we're going to be using anyway (including kdbus in this; if it's included
+in the kernel, I highly doubt Debian will refuse to use it in the long
+run) are pretty much the same components that people are concerned about
+being unstable.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 18 Dec 2013 22:57:03 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 18 Dec 2013 22:57:03 GMT) (full text, mbox, link).

+ +

Message #1094 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org, Ansgar Burchardt <ansgar@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Wed, 18 Dec 2013 14:53:39 -0800
+
+
Adrian Bunk <bunk@stusta.de> writes:
+
+> [1] Personally, I am sceptical whether it is a good idea to switch to a
+>     different init system for jessie. But I am not on a desperate rant 
+>     against systemd, and if something I bring up can be addressed that
+>     is positive for me.
+
+Just to give fair warning: right now, based on what I know today, there is
+basically zero chance that I personally will vote retaining sysvinit for
+jessie above further discussion.  So if you want to convince at least this
+one member of the technical committee that this is a viable option, you
+have quite a bit of work to do.
+
+Right now, it appears to me that the feature set is wholly inadequate,
+further substantial development is highly unlikely, the configuration
+syntax is familiar but awful, and we are already seeing software in the
+archive that requires capabilities that it's just not able to support.
+
+To support continuing to use sysvinit, I think I would need to see a
+credible plan for significant upstream development and support of the
+software, including, at a minimum, how the features that are required by
+our desktop environments would be handled, how device management and
+dependencies will be managed given the event-driven kernel, and how proper
+daemon management at least at the level common to upstart, systemd, and
+OpenRC will be added.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 00:12:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 00:12:09 GMT) (full text, mbox, link).

+ +

Message #1099 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Uoti Urpala <uoti.urpala@pp1.inet.fi>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd socket activation protocol rationale
+
Date: Thu, 19 Dec 2013 00:09:12 +0000
+
+
Uoti Urpala writes ("Bug#727708: systemd socket activation protocol rationale"):
+> On Sat, 2013-12-14 at 21:45 +0000, Ian Jackson wrote:
+> > Why do only some of the environment variables start "SD_" ?
+> > We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START.
+> 
+> You misread it: there is no environment variable SD_LISTEN_FDS_START.
+> The API defines the start value as the constant 3. There is a
+> corresponding #define in sd-daemon.h, but it is not communicated at
+> runtime.
+
+Oh, yes, I did misread it, thanks.
+
+> > What is the rationale behind the use of the LISTEN_PID variable and
+> > the pid check ?  It seems to me that at the very least this might make
+> > it hard to wrap up a socket-activated daemon in a shell script.
+> 
+> To ensure that the environment values are never accidentally inherited
+> by any child process.
+
+That much was clear.  The underlying reason for worrying about this
+wasn't.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 00:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 00:15:05 GMT) (full text, mbox, link).

+ +

Message #1104 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: OpenRC reference manual ?
+
Date: Thu, 19 Dec 2013 00:12:17 +0000
+
+
I wasn't able to find the reference manual for OpenRC.  Perhaps I'm
+just being dim.  Could someone please point me at it ?
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 01:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 01:21:04 GMT) (full text, mbox, link).

+ +

Message #1109 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian
+
Date: Thu, 19 Dec 2013 01:19:10 +0000
+
+
On Sat, Dec 14, 2013 at 08:28:25PM +0000, Ian Jackson wrote:
+> Ian Jackson writes ("upstart proposed policy in Debian"):
+> > Having read the docs there I have some apparently unanswered questions
+> > about how the upstart proponents think we would use upstart in Debian.
+> 
+> I found policy 9.11.1 which I had unaccountably failed to notice
+> before.  It answer the question of how to do the transition from
+> sysvinit to upstart, with a hideous shell rune.  Perhaps the upstart
+> package could provide a cooked command and then we could all say
+> 
+>   if init-is-upstart 2>/dev/null; then exit 1; fi
+> 
+> or something.
+
+There's an init_is_upstart shell function in /lib/lsb/init-functions
+(which is generally already sourced by SysV init scripts); it amounts to
+the rune in policy 9.11.1.  I'm not sure why policy hasn't been updated
+to refer to it, although
+https://wiki.ubuntu.com/UpstartCompatibleInitScripts does.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 01:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 01:33:04 GMT) (full text, mbox, link).

+ +

Message #1114 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian
+
Date: Thu, 19 Dec 2013 01:28:49 +0000
+
+
On Sat, Dec 14, 2013 at 01:36:59PM +0000, Ian Jackson wrote:
+> How will we cope with removed-but-not-purged services ?
+
+Somebody else can perhaps provide a better answer, but I'd note that
+this situation will generally just result in a log file complaining that
+the executable in question doesn't exist (and of course the service
+never reaching the "running" state, but that was expected), which isn't
+particularly awful.
+
+> Do we deprecate "expect fork" and "expect daemon" ?  (I would favour
+> this - the approach there is pretty horrible.)
+
+For cases where simply running the daemon in the foreground is
+insufficient (i.e. it's important to know more accurately about service
+readiness), I personally prefer "expect stop".  While raising SIGSTOP
+when they're ready isn't generally something daemons already support, it
+also normally has no other conflicting meaning.  It's trivial to patch
+into existing code and generally also trivial to maintain such a patch.
+This protocol is simple enough that it's very easy to reason about,
+which is helpful when investigating problems relating to service
+startup, and it requires no particularly exciting code in the init
+daemon since finding out about SIGSTOP already basically comes with the
+territory of being pid 1.
+
+I think we'd have to do some work to modify existing Upstart jobs to
+conform to this, but I also think that work would be worthwhile, as
+"expect fork" and "expect daemon" have been a bit flaky and they're a
+bit of an obstacle (perhaps not an insurmountable one) to porting to
+non-Linux kernels.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 01:39:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 01:39:08 GMT) (full text, mbox, link).

+ +

Message #1119 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian
+
Date: Thu, 19 Dec 2013 01:36:21 +0000
+
+
Colin Watson writes ("Re: Bug#727708: upstart proposed policy in Debian"):
+> On Sat, Dec 14, 2013 at 01:36:59PM +0000, Ian Jackson wrote:
+> > How will we cope with removed-but-not-purged services ?
+> 
+> Somebody else can perhaps provide a better answer, but I'd note that
+> this situation will generally just result in a log file complaining that
+> the executable in question doesn't exist (and of course the service
+> never reaching the "running" state, but that was expected), which isn't
+> particularly awful.
+
+Right.  So is the current practice just to ignore this problem and
+tolerate the errors in the logs ?
+
+> > Do we deprecate "expect fork" and "expect daemon" ?  (I would favour
+> > this - the approach there is pretty horrible.)
+> 
+> [lots of stuff]
+
+Exactly.
+
+>  and it requires no particularly exciting code in the init daemon
+> since finding out about SIGSTOP already basically comes with the
+> territory of being pid 1.
+
+It comes with being the daemon's parent, even - the special powers of
+pid 1 aren't even needed.
+
+> I think we'd have to do some work to modify existing Upstart jobs to
+> conform to this, but I also think that work would be worthwhile, as
+> "expect fork" and "expect daemon" have been a bit flaky and they're a
+> bit of an obstacle (perhaps not an insurmountable one) to porting to
+> non-Linux kernels.
+
+Yes.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 01:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 01:45:04 GMT) (full text, mbox, link).

+ +

Message #1124 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Colin Watson <cjwatson@debian.org>
+
Cc: 727708@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: upstart proposed policy in Debian
+
Date: Wed, 18 Dec 2013 17:42:11 -0800
+
+
Colin Watson <cjwatson@debian.org> writes:
+
+> For cases where simply running the daemon in the foreground is
+> insufficient (i.e. it's important to know more accurately about service
+> readiness), I personally prefer "expect stop".  While raising SIGSTOP
+> when they're ready isn't generally something daemons already support, it
+> also normally has no other conflicting meaning.
+
+Is there a more complete explanation of this somewhere?  The cookbook is
+rather short on details.
+
+Assuming that this means the daemon sends SIGSTOP to itself when it's
+ready to accept connections, I find this completely counter-intuitive and
+exceedingly strange.  Wouldn't this cause the daemon, if run outside of
+upstart, to do nothing in an extremely confusing fashion?  I assume
+upstart is using waitpid to wait for the child to be stopped and is
+sending SIGCONT, and if you run the daemon outside of that environment, it
+would just stop itself and never start again.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 01:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 01:54:04 GMT) (full text, mbox, link).

+ +

Message #1129 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian
+
Date: Wed, 18 Dec 2013 17:51:05 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Colin Watson writes ("Re: Bug#727708: upstart proposed policy in Debian"):
+
+>> and it requires no particularly exciting code in the init daemon since
+>> finding out about SIGSTOP already basically comes with the territory of
+>> being pid 1.
+
+> It comes with being the daemon's parent, even - the special powers of
+> pid 1 aren't even needed.
+
+I'm not sure that I understand.  This is in the context of handling
+daemons that fork and background themselves, is not it?  If so, no normal
+parent would be able to detect that this has happened because the process
+would have already been reparented by init before the SIGSTOP signal is
+sent.  So it does rely on the special properties of PID 1, namely its
+adoption of all processes that have abandoned their parent process.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 02:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 02:12:05 GMT) (full text, mbox, link).

+ +

Message #1134 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: upstart proposed policy in Debian
+
Date: Thu, 19 Dec 2013 02:08:54 +0000
+
+
On Wed, Dec 18, 2013 at 05:42:11PM -0800, Russ Allbery wrote:
+> Colin Watson <cjwatson@debian.org> writes:
+> > For cases where simply running the daemon in the foreground is
+> > insufficient (i.e. it's important to know more accurately about service
+> > readiness), I personally prefer "expect stop".  While raising SIGSTOP
+> > when they're ready isn't generally something daemons already support, it
+> > also normally has no other conflicting meaning.
+> 
+> Is there a more complete explanation of this somewhere?  The cookbook is
+> rather short on details.
+
+init(5) says much the same thing, with the addition of this sentence:
+
+  "init(8) will send the process the SIGCONT signal to allow it to
+  continue."
+
+> Assuming that this means the daemon sends SIGSTOP to itself when it's
+> ready to accept connections, I find this completely counter-intuitive and
+> exceedingly strange.
+
+It makes a lot of sense to me; it's a synchronisation point.  Though it
+would be better if it didn't involve the daemon stopping briefly; I'd
+also be fine with a better protocol along similar lines, but at least
+this has an appealing minimum of setup.  Lennart was talking at DebConf
+about doing something similar in principle with IIRC a well-known
+socket.  There are trade-offs here in terms of how much extra code you
+want to patch into daemons, and whether you think it's reasonable to
+make them link to additional libraries (I would prefer not).
+
+> Wouldn't this cause the daemon, if run outside of upstart, to do
+> nothing in an extremely confusing fashion?  I assume upstart is using
+> waitpid to wait for the child to be stopped and is sending SIGCONT,
+> and if you run the daemon outside of that environment, it would just
+> stop itself and never start again.
+
+That would indeed be confusing if it happened, but you wouldn't do the
+SIGSTOP thing if not running in an environment supporting this protocol,
+so I don't think this confusion should arise.  For a practical
+implementation, see the Debian openssh package, in particular:
+
+  http://patch-tracker.debian.org/patch/series/view/openssh/1:6.4p1-1/sigstop.patch
+
+(This just does the quick and easy thing of keying off an environment
+variable; when I implemented this in openssh, I opted for that over
+looking for some Upstart-specific property because this is trivial to
+port to any other hypothetical init daemon supporting the same thing,
+and it means that it is also tied to an appropriate job configuration,
+not just a suitable init daemon.)
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 02:18:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 02:18:05 GMT) (full text, mbox, link).

+ +

Message #1139 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Thu, 19 Dec 2013 02:15:11 +0000
+
+
Russ Allbery writes ("Bug#727708: upstart proposed policy in Debian"):
+> Is there a more complete explanation of this somewhere?  The cookbook is
+> rather short on details.
+
+It's documented in upstart's init(5) under "expect stop".
+
+http://manpages.debian.net/cgi-bin/man.cgi?query=init&sektion=5&apropos=0&manpath=Debian+testing+jessie&locale=
+
+> Assuming that this means the daemon sends SIGSTOP to itself when it's
+> ready to accept connections, I find this completely counter-intuitive and
+> exceedingly strange.  Wouldn't this cause the daemon, if run outside of
+> upstart, to do nothing in an extremely confusing fashion?  I assume
+> upstart is using waitpid to wait for the child to be stopped and is
+> sending SIGCONT, and if you run the daemon outside of that environment, it
+> would just stop itself and never start again.
+
+The daemon only does this if you tell it to, typically with a command
+line option.  If you were to run it with that option from the shell,
+your shell would report that the daemon had stopped much as if you had
+^Z'd it (although ^Z generates SIGTSTP).
+
+Russ Allbery writes ("Bug#727708: upstart proposed policy in Debian"):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > It comes with being the daemon's parent, even - the special powers of
+> > pid 1 aren't even needed.
+> 
+> I'm not sure that I understand.  This is in the context of handling
+> daemons that fork and background themselves, is not it?
+
+No.  It's in the context of daemons which are written (well, have been
+modified) _not_ to fork.  They just run as children of the supervisor.
+It's a way for a daemon to signal that it is ready.
+
+Running daemons directly as children of the supervisor is not a new
+idea: inetd does it for network servers (although it gets the logging
+wrong) and Dan Bernstein's daemontools work this way too.
+
+systemd supports the non-forking daemon too.  Only, instead of
+raise(SIGSTOP) the daemon has to fetch an AF_UNIX socket name from an
+environment variable, connect to it, and send a special message with
+socket credentials attached.
+
+>  If so, no normal parent would be able to detect that this has
+> happened because the process would have already been reparented by
+> init before the SIGSTOP signal is sent.  So it does rely on the
+> special properties of PID 1, namely its adoption of all processes
+> that have abandoned their parent process.
+
+The SIGSTOP protocol is an alternative to the traditional daemon(3)
+call.  daemon(3) is IMO at the root of the problem with sysvinit.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 03:03:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 03:03:05 GMT) (full text, mbox, link).

+ +

Message #1144 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: Quick upstart and systemd feature comparison
+
Date: Wed, 18 Dec 2013 18:59:50 -0800
+
+
I took a fairly quick look at the features provided by upstart and systemd
+for starting and managing daemons, since that's the part that I feel the
+most qualified to evaluate.  I've been trying out different methods for
+doing that for about 15 years and run a bunch of production systems with a
+variety of different daemons, so I have strong opinions about what
+features I want.
+
+The short version is that both upstart and systemd directly support most
+of the things that are annoying or repetitive to handle with init scripts.
+Both of them strike me as sufficient.  systemd has some specific features
+that upstart appears not to have that I would immediately use in my day
+job if I had them available.
+
+I had difficulty finding equivalent documentation for OpenRC so that I
+could check its feature list against the things I've needed, but I see
+that Ian already asked about that, so I will read whatever documentation
+he's pointed to.
+
+Features both upstart and systemd have over sysvinit that I would
+immediately start using at work:
+
+* Process monitoring and automatic restarting
+* Setting process user and group
+* Setting process priority
+* Linux OOM killer score adjustment
+* Process limits (I would use file descriptors, primarily)
+* Multiple instances of a given service
+
+The last feature is extremely nice and would replace a lot of nasty and
+difficult-to-maintain code both at my day job (to run multiple copies of
+Apache, for example) and in Debian (consider the Tomcat init script).  I
+think the upstart implementation of this is cleaner and easier to
+understand, and the systemd implementation is kind of weird, but it looks
+like the functionality is equivalent.
+
+Features that systemd provides that I didn't see in upstart (please
+correct me if I'm wrong):
+
+* StandardError=syslog.  This would be *so nice* for *so many things*.
+  Particularly for running Java applications, which are very bad about not
+  sending everything to syslog even when one tries to write them to do so.
+  I would start using this immediately.  There are various external
+  programs that can do this, but with sysvinit you have to set up the
+  pipelines yourself and worry about the programs dying, whereas systemd
+  takes care of all of that.
+
+* Lots of really interesting defense-in-depth security features.  I
+  particularly liked ReadWriteDirectories, ReadOnlyDirectories,
+  InaccessibleDirectories, PrivateNetwork, and NoNewPrivileges, which
+  provide a sort of lightweight process containment that would be much
+  easier to use than a full-blown chroot, and in some ways more powerful.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 03:09:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 03:09:05 GMT) (full text, mbox, link).

+ +

Message #1149 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Wed, 18 Dec 2013 19:07:52 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> No.  It's in the context of daemons which are written (well, have been
+> modified) _not_ to fork.  They just run as children of the supervisor.
+> It's a way for a daemon to signal that it is ready.
+
+Oh, I see, I misunderstood the context.  (Although correct me if I'm
+wrong, but it sounded like this also worked for forking daemons.)
+
+> systemd supports the non-forking daemon too.  Only, instead of
+> raise(SIGSTOP) the daemon has to fetch an AF_UNIX socket name from an
+> environment variable, connect to it, and send a special message with
+> socket credentials attached.
+
+I assume this is functionality provided by the libsystemd-daemon library
+if you're willing to have a dependency on it?  (Checks.)  Ah, yes, this is
+one of the things that sd_notify is for.
+
+SIGSTOP is simpler in that no build system changes are required.  I can
+see the appeal.  I do find the use of the signal for that purpose
+profoundly weird, though, and it's rather annoying that you have to add an
+environment variable or command-line option (and hence more complexity).
+The systemd approach adds a shared library dependency but reduces code
+complexity, since you can just make that call unconditionally and not care
+if you're running outside of a systemd environment (where it will just
+quietly do nothing).
+
+sd_notify has a few other rather neat features for daemons that are
+systemd-aware, none of which are horribly important but which I will
+probably now start adding to some stuff since I think they're useful.  The
+watchdog stuff in particular strikes me as similar to socket activation:
+something that requires a lot of upstream cooperation to use well, but
+which could really improve the state of play for daemon management when
+used well.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 03:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 03:15:04 GMT) (full text, mbox, link).

+ +

Message #1154 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Wed, 18 Dec 2013 19:10:08 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> Running daemons directly as children of the supervisor is not a new
+> idea: inetd does it for network servers (although it gets the logging
+> wrong) and Dan Bernstein's daemontools work this way too.
+
+Oh, and I should note that I've been using daemontools since very shortly
+after djb wrote it and continue using it to this day for some things, so
+you definitely don't have to convince me of the merits of non-forking
+daemons.  I'm in complete agreement.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 03:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 03:33:05 GMT) (full text, mbox, link).

+ +

Message #1159 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Colin Watson <cjwatson@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: upstart proposed policy in Debian
+
Date: Wed, 18 Dec 2013 19:28:40 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Thu, Dec 19, 2013 at 01:19:10AM +0000, Colin Watson wrote:
+> On Sat, Dec 14, 2013 at 08:28:25PM +0000, Ian Jackson wrote:
+> > Ian Jackson writes ("upstart proposed policy in Debian"):
+> > > Having read the docs there I have some apparently unanswered questions
+> > > about how the upstart proponents think we would use upstart in Debian.
+
+> > I found policy 9.11.1 which I had unaccountably failed to notice
+> > before.  It answer the question of how to do the transition from
+> > sysvinit to upstart, with a hideous shell rune.  Perhaps the upstart
+> > package could provide a cooked command and then we could all say
+
+> >   if init-is-upstart 2>/dev/null; then exit 1; fi
+
+> > or something.
+
+> There's an init_is_upstart shell function in /lib/lsb/init-functions
+> (which is generally already sourced by SysV init scripts); it amounts to
+> the rune in policy 9.11.1.  I'm not sure why policy hasn't been updated
+> to refer to it, although
+> https://wiki.ubuntu.com/UpstartCompatibleInitScripts does.
+
+Primarily because policy tends to document the more fundamental interfaces,
+not optional libraries.  If we're happy with policy recommending interfaces
+that are only present in /lib/lsb/init-functions, it's an easy change.
+
+It's also been suggested that instead of requiring modification of the init
+scripts at all, this logic should be provided by the upstart package in a
+/lib/lsb/init-functions.d/ fragment that automatically DTRT.  The two
+options here seem to be a question of personal preference; I'm happy for
+upstart to implement this via /lib/lsb/init-functions.d/ if that's seen as
+the preferable approach.  At the time
+https://wiki.ubuntu.com/UpstartCompatibleInitScripts was drafted, I wasn't
+aware that init-functions hooks were supported, so assumed that a central
+implementation would carry a performance penalty for users who weren't
+running upstart and thought that might be impolite.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 07:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 07:33:05 GMT) (full text, mbox, link).

+ +

Message #1164 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>
+
Cc: Sam Hartman <hartmans@debian.org>, 727708@bugs.debian.org, + Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Thu, 19 Dec 2013 09:22:27 +0200
+
+
On Wed, Dec 18, 2013 at 02:44:03PM -0800, Russ Allbery wrote:
+> Adrian Bunk <bunk@stusta.de> writes:
+>...
+> > When not using systemd as pid 1, that risk would be confined to the
+> > parts of systemd Debian would be using (currently only udev).
+> 
+> There appears to be near-unanimous agreement that Debian will also be
+> using logind in the near future.
+> 
+> I think "only" in this context is misleading, given that the components
+> we're going to be using anyway (including kdbus in this; if it's included
+> in the kernel, I highly doubt Debian will refuse to use it in the long
+> run) are pretty much the same components that people are concerned about
+> being unstable.
+
+I expect Debian to use kdbus in the long run if it gets accepted into 
+the upstream kernel in any case. Note that this does not imply that
+Debian has to switch to systemd.
+
+Ubuntu is also using udev and logind without using systemd, so they are 
+and will continue to be available stand-alone.
+
+And having them standalone and not as part of the big systemd bundle 
+makes it much easier to ship an older version of udev and/or logind
+in a release if that avoids upgrade headaches.
+
+
+> Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 07:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 07:45:04 GMT) (full text, mbox, link).

+ +

Message #1169 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Thu, 19 Dec 2013 08:40:52 +0100
+
+
]] Ian Jackson 
+
+> systemd supports the non-forking daemon too.  Only, instead of
+> raise(SIGSTOP) the daemon has to fetch an AF_UNIX socket name from an
+> environment variable, connect to it, and send a special message with
+> socket credentials attached.
+
+Note that this is only if you need socket activation or a
+synchronisation point.  If you don't have other services depending on
+the service in question, just omit Type from the systemd unit and it'll
+default to simple (aka «run in the foreground»).
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 07:45:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 07:45:08 GMT) (full text, mbox, link).

+ +

Message #1174 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org, Ansgar Burchardt <ansgar@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Thu, 19 Dec 2013 09:43:05 +0200
+
+
On Wed, Dec 18, 2013 at 02:53:39PM -0800, Russ Allbery wrote:
+> Adrian Bunk <bunk@stusta.de> writes:
+> 
+> > [1] Personally, I am sceptical whether it is a good idea to switch to a
+> >     different init system for jessie. But I am not on a desperate rant 
+> >     against systemd, and if something I bring up can be addressed that
+> >     is positive for me.
+> 
+> Just to give fair warning: right now, based on what I know today, there is
+> basically zero chance that I personally will vote retaining sysvinit for
+> jessie above further discussion.  So if you want to convince at least this
+> one member of the technical committee that this is a viable option, you
+> have quite a bit of work to do.
+
+Where would "further discussion in 1-2 years" rank for you?
+
+What I suggested earlier in this discussion was not that you vote for
+keeping sysvinit forever, but:
+  * jessie will continue to use sysvinit, and the TC will re-evaluate
+    the situation after the release of jessie
+
+
+As time passes, the kernel<->systemd interface will become more
+stable since new features systemd wants like kdbus will already
+be in the kernel, reducing potential upgrade problems.
+
+It will also become more clear how exactly systemd is evolving and what 
+exactly the consequences are for Debian in areas where Debian differs
+from other distributions. 
+
+
+And in my opinion the worst case would be that Debian switches init 
+systems in jessie and then again in jessie+1.
+
+OpenRC looks too WIP and with an unclear future for me for switching
+to it for jessie.
+
+Upstart is mature, but I would be cautious since Canonical might decide 
+at some point in the future that systemd is better and abandon upstart.
+I am not seeing a big probability of that happening, but it is a risk.
+
+
+If you are convinced that any of systemd/OpenRC/upstart is the best 
+option for Debian then vote for it, but no matter where you vote
+"further discussion" it is unlikely that there will be significant
+new arguments in the immediate future - and it would therefore be
+better to wait 1-2 years until the further discussion happens.
+
+
+> Right now, it appears to me that the feature set is wholly inadequate,
+> further substantial development is highly unlikely, the configuration
+> syntax is familiar but awful, and we are already seeing software in the
+> archive that requires capabilities that it's just not able to support.
+> 
+> To support continuing to use sysvinit, I think I would need to see a
+> credible plan for significant upstream development and support of the
+> software, including, at a minimum, how the features that are required by
+> our desktop environments would be handled, how device management and
+> dependencies will be managed given the event-driven kernel, and how proper
+> daemon management at least at the level common to upstart, systemd, and
+> OpenRC will be added.
+
+When staying with sysvinit is only the stopgap solution for jessie, then 
+significant upstream development would not even bring any advantages.
+
+
+> Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 11:24:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 11:24:14 GMT) (full text, mbox, link).

+ +

Message #1179 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Quick upstart and systemd feature comparison
+
Date: Thu, 19 Dec 2013 11:13:16 +0000
+
+
Russ Allbery writes ("Bug#727708: Quick upstart and systemd feature comparison"):
+> * StandardError=syslog.  This would be *so nice* for *so many things*.
+>   Particularly for running Java applications, which are very bad about not
+>   sending everything to syslog even when one tries to write them to do so.
+>   I would start using this immediately.  There are various external
+>   programs that can do this, but with sysvinit you have to set up the
+>   pipelines yourself and worry about the programs dying, whereas systemd
+>   takes care of all of that.
+
+From the documentation, upstart's default is to log your program's
+stderr to a file in /var/log/upstart/.  I agree that diverting this to
+syslog would be a useful feature.
+
+> * Lots of really interesting defense-in-depth security features.  I
+>   particularly liked ReadWriteDirectories, ReadOnlyDirectories,
+>   InaccessibleDirectories, PrivateNetwork, and NoNewPrivileges, which
+>   provide a sort of lightweight process containment that would be much
+>   easier to use than a full-blown chroot, and in some ways more powerful.
+
+I think that this functionality should be provided by "auxiliary verb"
+wrapper commands, not welded into init.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 11:24:18 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 11:24:18 GMT) (full text, mbox, link).

+ +

Message #1184 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve Langasek <vorlon@debian.org>, + 727708@bugs.debian.org
+
Cc: Colin Watson <cjwatson@debian.org>
+
Subject: Re: Bug#727708: upstart proposed policy in Debian
+
Date: Thu, 19 Dec 2013 11:15:24 +0000
+
+
Steve Langasek writes ("Bug#727708: upstart proposed policy in Debian"):
+> It's also been suggested that instead of requiring modification of the init
+> scripts at all, this logic should be provided by the upstart package in a
+> /lib/lsb/init-functions.d/ fragment that automatically DTRT.
+
+If I want to source the lsb init functions, do I have to declare a new
+dependency on the lsb package, or are they always available ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 11:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 11:42:04 GMT) (full text, mbox, link).

+ +

Message #1189 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian
+
Date: Thu, 19 Dec 2013 11:38:00 +0000
+
+
On Thu, Dec 19, 2013 at 11:15:24AM +0000, Ian Jackson wrote:
+> Steve Langasek writes ("Bug#727708: upstart proposed policy in Debian"):
+> > It's also been suggested that instead of requiring modification of the init
+> > scripts at all, this logic should be provided by the upstart package in a
+> > /lib/lsb/init-functions.d/ fragment that automatically DTRT.
+> 
+> If I want to source the lsb init functions, do I have to declare a new
+> dependency on the lsb package, or are they always available ?
+
+It requires a dependency on lsb-base.  (In practice most init scripts in
+Debian have been depending on this for some time for pretty logging
+anyway, so for them it's just a version bump.)
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 12:03:04 GMT) (full text, mbox, link).

+ +

Message #1192 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Quick upstart and systemd feature comparison
+
Date: Thu, 19 Dec 2013 13:00:38 +0100
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Russ Allbery writes ("Bug#727708: Quick upstart and systemd feature comparison"):
+>> * Lots of really interesting defense-in-depth security features.  I
+>>   particularly liked ReadWriteDirectories, ReadOnlyDirectories,
+>>   InaccessibleDirectories, PrivateNetwork, and NoNewPrivileges, which
+>>   provide a sort of lightweight process containment that would be much
+>>   easier to use than a full-blown chroot, and in some ways more powerful.
+>
+> I think that this functionality should be provided by "auxiliary verb"
+> wrapper commands, not welded into init.
+
+That has a number of problems:
+
+ * Init can no longer switch to non-root as most of these features need
+   higher privileges to setup. One would lose the User= and Group=
+   settings.
+ * We would be back at writing shell scripts for configuration:
+   no-new-privileges private-network read-only-directory /etc -- some-daemon
+ * One would have to change all options at once as there is just one
+   command line to change. There is no way to say "just disable (enable)
+   <x>" as one has with overriding specific entries from a .service file.
+ * The order of invocations of the wrapper commands might matter and
+   break things if done wrong. Not having to worry about this as init
+   takes care of it removes one source of errors.
+
+So I think having these features integrated into init rather than
+wrapper commands is preferable.
+
+Ansgar
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 17:27:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 17:27:10 GMT) (full text, mbox, link).

+ +

Message #1197 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>, Ansgar Burchardt <ansgar@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Thu, 19 Dec 2013 09:24:54 -0800
+
+
On Thu, Dec 19, 2013 at 09:43:05AM +0200, Adrian Bunk wrote:
+> On Wed, Dec 18, 2013 at 02:53:39PM -0800, Russ Allbery wrote:
+> > Adrian Bunk <bunk@stusta.de> writes:
+
+> > > [1] Personally, I am sceptical whether it is a good idea to switch to a
+> > >     different init system for jessie. But I am not on a desperate rant 
+> > >     against systemd, and if something I bring up can be addressed that
+> > >     is positive for me.
+
+> > Just to give fair warning: right now, based on what I know today, there is
+> > basically zero chance that I personally will vote retaining sysvinit for
+> > jessie above further discussion.  So if you want to convince at least this
+> > one member of the technical committee that this is a viable option, you
+> > have quite a bit of work to do.
+
+> Where would "further discussion in 1-2 years" rank for you?
+
+> What I suggested earlier in this discussion was not that you vote for
+> keeping sysvinit forever, but:
+>   * jessie will continue to use sysvinit, and the TC will re-evaluate
+>     the situation after the release of jessie
+
+This is equivalent to "let others outside of Debian decide our course for
+us".  The Linux ecosystem won't stand still waiting for Debian to make a
+decision; if Debian doesn't take a decision this cycle, Upstart will remain
+a "single-distro solution" in the eyes of many, which means systemd will
+retain its "upstream" soapbox and continue to gather contributors.
+
+Russ rightly points out that there is a momentum gap between systemd and
+upstart.  It is not insurmountable, if Debian decides to endorse upstart
+today.  But two years further on, it will be.  If Debian wants to replace
+sysvinit with something modern, and wants a say in what that replacement
+will be, it should decide now.
+
+And if Debian's not going to adopt upstart, then we should adopt systemd
+immediately so that we have a say in its direction between now and jessie,
+instead of waiting until after jessie and finding ourselves with two more
+years of entrenched bugs / design problems to sort out when integrating with
+it.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 17:57:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 17:57:05 GMT) (full text, mbox, link).

+ +

Message #1202 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: Sam Hartman <hartmans@debian.org>, 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Thu, 19 Dec 2013 09:53:01 -0800
+
+
Adrian Bunk <bunk@stusta.de> writes:
+
+> Ubuntu is also using udev and logind without using systemd, so they are
+> and will continue to be available stand-alone.
+
+Ubuntu is maintaining a variety of moderately fragile glue in order to
+make this happen and currently can't upgrade to the current version of
+logind.  This strategy clearly causes some problems for Ubuntu and would
+cause some similar problems for us.  I think everyone agrees that it's
+*possible*, but my point is that it's increased work that we otherwise
+wouldn't have to incur.
+
+> And having them standalone and not as part of the big systemd bundle
+> makes it much easier to ship an older version of udev and/or logind in a
+> release if that avoids upgrade headaches.
+
+This proven false by the way that Debian already handles gcc, many library
+transitions, and multiple other packages where we build different
+components from different versions for backwards-compatibility reasons.
+This is not difficult to handle at the packaging layer if we need to do
+it.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 18:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 18:00:04 GMT) (full text, mbox, link).

+ +

Message #1207 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Quick upstart and systemd feature comparison
+
Date: Thu, 19 Dec 2013 09:57:48 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Russ Allbery writes:
+
+>> * Lots of really interesting defense-in-depth security features.  I
+>>   particularly liked ReadWriteDirectories, ReadOnlyDirectories,
+>>   InaccessibleDirectories, PrivateNetwork, and NoNewPrivileges, which
+>>   provide a sort of lightweight process containment that would be much
+>>   easier to use than a full-blown chroot, and in some ways more powerful.
+
+> I think that this functionality should be provided by "auxiliary verb"
+> wrapper commands, not welded into init.
+
+Why?  It feels like it adds (mild) complexity without a whole lot of
+benefit.  The init system (for both systemd and upstart) are already
+handling setuid, setgid, nice, OOM adjustment, system resource limits,
+etc.  This stuff feels like the same type of thing.
+
+Also, note that systemd also has broad support for SELinux and related MAC
+mechanisms (and upstart has support for apparmor), which use the same type
+of mechanism.  I believe there are some policy challenges in allowing a
+separate process to handle that setup without compromising security.  The
+init system is already running in the correct trusted context to do that
+sort of setup.
+
+(I'm very interested in the SELinux parts as well, but probably won't be
+able to use them immediately, so I didn't analyze them in much depth.)
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 19:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 19:00:05 GMT) (full text, mbox, link).

+ +

Message #1212 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Quick upstart and systemd feature comparison
+
Date: Thu, 19 Dec 2013 10:57:13 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Thu, Dec 19, 2013 at 09:57:48AM -0800, Russ Allbery wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > Russ Allbery writes:
+
+> >> * Lots of really interesting defense-in-depth security features.  I
+> >>   particularly liked ReadWriteDirectories, ReadOnlyDirectories,
+> >>   InaccessibleDirectories, PrivateNetwork, and NoNewPrivileges, which
+> >>   provide a sort of lightweight process containment that would be much
+> >>   easier to use than a full-blown chroot, and in some ways more powerful.
+
+> > I think that this functionality should be provided by "auxiliary verb"
+> > wrapper commands, not welded into init.
+
+> Why?  It feels like it adds (mild) complexity without a whole lot of
+> benefit.  The init system (for both systemd and upstart) are already
+> handling setuid, setgid, nice, OOM adjustment, system resource limits,
+> etc.  This stuff feels like the same type of thing.
+
+> Also, note that systemd also has broad support for SELinux and related MAC
+> mechanisms (and upstart has support for apparmor), which use the same type
+> of mechanism.  I believe there are some policy challenges in allowing a
+> separate process to handle that setup without compromising security.  The
+> init system is already running in the correct trusted context to do that
+> sort of setup.
+
+> (I'm very interested in the SELinux parts as well, but probably won't be
+> able to use them immediately, so I didn't analyze them in much depth.)
+
+Right, I also agree this kind of thing is best implemented directly in the
+init system.  I don't think it's the highest priority for implementing, but
+it would have its uses and the init system is best placed to handle it.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 19:12:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 19:12:09 GMT) (full text, mbox, link).

+ +

Message #1217 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Quick upstart and systemd feature comparison
+
Date: Thu, 19 Dec 2013 19:09:12 +0000
+
+
On Thu, Dec 19, 2013 at 09:57:48AM -0800, Russ Allbery wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > Russ Allbery writes:
+> >> * Lots of really interesting defense-in-depth security features.  I
+> >>   particularly liked ReadWriteDirectories, ReadOnlyDirectories,
+> >>   InaccessibleDirectories, PrivateNetwork, and NoNewPrivileges, which
+> >>   provide a sort of lightweight process containment that would be much
+> >>   easier to use than a full-blown chroot, and in some ways more powerful.
+> 
+> > I think that this functionality should be provided by "auxiliary verb"
+> > wrapper commands, not welded into init.
+> 
+> Why?  It feels like it adds (mild) complexity without a whole lot of
+> benefit.  The init system (for both systemd and upstart) are already
+> handling setuid, setgid, nice, OOM adjustment, system resource limits,
+> etc.  This stuff feels like the same type of thing.
+
+We should have *at least* auxverb-style commands for this, because
+they're often useful outside the context of the init system (for
+example, a private network is useful for building packages; you can do
+this kind of thing with "unshare -n" or with the LXC tools).
+
+It's a fairly narrow judgement call whether this kind of thing should be
+directly supported in the init daemon or not; I can certainly see some
+being useful, although if they're already supported by auxverbs then
+they would presumably be pretty trivial to add to anything that already
+has direct support for things like "nice".
+
+In the case of Upstart's "setuid" and "setgid" verbs, I think part of
+the reasoning was that we had scripts that were doing it by hand in a
+boilerplate fashion but of course it was important that they get it just
+right, and it made sense to consolidate the code.  That seems to me to
+be a reasonable metric for whether this belongs in the init daemon.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 19:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 19:21:04 GMT) (full text, mbox, link).

+ +

Message #1222 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: upstart upstream maintenance practices
+
Date: Thu, 19 Dec 2013 11:19:37 -0800
+
+
Could someone (Steve, most likely) provide a bit of background for how
+upstart upstream maintenance works and relates to its packaging?
+
+This question is prompted by a few different things, set off by looking at
+the SELinux support since this is something I expect to start looking at
+for my day job.  From there, I found that the SELinux context support in
+upstart is somewhat limited, but more interestingly is being maintained as
+a patch in the Debian package.  (But maybe that's because the Debian
+packaging is one version behind?)
+
+I then looked at the Ubuntu patch for upstart and was rather surprised to
+find that it's quite large (although a lot of that is regeneration of the
+Autotools files -- can I recommend dh-autoreconf?).  There appear to be
+substantive code changes in Ubuntu's packaging of upstart that aren't
+upstream, which surprised me.
+
+How does this all work?  How do changes flow from Debian and Ubuntu
+packaging into upstream, and why would the packaging be carrying
+substantial local patches for software that's maintained upstream by (at
+least as I understand it) the same project?  Is there a separate policy
+about what goes into upstream that precludes things that aren't considered
+fully baked?
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 20:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 20:39:04 GMT) (full text, mbox, link).

+ +

Message #1227 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: Adrian Bunk <bunk@stusta.de>, Sam Hartman <hartmans@debian.org>, + Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Thu, 19 Dec 2013 12:35:38 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Thu, Dec 19, 2013 at 09:53:01AM -0800, Russ Allbery wrote:
+> Adrian Bunk <bunk@stusta.de> writes:
+
+> > Ubuntu is also using udev and logind without using systemd, so they are
+> > and will continue to be available stand-alone.
+
+> Ubuntu is maintaining a variety of moderately fragile glue in order to
+> make this happen and currently can't upgrade to the current version of
+> logind.
+
+The reasons for not upgrading to the current version of logind aren't to do
+with any fragility of the existing glue code (the systemd-shim package), but
+because logind 205 has a new dependency on systemd as cgroup manager, which
+is architecturally incompatible with other consumers of cgroups in the
+ecosystem.  This needs to be resolved before logind v205 can reasonably be
+adopted, because it's broken by design and needs to be worked around.
+
+> This strategy clearly causes some problems for Ubuntu and would cause some
+> similar problems for us.  I think everyone agrees that it's
+> *possible*, but my point is that it's increased work that we otherwise
+> wouldn't have to incur.
+
+I wouldn't call this a problem, so much as the cost of integrating an OS.
+systemd-shim weighs in at < 2kloc of C code, and is relatively stable.  An
+out-of-pid-1 cgroup manager will bring more code to the table, but only that
+which is necessary to support systemd-incompatible uses of cgroups.
+systemd-shim will need extended to bridge between cgmanager and logind.
+
+Yes, there's code here that wouldn't need to be written if we all just
+adopted systemd.  But the hidden assumption there is that systemd adequately
+addresses all the use cases we care about.  When you want to support
+something that upstream doesn't want to support, you get to write code.
+
+It seems to me that most of this code would have to be written to support
+logind on non-Linux anyway, and is a much better choice than supporting
+consolekit indefinitely for those ports.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 19 Dec 2013 22:27:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 19 Dec 2013 22:27:09 GMT) (full text, mbox, link).

+ +

Message #1232 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Thu, 19 Dec 2013 23:26:19 +0100
+
+
Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit :
+> The reasons for not upgrading to the current version of logind aren't to do
+> with any fragility of the existing glue code (the systemd-shim package), but
+> because logind 205 has a new dependency on systemd as cgroup manager, which
+> is architecturally incompatible with other consumers of cgroups in the
+> ecosystem.  This needs to be resolved before logind v205 can reasonably be
+> adopted, because it's broken by design and needs to be worked around.
+
+The new logind is not “broken by design”. Using the cgroups tree is the
+most correct and secure way to identify which processes are permitted to
+access specific devices or services. You might disagree with the idea of
+a single cgroups manager or prefer a less secure mechanism in order to
+handle corner cases (that have yet to be described), but that doesn’t
+make the design less correct.
+
+-- 
+.''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 15:51:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 15:51:09 GMT) (full text, mbox, link).

+ +

Message #1237 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart upstream maintenance practices
+
Date: Thu, 19 Dec 2013 13:49:31 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Hi Russ,
+
+On Thu, Dec 19, 2013 at 11:19:37AM -0800, Russ Allbery wrote:
+> Could someone (Steve, most likely) provide a bit of background for how
+> upstart upstream maintenance works and relates to its packaging?
+
+> This question is prompted by a few different things, set off by looking at
+> the SELinux support since this is something I expect to start looking at
+> for my day job.  From there, I found that the SELinux context support in
+> upstart is somewhat limited, but more interestingly is being maintained as
+> a patch in the Debian package.  (But maybe that's because the Debian
+> packaging is one version behind?)
+
+> I then looked at the Ubuntu patch for upstart and was rather surprised to
+> find that it's quite large (although a lot of that is regeneration of the
+> Autotools files -- can I recommend dh-autoreconf?).  There appear to be
+> substantive code changes in Ubuntu's packaging of upstart that aren't
+> upstream, which surprised me.
+
+> How does this all work?  How do changes flow from Debian and Ubuntu
+> packaging into upstream, and why would the packaging be carrying
+> substantial local patches for software that's maintained upstream by (at
+> least as I understand it) the same project?  Is there a separate policy
+> about what goes into upstream that precludes things that aren't considered
+> fully baked?
+
+I'm attaching the full delta against upstream currently in the Ubuntu
+packaging VCS branch, for reference.  FWIW, I'm not sure which version you
+were looking at, but the current version of the Ubuntu package
+(1.11-0ubuntu1) does not include any delta against autogenerated autotools
+files (and does use dh-autoreconf).  Also FWIW, the attached patch includes
+changes not yet released to Ubuntu (actually, just an update to sync the
+packaging with the version in Debian).
+
+The attached delta is generated from:
+
+  bzr diff -pa/:b/ -r tag:upstream-1.11 lp:ubuntu/upstart | filterdiff -x '**/debian/**'
+
+plus a bit of postprocessing.
+
+I've dissected the current delta and provided an explanation below for each
+bit, but the short answer to your question is yes: there are different
+policies for upstream vs. the Ubuntu package.  Although efforts are made to
+keep the distro delta as small as possible, changes are sometimes applied to
+the package before they're in a state that they can be included in upstream
+in the interest of expediency.
+
+As for Upstart and Ubuntu being maintained "by the same project": if Upstart
+were intended to be "Ubuntu's init system", it would be reasonable to do all
+of the maintenance on a single upstream branch.  But it was never intended
+to be Ubuntu's init system, but rather "the init system", and as there are
+other downstreams besides Ubuntu, care is taken to not embed Ubuntu-specific
+policy upstream.
+
+So while there is some delta between Ubuntu and upstream right now, the
+delta between Debian and Ubuntu packages has been the greater focus of
+attention and has posed the greater maintenance challenge while trying to
+converge Ubuntu's packaging (which made reasonable assumptions of
+Upstart-everywhere) with Debian's (which did not).
+
+
+Now for the current delta, the changes here consist of a few different
+things:
+
+ - Changes to core jobs for integration with Debian/Ubuntu.  E.g.,
+   conf/rc-sysinit.conf is changed to refer to 'filesystem' and
+   'static-network-up' events that are provided by components external to
+   upstart (mountall and ifupdown respectively).  They are deemed
+   inappropriate for upstream, because upstream upstart shouldn't have
+   dependencies on distro-specific implementations.  Likewise, conf/rc.conf
+   has 'emits' lines added for documentation, which are only true when using
+   a version of initscripts that includes upstart integration.
+ - References to the Debian/Ubuntu-specific upstart-events(7) manpage, which
+   describes event policy as it exists here.  Not upstreamable for the same
+   reason as the job changes; none of this applies to other users of upstart
+   (e.g.: RHEL6, Chrome OS).
+ - SELinux support.  This was accepted as a distro patch in Debian, but has
+   not been submitted under Canonical's contributor licensing agreement, so
+   at present is not suitable for inclusion upstream per the upstream
+   contribution policy.  We are happy to carry such patches in the
+   Debian/Ubuntu packaging delta where appropriate, though of course would
+   prefer that such changes be mergeable upstream.
+ - A minor build fix for configure.ac, to make the test suite function
+   correctly under make -j.  This is needed on systems with newer automake,
+   and incompatible with systems with older automake, so carried as a distro
+   patch for now.
+ - A patch to disable apparmor in containers and liveCDs.  This patch is
+   from a member of the Ubuntu security team.  I'm not sure why it's not
+   upstreamed, but it's a minor patch and not at the top of my todo list to
+   resolve.
+ - A patch to work around
+   <https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1058356>, which I
+   believe will be dropped after the next Ubuntu LTS release (14.04).
+ - Changes to the default console handling, which were validated for Ubuntu
+   but no one has had a chance to work through yet upstream to confirm
+   whether they should be applied as is.
+ - A hack to import pids of processes started in the initramfs (used for
+   plymouth).  Scott apparently never felt this was good enough for
+   inclusion upstream because it encoded too much policy, and we haven't
+   really revisited because it hasn't been a maintenance burden.
+ - Various fixes to test cases that were failing in Debian builds.  These
+   fixes have been pushed to trunk and will be included in the next upstream
+   release.
+
+Aside: the full upstream delta is 441 lines.  So this message is 25% of the
+size of the delta that it describes. ;)
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[packaging-changes.diff (text/x-diff, attachment)]
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 15:51:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 15:51:12 GMT) (full text, mbox, link).

+ +

Message #1242 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Quick upstart and systemd feature comparison
+
Date: Thu, 19 Dec 2013 16:24:55 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Dec 18, 2013 at 06:59:50PM -0800, Russ Allbery wrote:
+> Features that systemd provides that I didn't see in upstart (please
+> correct me if I'm wrong):
+
+> * StandardError=syslog.  This would be *so nice* for *so many things*.
+>   Particularly for running Java applications, which are very bad about not
+>   sending everything to syslog even when one tries to write them to do so.
+>   I would start using this immediately.  There are various external
+>   programs that can do this, but with sysvinit you have to set up the
+>   pipelines yourself and worry about the programs dying, whereas systemd
+>   takes care of all of that.
+
+It would be a straightforward incremental change on top of the existing
+logging support in Upstart.  I'm not sure it's such a great idea to have
+some logs going to /var/log/upstart and some going via syslog, however; the
+resulting user/admin confusion may outweigh any benefit from supporting
+syslog.
+
+Are you actually looking for syslog per se here, or are you primarily
+interested in logging of stderr generally?  Upstart already does that by
+default, it just logs it to /var/log/upstart instead of to syslog (for
+reasons of avoiding a dependency on on external daemon for debuggability).
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 15:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 15:57:05 GMT) (full text, mbox, link).

+ +

Message #1247 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Fri, 20 Dec 2013 07:53:35 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Thu, Dec 19, 2013 at 11:26:19PM +0100, Josselin Mouette wrote:
+> Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit :
+> > The reasons for not upgrading to the current version of logind aren't to do
+> > with any fragility of the existing glue code (the systemd-shim package), but
+> > because logind 205 has a new dependency on systemd as cgroup manager, which
+> > is architecturally incompatible with other consumers of cgroups in the
+> > ecosystem.  This needs to be resolved before logind v205 can reasonably be
+> > adopted, because it's broken by design and needs to be worked around.
+
+> The new logind is not “broken by design”. Using the cgroups tree is the
+> most correct and secure way to identify which processes are permitted to
+> access specific devices or services. You might disagree with the idea of
+> a single cgroups manager or prefer a less secure mechanism in order to
+> handle corner cases (that have yet to be described), but that doesn’t
+> make the design less correct.
+
+The design which claims this role for systemd-as-pid-1, and which does not
+adequately address use cases of other existing cgroups consumers in the
+ecosystem (lmctfy, lxc) is broken by design.
+
+Having a single cgroup writer in userspace is fine.  Coupling it to systemd
+in this manner is not.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 17:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 17:42:04 GMT) (full text, mbox, link).

+ +

Message #1252 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Fri, 20 Dec 2013 19:39:28 +0200
+
+
On Fri, 2013-12-20 at 07:53 -0800, Steve Langasek wrote:
+> On Thu, Dec 19, 2013 at 11:26:19PM +0100, Josselin Mouette wrote:
+> > Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit :
+> > > ecosystem.  This needs to be resolved before logind v205 can reasonably be
+> > > adopted, because it's broken by design and needs to be worked around.
+> 
+> > The new logind is not “broken by design”. Using the cgroups tree is the
+> > most correct and secure way to identify which processes are permitted to
+> > access specific devices or services. You might disagree with the idea of
+> > a single cgroups manager or prefer a less secure mechanism in order to
+> > handle corner cases (that have yet to be described), but that doesn’t
+> > make the design less correct.
+> 
+> The design which claims this role for systemd-as-pid-1, and which does not
+> adequately address use cases of other existing cgroups consumers in the
+> ecosystem (lmctfy, lxc) is broken by design.
+> 
+> Having a single cgroup writer in userspace is fine.  Coupling it to systemd
+> in this manner is not.
+
+You're still not saying what would actually be broken about this. On one
+hand you say that you don't disagree with "single cgroup writer"[1], but
+on the other hand you talk about "existing cgroups consumers" like lxc.
+You certainly can't expect lxc to be the only cgroup user on the system.
+Thus the old lxc would not work in the new model in any case, and has to
+be modified to use other APIs instead. Given that, what's wrong with
+systemd being the one to provide those APIs? If you want to criticize
+some specifics of the APIs it provides at the moment, that's mostly
+irrelevant to the general design decision in logind to depend on
+systemd.
+
+The arguments for using systemd as the cgroup manager given at
+http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
+are much better than any you've given against it.
+
+
+[1] The plan still seems to be to eventually deprecate direct kernel
+tree read access too, not only write access; Josselin's "cgroups
+manager" is more accurate.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 18:18:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 18:18:14 GMT) (full text, mbox, link).

+ +

Message #1257 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Quick upstart and systemd feature comparison
+
Date: Fri, 20 Dec 2013 10:15:37 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> Are you actually looking for syslog per se here, or are you primarily
+> interested in logging of stderr generally?
+
+I am specifically looking for syslog.  I consider logging to disk files to
+be significantly inferior: I can't use rsyslog to send them to Splunk or
+any other central log server, I have to figure out some special
+incantation to safely rotate them instead of just throwing them into the
+syslog rotation rules, and the date stamp format isn't picked up from the
+general rsyslog configuration.
+
+Our existing Tomcat init scripts already capture Tomcat output in local
+disk files, so upstart currently doesn't add much value there.  Getting
+them into syslog would be quite helpful.
+
+This is a relatively minor thing since one can set up some simple
+pipelines to do this (and you can tell that it's minor in that we've not
+done that work yet), but for something as critical as logging it's nice to
+not have to worry about the other end of the pipeline dying and not
+getting restarted or having log messages lost when it does.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 18:57:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 18:57:08 GMT) (full text, mbox, link).

+ +

Message #1262 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve Langasek <vorlon@debian.org>, + 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: Quick upstart and systemd feature comparison
+
Date: Fri, 20 Dec 2013 18:52:51 +0000
+
+
Steve Langasek writes ("Bug#727708: Quick upstart and systemd feature comparison"):
+> It would be a straightforward incremental change on top of the existing
+> logging support in Upstart.  I'm not sure it's such a great idea to have
+> some logs going to /var/log/upstart and some going via syslog, however; the
+> resulting user/admin confusion may outweigh any benefit from supporting
+> syslog.
+
+Perhaps it would be possible to have a global setting that changes the
+effect of "log console" to use syslog.
+
+> Are you actually looking for syslog per se here, or are you primarily
+> interested in logging of stderr generally?  Upstart already does that by
+> default, it just logs it to /var/log/upstart instead of to syslog (for
+> reasons of avoiding a dependency on on external daemon for debuggability).
+
+Many people are fans of syslog.  I'm sure I don't have to explain why.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 19:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 19:09:04 GMT) (full text, mbox, link).

+ +

Message #1267 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, + Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Quick upstart and systemd feature comparison
+
Date: Fri, 20 Dec 2013 11:06:54 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Dec 20, 2013 at 10:15:37AM -0800, Russ Allbery wrote:
+> > Are you actually looking for syslog per se here, or are you primarily
+> > interested in logging of stderr generally?
+
+> I am specifically looking for syslog.  I consider logging to disk files to
+> be significantly inferior: I can't use rsyslog to send them to Splunk or
+> any other central log server, I have to figure out some special
+> incantation to safely rotate them instead of just throwing them into the
+> syslog rotation rules, and the date stamp format isn't picked up from the
+> general rsyslog configuration.
+
+> Our existing Tomcat init scripts already capture Tomcat output in local
+> disk files, so upstart currently doesn't add much value there.  Getting
+> them into syslog would be quite helpful.
+
+> This is a relatively minor thing since one can set up some simple
+> pipelines to do this (and you can tell that it's minor in that we've not
+> done that work yet), but for something as critical as logging it's nice to
+> not have to worry about the other end of the pipeline dying and not
+> getting restarted or having log messages lost when it does.
+
+Right, those are all pretty much the reasons I would expect for preferring
+rsyslog.  As I said, I just think there's a trade-off between supporting
+this and having confusing complexity exposed to the users.
+
+On Fri, Dec 20, 2013 at 06:52:51PM +0000, Ian Jackson wrote:
+> Steve Langasek writes ("Bug#727708: Quick upstart and systemd feature comparison"):
+> > It would be a straightforward incremental change on top of the existing
+> > logging support in Upstart.  I'm not sure it's such a great idea to have
+> > some logs going to /var/log/upstart and some going via syslog, however; the
+> > resulting user/admin confusion may outweigh any benefit from supporting
+> > syslog.
+
+> Perhaps it would be possible to have a global setting that changes the
+> effect of "log console" to use syslog.
+
+Yes, I think if we were to implement this, this would be the way I'd prefer
+to see it done.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 19:27:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 19:27:09 GMT) (full text, mbox, link).

+ +

Message #1272 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Steve Langasek <vorlon@debian.org>
+
Subject: Re: Bug#727708: Quick upstart and systemd feature comparison
+
Date: Fri, 20 Dec 2013 11:22:25 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Steve Langasek writes:
+
+>> It would be a straightforward incremental change on top of the existing
+>> logging support in Upstart.  I'm not sure it's such a great idea to
+>> have some logs going to /var/log/upstart and some going via syslog,
+>> however; the resulting user/admin confusion may outweigh any benefit
+>> from supporting syslog.
+
+> Perhaps it would be possible to have a global setting that changes the
+> effect of "log console" to use syslog.
+
+Take a look at the systemd support for how to direct the logs.  (It's in
+systemd.exec(5).)  It's quite nice: you can choose whether to log or
+discard stdout and stderr independently, you can set the syslog priority
+and (more importantly) facility, and you can prefix each line of output
+with some identifier.  You can also do a bunch of other stuff with
+standard output and standard error for which I don't have as much
+immediate need, but which looks rather nice, such as sending output to
+both the console and syslog, logging to a tty, logging to a socket, etc.
+
+systemd provides enough facilities to fully replace the daemontools
+logging infrastructure plus some, so you can use it to run daemons that
+were designed to log to standard output and standard error and direct
+those logs to syslog (instead of djb's multilog, which is a nice idea but
+which doesn't play well with central infrastructure).  That means that,
+for small homegrown stuff, you don't have to bother to add explicit syslog
+code and a switch saying whether to use syslog or stdout/stderr; you can
+just handle it all in the unit configuration.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 22:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 22:33:04 GMT) (full text, mbox, link).

+ +

Message #1277 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more + messages]
+
Date: Fri, 20 Dec 2013 23:29:07 +0100
+
+
* Russ Allbery (rra@debian.org) [131219 04:09]:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> > systemd supports the non-forking daemon too.  Only, instead of
+> > raise(SIGSTOP) the daemon has to fetch an AF_UNIX socket name from an
+> > environment variable, connect to it, and send a special message with
+> > socket credentials attached.
+
+> I assume this is functionality provided by the libsystemd-daemon library
+> if you're willing to have a dependency on it?  (Checks.)  Ah, yes, this is
+> one of the things that sd_notify is for.
+
+I don't think this is a conceptual difference, but both inits would be
+able to work either way without changing their basic concepts. So if
+we have strong reasons to prefer one above the other this could also
+mean convincing upstream to implement the second approach. (It also
+could of course mean that there are too many things to adjust.)
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 23:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 23:06:04 GMT) (full text, mbox, link).

+ +

Message #1282 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Andreas Barth <aba@ayous.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Fri, 20 Dec 2013 15:03:25 -0800
+
+
Andreas Barth <aba@ayous.org> writes:
+> * Russ Allbery (rra@debian.org) [131219 04:09]:
+>> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+>>> systemd supports the non-forking daemon too.  Only, instead of
+>>> raise(SIGSTOP) the daemon has to fetch an AF_UNIX socket name from an
+>>> environment variable, connect to it, and send a special message with
+>>> socket credentials attached.
+
+>> I assume this is functionality provided by the libsystemd-daemon
+>> library if you're willing to have a dependency on it?  (Checks.)  Ah,
+>> yes, this is one of the things that sd_notify is for.
+
+> I don't think this is a conceptual difference, but both inits would be
+> able to work either way without changing their basic concepts.  So if we
+> have strong reasons to prefer one above the other this could also mean
+> convincing upstream to implement the second approach. (It also could of
+> course mean that there are too many things to adjust.)
+
+Agreed.
+
+I'd like to see both of them support systemd's method, since it's
+extensible and provides more general functionality.  I think the benefit
+of support for SIGSTOP is marginal; adding sd_notify calls is not that
+much harder and doesn't have the conceptual weirdness of stopping the
+daemon to notify the init system that it's running.
+
+Overall, I think the approach outlined in daemon(3) is more
+forward-looking and thoughtful upstart's more conservative approach, and I
+like the long-term vision.  (Not horribly surprising, since it's an
+evolution of the vision that daemontools represented early on, and which I
+became convinced of some time ago.)  It's going to take a lot of upstream
+work to get there, and a lot of older or abandoned upstreams may not adopt
+it fully, but it provides incremental benefits as more daemons are
+switched over to a simpler and saner model that has clearly-defined and
+well-specified synchronization points.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 23:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 23:21:04 GMT) (full text, mbox, link).

+ +

Message #1287 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart upstream maintenance practices
+
Date: Fri, 20 Dec 2013 15:16:07 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> I'm attaching the full delta against upstream currently in the Ubuntu
+> packaging VCS branch, for reference.  FWIW, I'm not sure which version
+> you were looking at, but the current version of the Ubuntu package
+> (1.11-0ubuntu1) does not include any delta against autogenerated
+> autotools files (and does use dh-autoreconf).  Also FWIW, the attached
+> patch includes changes not yet released to Ubuntu (actually, just an
+> update to sync the packaging with the version in Debian).
+
+Thank you for this!  That was a more thorough answer than I was expecting!
+
+For the record, I pulled the Ubuntu patch from:
+
+    http://patches.ubuntu.com/u/upstart/upstart_1.11-0ubuntu1.patch
+
+linked off of the Debian PTS.  What I hadn't realized is that this patch
+appears to be generated relative to the current version in Debian, which
+is a different upstream release, and that explains the huge delta.  This
+was just a misunderstanding on my part on how the Ubuntu patches shown on
+the PTS are generated (obvious in retrospect).
+
+> I've dissected the current delta and provided an explanation below for
+> each bit, but the short answer to your question is yes: there are
+> different policies for upstream vs. the Ubuntu package.  Although
+> efforts are made to keep the distro delta as small as possible, changes
+> are sometimes applied to the package before they're in a state that they
+> can be included in upstream in the interest of expediency.
+
+Indeed, most of this seems quite reasonable to me and the sort of thing
+that makes sense to carry as a distribution patch, apart from the SELinux
+change (which is stuck on the CLA).
+
+> As for Upstart and Ubuntu being maintained "by the same project": if
+> Upstart were intended to be "Ubuntu's init system", it would be
+> reasonable to do all of the maintenance on a single upstream branch.
+> But it was never intended to be Ubuntu's init system, but rather "the
+> init system", and as there are other downstreams besides Ubuntu, care is
+> taken to not embed Ubuntu-specific policy upstream.
+
+That makes sense.  I take a different approach as upstream for my Debian
+packages and try fairly hard to embed everything into the upstream release
+with necessary conditionals where needed, but that's just a philosophical
+approach and neither approach is inherently superior.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 23:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 23:24:04 GMT) (full text, mbox, link).

+ +

Message #1292 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: Andreas Barth <aba@ayous.org>
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more + messages]
+
Date: Fri, 20 Dec 2013 15:20:14 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Dec 20, 2013 at 03:03:25PM -0800, Russ Allbery wrote:
+> Andreas Barth <aba@ayous.org> writes:
+> > * Russ Allbery (rra@debian.org) [131219 04:09]:
+> >> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> >>> systemd supports the non-forking daemon too.  Only, instead of
+> >>> raise(SIGSTOP) the daemon has to fetch an AF_UNIX socket name from an
+> >>> environment variable, connect to it, and send a special message with
+> >>> socket credentials attached.
+
+> >> I assume this is functionality provided by the libsystemd-daemon
+> >> library if you're willing to have a dependency on it?  (Checks.)  Ah,
+> >> yes, this is one of the things that sd_notify is for.
+
+> > I don't think this is a conceptual difference, but both inits would be
+> > able to work either way without changing their basic concepts.  So if we
+> > have strong reasons to prefer one above the other this could also mean
+> > convincing upstream to implement the second approach. (It also could of
+> > course mean that there are too many things to adjust.)
+
+> Agreed.
+
+> I'd like to see both of them support systemd's method, since it's
+> extensible and provides more general functionality.  I think the benefit
+> of support for SIGSTOP is marginal; adding sd_notify calls is not that
+> much harder and doesn't have the conceptual weirdness of stopping the
+> daemon to notify the init system that it's running.
+
+The one benefit of not using sd_notify() is that it doesn't require
+introducing build-time dependencies or portability concerns; upstreams who
+may not use Linux at all can still validate the correctness of the SIGSTOP
+interface manually, and low barrier to entry for upstream is a good thing.
+
+But as Andi said, there's no real conceptual difference between the two
+approaches, and I don't see anything here that weighs in favor of one
+project over the other.  Do you agree?  If so, perhaps we should table this
+particular thread; we can always discuss the finer points of implementation
+outside the TC decision.
+
+Of course if you disagree, and feel this is a point that's relevant to the
+TC decision, I'd like to understand why.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 23:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 23:30:04 GMT) (full text, mbox, link).

+ +

Message #1297 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Cc: Andreas Barth <aba@ayous.org>
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Fri, 20 Dec 2013 23:27:54 +0000
+
+
Russ Allbery writes ("Bug#727708: upstart proposed policy in Debian [and 1 more messages]"):
+> I'd like to see both of them support systemd's method, since it's
+> extensible and provides more general functionality.  I think the benefit
+> of support for SIGSTOP is marginal; adding sd_notify calls is not that
+> much harder and doesn't have the conceptual weirdness of stopping the
+> daemon to notify the init system that it's running.
+
+I strongly disagreee.
+
+As the upstream author of a daemon I'm
+ - not willing to add a library dependency for this
+ - not willing to write a 50-100 lines of tiresome socket code for this
+ - not willing to copy the library file into my source tree
+so the result is that userv upstream won't support systemd's readiness
+protocol.
+
+Luckily the systemd socket activation is less fiddly than the general
+readiness protcol, so for systemd I am doing that instead.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 23:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 23:33:04 GMT) (full text, mbox, link).

+ +

Message #1302 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve Langasek <vorlon@debian.org>, + 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>, + Andreas Barth <aba@ayous.org>
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Fri, 20 Dec 2013 23:29:12 +0000
+
+
Steve Langasek writes ("Bug#727708: upstart proposed policy in Debian [and 1 more messages]"):
+> Of course if you disagree, and feel this is a point that's relevant to the
+> TC decision, I'd like to understand why.
+
+I think it's relevant to the TC decision.
+
+Also relevant is the response from systemd upstream to the request to
+support this protocol as an option.  I found it unsatisfactory.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 23:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 23:42:04 GMT) (full text, mbox, link).

+ +

Message #1307 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org, Andreas Barth <aba@ayous.org>
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Fri, 20 Dec 2013 15:40:01 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> But as Andi said, there's no real conceptual difference between the two
+> approaches, and I don't see anything here that weighs in favor of one
+> project over the other.  Do you agree?
+
+No -- for me, this is a plus in the systemd column over upstart, and
+likely will have an effect on my vote.
+
+> Of course if you disagree, and feel this is a point that's relevant to
+> the TC decision, I'd like to understand why.
+
+I don't think the upstart synchronization approach has a future.  It's
+basically a hack to work around only the lack of synchronization, and all
+it can deliver is a single bit of data.  The problem is that there may be
+more than a single bit of data that needs to be delivered.  There may be
+multiple synchronization points, there may be more information that the
+daemon wants to tell its management process (the existing status reporting
+interface is an example), and so on.  But there's no way to extend
+SIGSTOP.  The systemd approach, while necessarily requiring a more complex
+communications protocol, is clealy extensible for future needs as they
+arise.
+
+This is consistent with a pattern that I'm seeing when evaluating the core
+init system functionality between systemd and upstart.  upstart takes a
+very conservative approach of only addressing known problems and doing so
+in a fairly limited way.  systemd takes a broader approach of trying to
+understand the general problem and trying to create a way to write daemons
+and other startup code that can be much simpler once systemd interfaces
+are available.
+
+There are pluses and minuses to those approaches, but given that both
+projects are maintaining backward compatibility, and given that I find
+myself generally nodding along with the systemd design decisions, I think
+the systemd approach is more interesting and has more long-term upside
+potential.  upstart as it exists right now would solve a bunch of problems
+for us, but not lay groundwork for solving more problems in the future.
+systemd would both solve an equivalent set of problems and provide a path
+forward towards making the overall system much more robust, and given the
+breadth of the existing systemd deployment, it's likely that our upstreams
+are going to start adding that support.  It's a more appealing picture.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 23:42:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 23:42:08 GMT) (full text, mbox, link).

+ +

Message #1312 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more + messages]
+
Date: Sat, 21 Dec 2013 00:41:06 +0100
+
+
* Ian Jackson (ijackson@chiark.greenend.org.uk) [131221 00:33]:
+> Steve Langasek writes ("Bug#727708: upstart proposed policy in Debian [and 1 more messages]"):
+> > Of course if you disagree, and feel this is a point that's relevant to the
+> > TC decision, I'd like to understand why.
+> 
+> I think it's relevant to the TC decision.
+
+As I think that both protocols have their own advantages (and
+currently I don't think that any is so much better that we have to
+take it) I don't think it is relevant which of the protocols is
+supported right now.
+
+However I think it is relevant if we could get an patch integrated to
+support the other protocol as well (means: not replacing the current
+protocol). Which might be a good thing anyways as both protocols have
+their own merits.
+
+
+> Also relevant is the response from systemd upstream to the request to
+> support this protocol as an option.  I found it unsatisfactory.
+
+You mean #732157 / https://bugzilla.redhat.com/show_bug.cgi?id=833105 ?
+
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 23:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 23:45:04 GMT) (full text, mbox, link).

+ +

Message #1317 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Andreas Barth <aba@ayous.org>
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Fri, 20 Dec 2013 15:41:55 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Russ Allbery writes:
+
+>> I'd like to see both of them support systemd's method, since it's
+>> extensible and provides more general functionality.  I think the
+>> benefit of support for SIGSTOP is marginal; adding sd_notify calls is
+>> not that much harder and doesn't have the conceptual weirdness of
+>> stopping the daemon to notify the init system that it's running.
+
+> I strongly disagreee.
+
+> As the upstream author of a daemon I'm
+>  - not willing to add a library dependency for this
+>  - not willing to write a 50-100 lines of tiresome socket code for this
+>  - not willing to copy the library file into my source tree
+> so the result is that userv upstream won't support systemd's readiness
+> protocol.
+
+Yes, we completely disagree.
+
+Among other things, that's about the smallest and least-impactful library
+dependency I can imagine.  My intent in integrating support for sd_notify
+is to just stub out the call when not built with systemd support, which is
+pretty trivial to do with Autoconf and means that those who want systemd
+integration get it and those who don't care can easily ignore it.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 20 Dec 2013 23:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 20 Dec 2013 23:51:04 GMT) (full text, mbox, link).

+ +

Message #1322 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Andreas Barth <aba@ayous.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Fri, 20 Dec 2013 15:46:38 -0800
+
+
Andreas Barth <aba@ayous.org> writes:
+> * Ian Jackson (ijackson@chiark.greenend.org.uk) [131221 00:33]:
+
+>> Also relevant is the response from systemd upstream to the request to
+>> support this protocol as an option.  I found it unsatisfactory.
+
+> You mean #732157 / https://bugzilla.redhat.com/show_bug.cgi?id=833105 ?
+
+Lennart here manages to put into words several of the things that I
+thought when I first heard about this method and didn't express as well:
+
+    SIGSTOP is a mechanism for stopping processes, not for notifying
+    service readiness. We shouldn't attempt to overload OS functionality
+    like this, as SIGSTOP might happen for it's real purpose too.
+
+    [...]
+
+    Another big problem with raise(SIGSTOP) is that if done on an init
+    system that can't handle it will result in a freeze. OTOH sd_notify()
+    handles this gracefully and just becomes a NOP.
+
+I basically agree with his response here.  If I were him, I probably would
+have added support for it anyway just on the grounds of supporting a
+mechanism that's already widely used in a major Linux distribution, but I
+understand his reluctance and, had I added it, I would have marked it as
+discouraged and documented why.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 21 Dec 2013 00:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 21 Dec 2013 00:27:04 GMT) (full text, mbox, link).

+ +

Message #1327 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Cc: Andreas Barth <aba@ayous.org>
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Fri, 20 Dec 2013 16:22:07 -0800
+
+
Russ Allbery <rra@debian.org> writes:
+
+> Overall, I think the approach outlined in daemon(3) is more
+> forward-looking and thoughtful upstart's more conservative approach, and I
+> like the long-term vision.
+
+Sorry, that should have been daemon(7).
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 21 Dec 2013 01:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 21 Dec 2013 01:42:04 GMT) (full text, mbox, link).

+ +

Message #1332 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Andreas Barth <aba@ayous.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Sat, 21 Dec 2013 01:39:51 +0000
+
+
Andreas Barth writes ("Bug#727708: upstart proposed policy in Debian [and 1 more messages]"):
+> However I think it is relevant if we could get an patch integrated to
+> support the other protocol as well (means: not replacing the current
+> protocol). Which might be a good thing anyways as both protocols have
+> their own merits.
+
+Yes, I agree that this is relevant.
+
+> > Also relevant is the response from systemd upstream to the request to
+> > support this protocol as an option.  I found it unsatisfactory.
+> 
+> You mean #732157 / https://bugzilla.redhat.com/show_bug.cgi?id=833105 ?
+
+Yes.  I agree with the comments from Vincent and Niklaus.  For me,
+Zbigniew's response shows where this approach leads and I don't find
+it attractive.
+
+I found Lennart's comments tendentious and his complaint about an
+admin's potential use of SIGSTOP (during startup) unconvincing (and
+easily resolved by the use of (say) SIGTTOU instead).
+
+I don't see the merit in extensibility; or rather, I think that there
+is room in the world for a non-extensible but trivial protocol.  (And
+there are other potential simple protocols which would be more
+extensible.)
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 21 Dec 2013 03:12:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 21 Dec 2013 03:12:04 GMT) (full text, mbox, link).

+ +

Message #1337 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Fri, 20 Dec 2013 19:09:41 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I don't see the merit in extensibility; or rather, I think that there is
+> room in the world for a non-extensible but trivial protocol.  (And there
+> are other potential simple protocols which would be more extensible.)
+
+Well, the extensibility is already providing another obviously-useful
+feature, namely the watchdog support, which is done over the same channel.
+How do you think that should be implemented in upstart?  It seems like a
+good example of a place where a daemon needs an ongoing communication
+channel with the init system.
+
+And you're never going to convince me that repurposing SIGSTOP to mean go
+is anything other than a hack.  Sorry.  :)  I agree that it's a useful
+hack with low impact when patching upstream source, but it's still exactly
+the sort of repurposing of one thing to mean something entirely unrelated
+that tends to create problems and undermine guarantees that unknown other
+parties might be depending on.  It makes the standards writer in me
+cringe.
+
+I personally have used kill -STOP on daemons started by init before as a
+systems administrator, usually when setting up debugging and sometimes
+when trying to temporarily pause a daemon while I figure out what's going
+on with a load issue without terminating it entirely and losing state.  I
+believe it's also the first step of a gdb attach.  The argument that
+admins may use this for other purposes is not theoretical.  SIGSTOP is
+very useful because it's uncatchable, so you know that daemons with weird
+signal handlers can't make it ineffective.  It always works the same in
+every situation (except, now, with daemons started by upstart).  This is
+not true of SIGTTOU.
+
+Now, that being said, upstart only cares about SIGSTOP when the job hasn't
+yet signaled that it's ready, so this is only an issue if you try to
+attach during the early startup stage.  That's not an entirely impossible
+situation, but less likely and not one of the cases where I've done this
+as an administrator before.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 21 Dec 2013 07:51:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 21 Dec 2013 07:51:11 GMT) (full text, mbox, link).

+ +

Message #1342 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: systemd as cgroup writer (was: Bug#727708: systemd jessie -> + jessie+1 upgrade problems)
+
Date: Sat, 21 Dec 2013 08:48:10 +0100
+
+
* Steve Langasek (vorlon@debian.org) [131220 16:57]:
+> The design which claims this role for systemd-as-pid-1, and which does not
+> adequately address use cases of other existing cgroups consumers in the
+> ecosystem (lmctfy, lxc) is broken by design.
+> 
+> Having a single cgroup writer in userspace is fine.  Coupling it to systemd
+> in this manner is not.
+
+I would like to understand that topic further, so I have two questions
+(to different people):
+
+1. Does systemd (or a part of the systemd project) need to be the
+single cgroup writer and if so, why?
+
+2. What problems do arise from there for other parts of the linux
+ecosystem?
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 21 Dec 2013 12:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 21 Dec 2013 12:24:04 GMT) (full text, mbox, link).

+ +

Message #1347 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Andreas Barth <aba@ayous.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: systemd as cgroup writer
+
Date: Sat, 21 Dec 2013 13:15:36 +0100
+
+
Hi Andreas,
+
+Le samedi 21 décembre 2013 à 08:48 +0100, Andreas Barth a écrit : 
+> 1. Does systemd (or a part of the systemd project) need to be the
+> single cgroup writer and if so, why?
+
+It does not… so far. The only thing currently required is for cgroups
+consumers to adhere to the shared guidelines¹ different projects agreed
+upon. As of today, there is no impact for us.
+
+What is changing is that the kernel cgroups developers want to fix the
+current mess cgroupfs has become². The identified solution is to only
+allow one cgroupfs hierarchy to be mounted and to let it be managed only
+by one process. The future kernel API has not been completely stabilized
+yet, but that much is clear.
+
+If you use systemd, this cgroups arbitrator has to lie in systemd
+itself. This is because systemd already starts all services as part of
+cgroups from PID 1. Otherwise, you can use another arbitrator such as
+cgmanager. Both have chosen the approach to provide the cgroups
+functionality as a D-Bus API to cgroups consumers (which makes a lot of
+sense).
+
+As I understand the transition plan, it goes this way: 
+     1. Migrate cgroups consumers to a D-Bus API instead of using
+        cgroupfs directly. 
+     2. Stabilize the new kernel API and start providing it in the
+        kernel. 
+     3. On a switch day, the cgroups arbitrator starts mounting cgroupfs
+        with the new API. Consumers still accessing the old API stop
+        working. 
+     4. The old kernel API is deprecated and eventually removed in the
+        distant future.
+
+Systemd developers are getting ready to part 3 by working closely with
+the kernel cgroups developers. It is not clear to me whether cgmanager
+will be able to do the same: from my discussions with more knowledgeable
+people, it is merely exposing the current cgroups API in D-Bus calls.
+This approach cannot work transparently when the API changes. Therefore,
+we might only have one available cgroups arbitrator in the end: systemd.
+
+
+ ① http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups/
+ ② http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linux-kernel-cgroup%E2%80%99s-redesign
+
+
+> 2. What problems do arise from there for other parts of the linux
+> ecosystem?
+
+These other parts have to migrate to a D-Bus-based interface. The
+problem is that systemd and cgmanager developers have not been able so
+far to agree on a common API. The consequences for those
+cgroups-consuming services are easy to infer. 
+      * Some services will only support systemd. 
+      * Some will use more complex code in order to support both. 
+      * Some will wait until a “standard” emerges and will not work
+        towards the transition. 
+
+With the systemd API being already available³ and part of the stability
+promise⁴, the only way this can happen is for cgmanager to start
+providing a systemd-compatible API, which in turn is unlikely since
+these are just extensions to the base API controlling systemd itself.
+
+Expect Red Hat, Samsung or Intel to provide patches if one of their
+products includes a relevant package. I think this is already the case
+for libvirt and LXC.
+
+
+ ③ http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
+ ④ http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
+
+
+Cheers,
+-- 
+ .''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 21 Dec 2013 12:57:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 21 Dec 2013 12:57:09 GMT) (full text, mbox, link).

+ +

Message #1352 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Sat, 21 Dec 2013 13:54:44 +0100
+
+
]] Russ Allbery 
+
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > Russ Allbery writes:
+> 
+> >> I'd like to see both of them support systemd's method, since it's
+> >> extensible and provides more general functionality.  I think the
+> >> benefit of support for SIGSTOP is marginal; adding sd_notify calls is
+> >> not that much harder and doesn't have the conceptual weirdness of
+> >> stopping the daemon to notify the init system that it's running.
+> 
+> > I strongly disagreee.
+> 
+> > As the upstream author of a daemon I'm
+> >  - not willing to add a library dependency for this
+> >  - not willing to write a 50-100 lines of tiresome socket code for this
+> >  - not willing to copy the library file into my source tree
+> > so the result is that userv upstream won't support systemd's readiness
+> > protocol.
+>
+> Yes, we completely disagree.
+> 
+> Among other things, that's about the smallest and least-impactful library
+> dependency I can imagine.
+
+sd-daemon.c is also intentionally designed to not have dependencies on
+the rest of the systemd source and to be portable to non-linux
+architectures too (but basically just stubs then) just so people can put
+the file in their source and not have to fiddle with checking for
+libraries and such if they find that tedious.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 21 Dec 2013 16:54:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 21 Dec 2013 16:54:13 GMT) (full text, mbox, link).

+ +

Message #1357 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Tollef Fog Heen <tfheen@err.no>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Sat, 21 Dec 2013 08:49:56 -0800
+
+
Tollef Fog Heen <tfheen@err.no> writes:
+
+> sd-daemon.c is also intentionally designed to not have dependencies on
+> the rest of the systemd source and to be portable to non-linux
+> architectures too (but basically just stubs then) just so people can put
+> the file in their source and not have to fiddle with checking for
+> libraries and such if they find that tedious.
+
+I agree with Ian's dislike of this approach.  We try to avoid embedded
+code copies, and I'm not sure why this would be an exception.  Yes, the
+code is fairly simple and hopefully doesn't contain (for example) security
+vulnerabilities, but it's possible to find bugs in just about anything.
+Updating numerous copies of that code is not appealing.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 21 Dec 2013 20:54:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 21 Dec 2013 20:54:05 GMT) (full text, mbox, link).

+ +

Message #1362 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Sat, 21 Dec 2013 21:51:59 +0100
+
+
]] Russ Allbery 
+
+> Tollef Fog Heen <tfheen@err.no> writes:
+> 
+> > sd-daemon.c is also intentionally designed to not have dependencies on
+> > the rest of the systemd source and to be portable to non-linux
+> > architectures too (but basically just stubs then) just so people can put
+> > the file in their source and not have to fiddle with checking for
+> > libraries and such if they find that tedious.
+> 
+> I agree with Ian's dislike of this approach.  We try to avoid embedded
+> code copies, and I'm not sure why this would be an exception.  Yes, the
+> code is fairly simple and hopefully doesn't contain (for example) security
+> vulnerabilities, but it's possible to find bugs in just about anything.
+
+Sure.  There's a tradeoff as always.  I wanted to point out that
+embedding it is intentionally easy.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 21 Dec 2013 22:00:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 21 Dec 2013 22:00:08 GMT) (full text, mbox, link).

+ +

Message #1367 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more + messages]
+
Date: Sat, 21 Dec 2013 23:56:24 +0200
+
+
On Sat, 2013-12-21 at 08:49 -0800, Russ Allbery wrote:
+> Tollef Fog Heen <tfheen@err.no> writes:
+> > sd-daemon.c is also intentionally designed to not have dependencies on
+> > the rest of the systemd source and to be portable to non-linux
+> > architectures too (but basically just stubs then) just so people can put
+> > the file in their source and not have to fiddle with checking for
+> > libraries and such if they find that tedious.
+> 
+> I agree with Ian's dislike of this approach.  We try to avoid embedded
+> code copies, and I'm not sure why this would be an exception.  Yes, the
+> code is fairly simple and hopefully doesn't contain (for example) security
+> vulnerabilities, but it's possible to find bugs in just about anything.
+> Updating numerous copies of that code is not appealing.
+
+I don't see why that should be considered a particularly significant
+downside though. Copies are usually worse than shared code, but not
+really worse than everything having a custom implementation. At least
+implementing sd_notify() support with a code copy should be considered a
+significant improvement over a daemon that always runs custom
+double-forking code.
+
+BTW it's worth noting that in the typical daemon case where "readiness"
+means the listening socket is ready to accept requests, the right way to
+convert the daemon to a new API is to use socket activation, which
+removes the need for separate start-up completion notification. Thus the
+need to use sd_notify() for this purpose should be the exception rather
+than the rule. This means that daemons which would use libsystemd-daemon
+for startup notification and nothing else (and would thus be potential
+candidates to abuse SIGSTOP) should be rare.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 21 Dec 2013 22:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 21 Dec 2013 22:15:05 GMT) (full text, mbox, link).

+ +

Message #1372 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Sat, 21 Dec 2013 14:11:03 -0800
+
+
Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
+
+> BTW it's worth noting that in the typical daemon case where "readiness"
+> means the listening socket is ready to accept requests, the right way to
+> convert the daemon to a new API is to use socket activation, which
+> removes the need for separate start-up completion notification. Thus the
+> need to use sd_notify() for this purpose should be the exception rather
+> than the rule. This means that daemons which would use libsystemd-daemon
+> for startup notification and nothing else (and would thus be potential
+> candidates to abuse SIGSTOP) should be rare.
+
+Good point.  Anything that's using socket activation probably doesn't
+really need additional synchronization.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 22 Dec 2013 09:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 22 Dec 2013 09:09:04 GMT) (full text, mbox, link).

+ +

Message #1377 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more + messages]
+
Date: Sun, 22 Dec 2013 10:05:09 +0100
+
+
* Tollef Fog Heen (tfheen@err.no) [131221 13:57]:
+> sd-daemon.c is also intentionally designed to not have dependencies on
+> the rest of the systemd source and to be portable to non-linux
+> architectures too (but basically just stubs then) just so people can put
+> the file in their source and not have to fiddle with checking for
+> libraries and such if they find that tedious.
+
+I'm not really happy by suggesting to copy files around. We have done
+that in the past too often, and it ends painful one way or other.
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 22 Dec 2013 19:39:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Daniel Pocock <daniel@pocock.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 22 Dec 2013 19:39:07 GMT) (full text, mbox, link).

+ +

Message #1382 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Daniel Pocock <daniel@pocock.com.au>
+
To: debian-devel@lists.debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: init multiple instances of a daemon
+
Date: Sun, 22 Dec 2013 20:38:07 +0100
+
+
+This email is not so much about the change of init system but just about
+the multiple-instance problem, regardless of which init we use.  It is
+not a huge hassle but it is something that could be handled more smoothly.
+
+Some packages provide a way to start multiple instances in one shot from
+their init script, e.g.
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433660
+which does it in such a way that a single invocation of the init script
+hits all instances (e.g. starting all when you may only want to start one).
+
+This is a situation that may improve by the move to a new init system
+but I believe it can also be improved even if we retain sysvinit for
+some or all platforms.
+
+My own solution usually involves duplicating the init script, e.g
+
+# cp /etc/init.d/some-service /etc/init.d/some-service-instance2
+
+and then hacking some-service-instance2 to use an alternate daemon
+command line, point the daemon to alternate configuration file, PID
+file, etc and finally I do
+
+# update-rc.d some-service-instance2 defaults
+
+This means the admin can restart the instances independently.  However,
+there are still two problems:
+
+a) the additional instances are not restarted automatically by dpkg upgrades
+
+b) depending upon the package, the effort to hack the init script can
+vary and potentially many users waste time duplicating these local hacks
+
+Changing to a new init system probably resolves problem (b) because most
+of the new solutions are based on a very concise manifest that can be
+duplicated easily.  If we stick with sysvinit, however, maybe we need to
+consider standardizing init scripts using a pattern that supports
+multi-instance?  Peter's blog suggests one starting point, for example:
+http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html
+
+Problem (a) would still remain, however, with all the init solutions as
+far as I can tell unless we decide on some mechanism for letting dpkg
+know which copies of the init script (or declarative manifest in systemd
+or upstart language) are associated with each package.  Is that a
+specific topic that has already been discussed elsewhere?
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 22 Dec 2013 20:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 22 Dec 2013 20:06:04 GMT) (full text, mbox, link).

+ +

Message #1387 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Daniel Pocock <daniel@pocock.com.au>
+
Cc: 727708@bugs.debian.org, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: init multiple instances of a daemon
+
Date: Sun, 22 Dec 2013 12:03:42 -0800
+
+
Daniel Pocock <daniel@pocock.com.au> writes:
+
+> This email is not so much about the change of init system but just about
+> the multiple-instance problem, regardless of which init we use.  It is
+> not a huge hassle but it is something that could be handled more
+> smoothly.
+
+> Some packages provide a way to start multiple instances in one shot from
+> their init script, e.g.
+> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433660
+> which does it in such a way that a single invocation of the init script
+> hits all instances (e.g. starting all when you may only want to start one).
+
+This is something that I specifically looked at when evaluating the
+features of upstart and systemd (I haven't been able to find the necessary
+documentation for OpenRC), and I'm happy to report that they both have
+mechanisms for doing this.  upstart calls this "instances" and systemd
+calls this "unit templates".  Both allow you to write a single service
+configuration file that can then be started multiple times with differing
+parameters, creating independent services from the same configuration.
+
+I haven't yet actually done this myself, so I don't have the experience
+required to compare the implementations directly yet.  I'm hoping to get a
+chance to look at it once I finish converting my first service to upstart
+and systemd support.  I have a package now (kstart) that would benefit
+greatly from this for one of its common use cases (running daemons that
+maintain live Kerberos ticket caches from system keytabs).
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 22 Dec 2013 20:15:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Daniel Pocock <daniel@pocock.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 22 Dec 2013 20:15:08 GMT) (full text, mbox, link).

+ +

Message #1392 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Daniel Pocock <daniel@pocock.com.au>
+
To: debian-devel@lists.debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init multiple instances of a daemon
+
Date: Sun, 22 Dec 2013 21:11:41 +0100
+
+
+
+On 22/12/13 21:03, Russ Allbery wrote:
+> Daniel Pocock <daniel@pocock.com.au> writes:
+> 
+>> This email is not so much about the change of init system but just about
+>> the multiple-instance problem, regardless of which init we use.  It is
+>> not a huge hassle but it is something that could be handled more
+>> smoothly.
+> 
+>> Some packages provide a way to start multiple instances in one shot from
+>> their init script, e.g.
+>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433660
+>> which does it in such a way that a single invocation of the init script
+>> hits all instances (e.g. starting all when you may only want to start one).
+> 
+> This is something that I specifically looked at when evaluating the
+> features of upstart and systemd (I haven't been able to find the necessary
+> documentation for OpenRC), and I'm happy to report that they both have
+> mechanisms for doing this.  upstart calls this "instances" and systemd
+> calls this "unit templates".  Both allow you to write a single service
+> configuration file that can then be started multiple times with differing
+> parameters, creating independent services from the same configuration.
+
+Just to clarify: does this mean systemd and upstart can refer to the
+instances collectively or individually as required?  E.g. you can tell
+it restart all instances of httpd (on dpkg upgrade) or just restart one
+specific instance (after a config change)?
+
+Will additional effort be needed so that dpkg or maintainer scripts can
+request the collective restart of all instances, should this be
+documented with a wishlist bug against dpkg perhaps?
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 22 Dec 2013 20:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 22 Dec 2013 20:51:05 GMT) (full text, mbox, link).

+ +

Message #1397 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Daniel Pocock <daniel@pocock.com.au>
+
Cc: 727708@bugs.debian.org, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: init multiple instances of a daemon
+
Date: Sun, 22 Dec 2013 12:48:47 -0800
+
+
Daniel Pocock <daniel@pocock.com.au> writes:
+
+> Just to clarify: does this mean systemd and upstart can refer to the
+> instances collectively or individually as required?  E.g. you can tell
+> it restart all instances of httpd (on dpkg upgrade) or just restart one
+> specific instance (after a config change)?
+
+It looks like both upstart and systemd don't provide direct mechanisms to
+manage all instances.  The upstart cookbook recommends getting a list of
+all active services and extracting the list of instances of a particular
+service from that, and then acting on them in a loop.  systemd's docs (at
+least that I can find) don't have a similar recipe, but systemd has all
+the tools required to do the same thing.
+
+> Will additional effort be needed so that dpkg or maintainer scripts can
+> request the collective restart of all instances,
+
+Yes.
+
+> should this be documented with a wishlist bug against dpkg perhaps?
+
+I would hold off until we decide which init system we're going with, and
+I'm not sure where this belongs.  It may make more sense to put it into
+dh-systemd and/or dh_installinit.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 22 Dec 2013 21:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 22 Dec 2013 21:15:04 GMT) (full text, mbox, link).

+ +

Message #1402 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init multiple instances of a daemon
+
Date: Sun, 22 Dec 2013 22:11:42 +0100
+
+
]] Russ Allbery 
+
+> Daniel Pocock <daniel@pocock.com.au> writes:
+> 
+> > Just to clarify: does this mean systemd and upstart can refer to the
+> > instances collectively or individually as required?  E.g. you can tell
+> > it restart all instances of httpd (on dpkg upgrade) or just restart one
+> > specific instance (after a config change)?
+> 
+> It looks like both upstart and systemd don't provide direct mechanisms to
+> manage all instances.  The upstart cookbook recommends getting a list of
+> all active services and extracting the list of instances of a particular
+> service from that, and then acting on them in a loop.  systemd's docs (at
+> least that I can find) don't have a similar recipe, but systemd has all
+> the tools required to do the same thing.
+
+The ideomatic systemd way seems to be to use a target for it.  Take a
+look at how getty.target works, for instance.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 22 Dec 2013 21:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 22 Dec 2013 21:24:04 GMT) (full text, mbox, link).

+ +

Message #1407 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Tollef Fog Heen <tfheen@err.no>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init multiple instances of a daemon
+
Date: Sun, 22 Dec 2013 13:21:41 -0800
+
+
Tollef Fog Heen <tfheen@err.no> writes:
+> ]] Russ Allbery 
+
+>> It looks like both upstart and systemd don't provide direct mechanisms
+>> to manage all instances.  The upstart cookbook recommends getting a
+>> list of all active services and extracting the list of instances of a
+>> particular service from that, and then acting on them in a loop.
+>> systemd's docs (at least that I can find) don't have a similar recipe,
+>> but systemd has all the tools required to do the same thing.
+
+> The ideomatic systemd way seems to be to use a target for it.  Take a
+> look at how getty.target works, for instance.
+
+What should I be looking at?  I see the target, and that the getty
+template delcares a Before relationship on it, but some quick searches are
+failing me in understanding what that means in terms of functionality.  I
+get how that affects dependencies, in that something that wants to ensure
+getty is set up can just declare a dependency on the getty target, but I'm
+not sure what that means for other functionality.
+
+Does that mean that you can do a systemctl restart getty and have it
+restart all of the services spawned from the getty template?
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 22 Dec 2013 23:39:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 22 Dec 2013 23:39:05 GMT) (full text, mbox, link).

+ +

Message #1412 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: Russ Allbery <rra@debian.org>
+
Cc: Daniel Pocock <daniel@pocock.com.au>, 727708@bugs.debian.org, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: init multiple instances of a daemon
+
Date: Mon, 23 Dec 2013 00:37:24 +0100
+
+
On Sun, Dec 22, 2013 at 12:48:47PM -0800, Russ Allbery wrote:
+> upstart calls this "instances" and systemd calls this "unit
+> templates".
+We too call them instances: an instance is created from a template.
+
+> Daniel Pocock <daniel@pocock.com.au> writes:
+> 
+> > Just to clarify: does this mean systemd and upstart can refer to the
+> > instances collectively or individually as required?  E.g. you can tell
+> > it restart all instances of httpd (on dpkg upgrade) or just restart one
+> > specific instance (after a config change)?
+> 
+> It looks like both upstart and systemd don't provide direct mechanisms to
+> manage all instances.
+That's true (I'm only speaking about systemd). There have been requests for
+such functionality before, but nothing was implemented. But I think we should
+revisit this topic... I recently added globbing to a bunch of systemctl verbs
+for listing stuff (list-units, list-sockets, etc.), and it was actually
+trivial. I felt that allowing globing for verbs that influence state (start,
+stop, enable, disable, ...) was too dangerous. But this should be safe for
+instance units, so I'd like to see 'systemctl stop/status/... server@*.service'
+implemented.
+
+Zbyszek
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 23 Dec 2013 00:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 23 Dec 2013 00:00:05 GMT) (full text, mbox, link).

+ +

Message #1417 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
Cc: Daniel Pocock <daniel@pocock.com.au>, 727708@bugs.debian.org, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: init multiple instances of a daemon
+
Date: Sun, 22 Dec 2013 15:56:04 -0800
+
+
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
+
+> But this should be safe for instance units, so I'd like to see
+> 'systemctl stop/status/... server@*.service' implemented.
+
+That would be very useful for distribution packagers.  If, for example,
+you support a multiple-instance Tomcat configuration (which is quite nice
+to do, since it isolates Java applications that may require different
+override JARs), you want to restart all of them when you upgrade the
+packaged Tomcat.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 23 Dec 2013 07:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 23 Dec 2013 07:48:04 GMT) (full text, mbox, link).

+ +

Message #1422 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init multiple instances of a daemon
+
Date: Mon, 23 Dec 2013 08:28:03 +0100
+
+
]] Russ Allbery 
+
+> Does that mean that you can do a systemctl restart getty and have it
+> restart all of the services spawned from the getty template?
+
+If you want that, add PartOf=foo.target and possibly
+ReloadPropagatedFrom=foo.target in foo@.service
+
+It'd be systemctl restart foo.target, not just foo, I think, though.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 23 Dec 2013 07:48:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrien Clerc <adrien@antipoul.fr>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 23 Dec 2013 07:48:07 GMT) (full text, mbox, link).

+ +

Message #1427 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrien Clerc <adrien@antipoul.fr>
+
To: Zbigniew Jędrzejewski-Szmek + <zbyszek@in.waw.pl>, Russ Allbery <rra@debian.org>
+
Cc: Daniel Pocock <daniel@pocock.com.au>, 727708@bugs.debian.org, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: init multiple instances of a daemon
+
Date: Mon, 23 Dec 2013 08:41:52 +0100
+
+
Le 23/12/2013 00:37, Zbigniew Jędrzejewski-Szmek a écrit :
+>> It looks like both upstart and systemd don't provide direct mechanisms to
+>> manage all instances.
+> That's true (I'm only speaking about systemd). There have been requests for
+> such functionality before, but nothing was implemented. But I think we should
+> revisit this topic... I recently added globbing to a bunch of systemctl verbs
+> for listing stuff (list-units, list-sockets, etc.), and it was actually
+> trivial. I felt that allowing globing for verbs that influence state (start,
+> stop, enable, disable, ...) was too dangerous. But this should be safe for
+> instance units, so I'd like to see 'systemctl stop/status/... server@*.service'
+> implemented.
+>
+> Zbyszek
+>
+This could be controlled via a setting inside the unit file, like 
+AllowGlobControl, default set to false in template unit files.
+
+Adrien
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 23 Dec 2013 08:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Daniel Pocock <daniel@pocock.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 23 Dec 2013 08:15:05 GMT) (full text, mbox, link).

+ +

Message #1432 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Daniel Pocock <daniel@pocock.com.au>
+
To: debian-devel@lists.debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init multiple instances of a daemon
+
Date: Mon, 23 Dec 2013 09:11:56 +0100
+
+
On 23/12/13 08:41, Adrien Clerc wrote:
+> Le 23/12/2013 00:37, Zbigniew Jędrzejewski-Szmek a écrit :
+>>> It looks like both upstart and systemd don't provide direct
+>>> mechanisms to
+>>> manage all instances.
+>> That's true (I'm only speaking about systemd). There have been
+>> requests for
+>> such functionality before, but nothing was implemented. But I think
+>> we should
+>> revisit this topic... I recently added globbing to a bunch of
+>> systemctl verbs
+>> for listing stuff (list-units, list-sockets, etc.), and it was actually
+>> trivial. I felt that allowing globing for verbs that influence state
+>> (start,
+>> stop, enable, disable, ...) was too dangerous. But this should be
+>> safe for
+>> instance units, so I'd like to see 'systemctl stop/status/...
+>> server@*.service'
+>> implemented.
+>>
+>> Zbyszek
+>>
+> This could be controlled via a setting inside the unit file, like
+> AllowGlobControl, default set to false in template unit files.
+>
+
+
+Going back to the SysVinit world for a moment... maybe we could add an
+extra keyword in the LSB data in the init scripts, e.g.
+
+X-Package: apache2
+
+would indicate that an init script is based on the apache2 package and
+should be executed whenever the primary init script from the package is
+executed by the maintainer scripts
+
+When people copy the apache2 init script or make any of their own custom
+init scripts using binaries from the apache2 package, they would have to
+make sure that line is included in their new script
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 26 Dec 2013 00:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 26 Dec 2013 00:39:04 GMT) (full text, mbox, link).

+ +

Message #1437 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: systemd vs. binfmt-support
+
Date: Thu, 26 Dec 2013 00:38:20 +0000
+
+
#716812 asks for binfmt-support to be disabled when systemd is present,
+because systemd-binfmt exists.  The two have a sort of soft conflict;
+I'm sure it's possible to run both, but having two programs configure
+the same kernel facility is bound to be confusing sooner or later, so it
+would certainly be good to come up with a coherent resolution.
+
+As I explain in the bug [1], I think that the facilities provided by
+binfmt-support are objectively superior; and even if they were broadly
+equivalent, I'd still question the utility of converting packages from
+an interface that's been well-established in Debian for over ten years.
+
+What is the systemd maintainers' position on this bug?  I bring it up
+here mainly because it's an interesting example of integration.  Tollef
+said during the committee's last meeting on IRC that he hadn't thought
+much about binfmt before, so perhaps this is just a loose end.
+
+For what it's worth, it doesn't look terribly difficult to make
+binfmt-support also support the path names used by systemd-binfmt, since
+the configuration is essentially a subset of what binfmt-support can
+handle; it would require a bit of thought to do well, of course.  If
+people think it's important (e.g. because upstream packages are starting
+to ship files in the systemd-binfmt paths) then I can certainly look
+into that.  And as I said in the bug I'd be happy to include systemd
+configuration in the same way that I've already included Upstart
+configuration; if I get time over Christmas I may manage to do this
+myself in the VM that Steve provided, as part of gaining practical
+experience with systemd.
+
+[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716812#15
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 26 Dec 2013 16:42:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 26 Dec 2013 16:42:09 GMT) (full text, mbox, link).

+ +

Message #1442 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: systemd-devel@lists.freedesktop.org, + lennart@poettering.net
+
Cc: 727708@bugs.debian.org, + Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
Subject: [PATCH] systemctl: allow globbing in commands which take multiple unit names
+
Date: Thu, 26 Dec 2013 17:39:33 +0100
+
+
As discussed on IRC, here's a patch which takes the simple approach of
+allowing globbing on loaded unit names in various (almost all :)) systemctl
+commands. Comments?
+
+(There were some preperatory patches which I'm not posting here.
+Please fetch from http://kawka.in.waw.pl/git/systemd/commit/16a4169b
+if you need something that'll apply to current git.)
+
+Zbyszek
+
+---
+ man/systemctl.xml         | 108 ++++++++++-----
+ src/core/device.c         |   2 +-
+ src/journal/journalctl.c  |   4 +-
+ src/run/run.c             |   6 +-
+ src/shared/unit-name.c    |  23 ++--
+ src/shared/unit-name.h    |   4 +-
+ src/shared/util.c         |   7 +
+ src/shared/util.h         |   1 +
+ src/systemctl/systemctl.c | 336 +++++++++++++++++++++++++++-------------------
+ src/test/test-unit-name.c |   4 +-
+ src/udev/udev-rules.c     |   2 +-
+ 11 files changed, 304 insertions(+), 193 deletions(-)
+
+diff --git a/man/systemctl.xml b/man/systemctl.xml
+index 7e0216e..13a4444 100644
+--- a/man/systemctl.xml
++++ b/man/systemctl.xml
+@@ -580,15 +580,24 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+         </varlistentry>
+ 
+         <varlistentry>
+-          <term><command>start <replaceable>NAME</replaceable>...</command></term>
++          <term><command>start <replaceable>PATTERN</replaceable>...</command></term>
+ 
+           <listitem>
+             <para>Start (activate) one or more units specified on the
+             command line.</para>
++
++            <para>Note that glob patterns operate on a list of currently
++            loaded units. Units which are not active and are not in a
++            failed state usually are not loaded, and would not be
++            matched by any pattern. In addition, in case of
++            instantiated units, systemd is often unaware of the
++            instance name until the instance has been started. Therefore
++            using glob patterns with <command>start</command>
++            has limited usefulness.</para>
+           </listitem>
+         </varlistentry>
+         <varlistentry>
+-          <term><command>stop <replaceable>NAME</replaceable>...</command></term>
++          <term><command>stop <replaceable>PATTERN</replaceable>...</command></term>
+ 
+           <listitem>
+             <para>Stop (deactivate) one or more units specified on the
+@@ -596,7 +605,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+           </listitem>
+         </varlistentry>
+         <varlistentry>
+-          <term><command>reload <replaceable>NAME</replaceable>...</command></term>
++          <term><command>reload <replaceable>PATTERN</replaceable>...</command></term>
+ 
+           <listitem>
+             <para>Asks all units listed on the command line to reload
+@@ -617,7 +626,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+ 
+         </varlistentry>
+         <varlistentry>
+-          <term><command>restart <replaceable>NAME</replaceable>...</command></term>
++          <term><command>restart <replaceable>PATTERN</replaceable>...</command></term>
+ 
+           <listitem>
+             <para>Restart one or more units specified on the command
+@@ -626,7 +635,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+           </listitem>
+         </varlistentry>
+         <varlistentry>
+-          <term><command>try-restart <replaceable>NAME</replaceable>...</command></term>
++          <term><command>try-restart <replaceable>PATTERN</replaceable>...</command></term>
+ 
+           <listitem>
+             <para>Restart one or more units specified on the command
+@@ -637,7 +646,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+           </listitem>
+         </varlistentry>
+         <varlistentry>
+-          <term><command>reload-or-restart <replaceable>NAME</replaceable>...</command></term>
++          <term><command>reload-or-restart <replaceable>PATTERN</replaceable>...</command></term>
+ 
+           <listitem>
+             <para>Reload one or more units if they support it. If not,
+@@ -646,7 +655,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+           </listitem>
+         </varlistentry>
+         <varlistentry>
+-          <term><command>reload-or-try-restart <replaceable>NAME</replaceable>...</command></term>
++          <term><command>reload-or-try-restart <replaceable>PATTERN</replaceable>...</command></term>
+ 
+           <listitem>
+             <para>Reload one or more units if they support it. If not,
+@@ -676,7 +685,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+           </listitem>
+         </varlistentry>
+         <varlistentry>
+-          <term><command>kill <replaceable>NAME</replaceable>...</command></term>
++          <term><command>kill <replaceable>PATTERN</replaceable>...</command></term>
+ 
+           <listitem>
+             <para>Send a signal to one or more processes of the
+@@ -687,7 +696,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+           </listitem>
+         </varlistentry>
+         <varlistentry>
+-          <term><command>is-active <replaceable>NAME</replaceable>...</command></term>
++          <term><command>is-active <replaceable>PATTERN</replaceable>...</command></term>
+ 
+           <listitem>
+             <para>Check whether any of the specified units are active
+@@ -698,7 +707,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+           </listitem>
+         </varlistentry>
+         <varlistentry>
+-          <term><command>is-failed <replaceable>NAME</replaceable>...</command></term>
++          <term><command>is-failed <replaceable>PATTERN</replaceable>...</command></term>
+ 
+           <listitem>
+             <para>Check whether any of the specified units are in a "failed" state.
+@@ -709,7 +718,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+           </listitem>
+         </varlistentry>
+         <varlistentry>
+-          <term><command>status</command> <optional><replaceable>NAME</replaceable>...|<replaceable>PID</replaceable>...]</optional></term>
++          <term><command>status</command> <optional><replaceable>PATTERN</replaceable>...|<replaceable>PID</replaceable>...]</optional></term>
+ 
+           <listitem>
+             <para>Show terse runtime status information about one or
+@@ -735,7 +744,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+           </listitem>
+         </varlistentry>
+         <varlistentry>
+-          <term><command>show</command> <optional><replaceable>NAME</replaceable>...|<replaceable>JOB</replaceable>...</optional></term>
++          <term><command>show</command> <optional><replaceable>PATTERN</replaceable>...|<replaceable>JOB</replaceable>...</optional></term>
+ 
+           <listitem>
+             <para>Show properties of one or more units, jobs, or the
+@@ -752,7 +761,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+           </listitem>
+         </varlistentry>
+         <varlistentry>
+-          <term><command>cat <replaceable>NAME</replaceable>...</command></term>
++          <term><command>cat <replaceable>PATTERN</replaceable>...</command></term>
+ 
+           <listitem>
+             <para>Show backing files of one or more units. Prints the
+@@ -788,7 +797,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+         </varlistentry>
+ 
+         <varlistentry>
+-          <term><command>help <replaceable>NAME</replaceable>...|<replaceable>PID</replaceable>...</command></term>
++          <term><command>help <replaceable>PATTERN</replaceable>...|<replaceable>PID</replaceable>...</command></term>
+ 
+           <listitem>
+             <para>Show manual pages for one or more units, if
+@@ -798,7 +807,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+         </varlistentry>
+ 
+         <varlistentry>
+-          <term><command>reset-failed [<replaceable>NAME</replaceable>...]</command></term>
++          <term><command>reset-failed [<replaceable>PATTERN</replaceable>...]</command></term>
+ 
+           <listitem>
+             <para>Reset the <literal>failed</literal> state of the
+@@ -1137,7 +1146,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+           </listitem>
+         </varlistentry>
+         <varlistentry>
+-          <term><command>delete <replaceable>NAME</replaceable>...</command></term>
++          <term><command>delete <replaceable>PATTERN</replaceable>...</command></term>
+ 
+           <listitem>
+             <para>Remove a snapshot previously created with
+@@ -1383,23 +1392,55 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+     <refsect2>
+       <title>Parameter Syntax</title>
+ 
+-    <para>For unit commands, the specified
+-    <replaceable>NAME</replaceable> should be the full name of the
+-    unit, or an abbreviated name which is automatically extended with
+-    the <literal>.service</literal> suffix.
+-    <programlisting># systemctl start foo.service</programlisting> is equivalent to:
+-    <programlisting># systemctl start foo</programlisting>
+-    Note that (absolute) paths to device nodes are automatically converted to device unit names, and other (absolute) paths to mount unit names.
+-    <programlisting># systemctl status /dev/sda
+-# systemctl status /home</programlisting> is equivalent to:
+-    <programlisting># systemctl status dev-sda.device
+-# systemctl status home.mount</programlisting></para>
+-
+-    <para>For unit file commands, the
+-    specified <replaceable>NAME</replaceable> should be the full name
+-    of the unit file, or the absolute path to the unit file.
+-    <programlisting># systemctl link /path/to/foo.service</programlisting>
+-    </para>
++      <para>Unit ommands listed above take either a single unit name
++      (designated as <replaceable>NAME</replaceable>), or multiple
++      unit specifications (designated as
++      <replaceable>PATTERN</replaceable>...). In the first case, the
++      unit name with or without a suffix must be given. If the suffix
++      is not specified, systemctl will append a suitable suffix,
++      <literal>.service</literal> by default, and a type-specific
++      suffix in case of commands which operate only on specific unit
++      types. For example,
++      <programlisting># systemctl start sshd</programlisting> and
++      <programlisting># systemctl start sshd.service</programlisting>
++      are equivalent, as are
++      <programlisting># systemctl isolate snapshot-11</programlisting>
++      and
++      <programlisting># systemctl isolate snapshot-11.snapshot</programlisting>
++      Note that (absolute) paths to device nodes are automatically
++      converted to device unit names, and other (absolute) paths to
++      mount unit names.
++      <programlisting># systemctl status /dev/sda
++# systemctl status /home</programlisting>
++      are equivalent to:
++      <programlisting># systemctl status dev-sda.device
++# systemctl status home.mount</programlisting>
++      In the second case, shell-style globs will be matched against
++      currently loaded units, and literal unit names, with or without
++      a suffix, will be treated as in the first case. This means that
++      literal unit names always refer to exactly one unit, but globs
++      may match zero units and this is not considered an error.</para>
++
++      <para>Glob patterns use
++      <citerefentry><refentrytitle>fnmatch</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
++      so normal shell-style globbing rules are used, and
++      <literal>*</literal>, <literal>?</literal>,
++      <literal>[]</literal> may be used. See
++      <citerefentry><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>
++      for more details. The patterns are matched against the names of
++      currently loaded units, and patterns which don't match anything
++      are silently skipped. For example:
++      <programlisting># systemctl stop sshd@*.service</programlisting>
++      will stop all <filename>sshd@.service</filename> instances.
++      </para>
++
++      <para>For unit file commands, the specified
++      <replaceable>NAME</replaceable> should be the full name of the
++      unit file, or the absolute path to the unit file:
++      <programlisting># systemctl enable foo.service</programlisting>
++      or
++      <programlisting># systemctl link /path/to/foo.service</programlisting>
++      </para>
+     </refsect2>
+ 
+   </refsect1>
+@@ -1441,6 +1482,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+       <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+       <citerefentry><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+       <citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>5</manvolnum></citerefentry>
++      <citerefentry><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+     </para>
+   </refsect1>
+ 
+diff --git a/src/core/device.c b/src/core/device.c
+index 2c44dec..d3976c9 100644
+--- a/src/core/device.c
++++ b/src/core/device.c
+@@ -268,7 +268,7 @@ static int device_update_unit(Manager *m, struct udev_device *dev, const char *p
+                                 memcpy(e, w, l);
+                                 e[l] = 0;
+ 
+-                                n = unit_name_mangle(e);
++                                n = unit_name_mangle(e, false);
+                                 if (!n) {
+                                         r = -ENOMEM;
+                                         goto fail;
+diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
+index 122b0e6..fdee9d4 100644
+--- a/src/journal/journalctl.c
++++ b/src/journal/journalctl.c
+@@ -991,7 +991,7 @@ static int add_units(sd_journal *j) {
+         assert(j);
+ 
+         STRV_FOREACH(i, arg_system_units) {
+-                u = unit_name_mangle(*i);
++                u = unit_name_mangle(*i, false);
+                 if (!u)
+                         return log_oom();
+                 r = add_matches_for_unit(j, u);
+@@ -1003,7 +1003,7 @@ static int add_units(sd_journal *j) {
+         }
+ 
+         STRV_FOREACH(i, arg_user_units) {
+-                u = unit_name_mangle(*i);
++                u = unit_name_mangle(*i, false);
+                 if (!u)
+                         return log_oom();
+ 
+diff --git a/src/run/run.c b/src/run/run.c
+index 2e0cd1a..ef2015f 100644
+--- a/src/run/run.c
++++ b/src/run/run.c
+@@ -208,7 +208,7 @@ static int message_start_transient_unit_new(sd_bus *bus, const char *name, sd_bu
+         if (!isempty(arg_slice)) {
+                 _cleanup_free_ char *slice;
+ 
+-                slice = unit_name_mangle_with_suffix(arg_slice, ".slice");
++                slice = unit_name_mangle_with_suffix(arg_slice, false, ".slice");
+                 if (!slice)
+                         return -ENOMEM;
+ 
+@@ -255,7 +255,7 @@ static int start_transient_service(
+         int r;
+ 
+         if (arg_unit)
+-                name = unit_name_mangle_with_suffix(arg_unit, ".service");
++                name = unit_name_mangle_with_suffix(arg_unit, false, ".service");
+         else
+                 asprintf(&name, "run-%lu.service", (unsigned long) getpid());
+         if (!name)
+@@ -342,7 +342,7 @@ static int start_transient_scope(
+         assert(bus);
+ 
+         if (arg_unit)
+-                name = unit_name_mangle_with_suffix(arg_unit, ".scope");
++                name = unit_name_mangle_with_suffix(arg_unit, false, ".scope");
+         else
+                 asprintf(&name, "run-%lu.scope", (unsigned long) getpid());
+         if (!name)
+diff --git a/src/shared/unit-name.c b/src/shared/unit-name.c
+index 178efef..832b9268 100644
+--- a/src/shared/unit-name.c
++++ b/src/shared/unit-name.c
+@@ -481,15 +481,18 @@ int unit_name_from_dbus_path(const char *path, char **name) {
+         return 0;
+ }
+ 
+-char *unit_name_mangle(const char *name) {
++
++/**
++ *  Try to turn a string that might not be a unit name into a
++ *  sensible unit name.
++ */
++char *unit_name_mangle(const char *name, bool allow_globs) {
+         char *r, *t;
+         const char *f;
++        const char* valid_chars = allow_globs ? "@" VALID_CHARS "[]!-*?" : "@" VALID_CHARS;
+ 
+         assert(name);
+ 
+-        /* Try to turn a string that might not be a unit name into a
+-         * sensible unit name. */
+-
+         if (is_device_path(name))
+                 return unit_name_from_path(name, ".device");
+ 
+@@ -506,7 +509,7 @@ char *unit_name_mangle(const char *name) {
+         for (f = name, t = r; *f; f++) {
+                 if (*f == '/')
+                         *(t++) = '-';
+-                else if (!strchr("@" VALID_CHARS, *f))
++                else if (!strchr(valid_chars, *f))
+                         t = do_escape_char(*f, t);
+                 else
+                         *(t++) = *f;
+@@ -520,7 +523,12 @@ char *unit_name_mangle(const char *name) {
+         return r;
+ }
+ 
+-char *unit_name_mangle_with_suffix(const char *name, const char *suffix) {
++
++/**
++ *  Similar to unit_name_mangle(), but is called when we know
++ *  that this is about a specific unit type.
++ */
++char *unit_name_mangle_with_suffix(const char *name, bool allow_globs, const char *suffix) {
+         char *r, *t;
+         const char *f;
+ 
+@@ -528,9 +536,6 @@ char *unit_name_mangle_with_suffix(const char *name, const char *suffix) {
+         assert(suffix);
+         assert(suffix[0] == '.');
+ 
+-        /* Similar to unit_name_mangle(), but is called when we know
+-         * that this is about snapshot units. */
+-
+         r = new(char, strlen(name) * 4 + strlen(suffix) + 1);
+         if (!r)
+                 return NULL;
+diff --git a/src/shared/unit-name.h b/src/shared/unit-name.h
+index 57719d5..362ff0c 100644
+--- a/src/shared/unit-name.h
++++ b/src/shared/unit-name.h
+@@ -98,7 +98,7 @@ char *unit_name_to_path(const char *name);
+ char *unit_dbus_path_from_name(const char *name);
+ int unit_name_from_dbus_path(const char *path, char **name);
+ 
+-char *unit_name_mangle(const char *name);
+-char *unit_name_mangle_with_suffix(const char *name, const char *suffix);
++char *unit_name_mangle(const char *name, bool allow_globs);
++char *unit_name_mangle_with_suffix(const char *name, bool allow_globs, const char *suffix);
+ 
+ int build_subslice(const char *slice, const char*name, char **subslice);
+diff --git a/src/shared/util.c b/src/shared/util.c
+index f491708..b157efa 100644
+--- a/src/shared/util.c
++++ b/src/shared/util.c
+@@ -5372,6 +5372,13 @@ bool string_has_cc(const char *p) {
+         return false;
+ }
+ 
++/**
++ * Check if a string contains any glob patterns.
++ */
++bool string_is_glob(const char *p) {
++        return strchr(p, '*') || strchr(p, '?') || strchr(p, '[');
++}
++
+ bool path_is_safe(const char *p) {
+ 
+         if (isempty(p))
+diff --git a/src/shared/util.h b/src/shared/util.h
+index b37072f..3921209 100644
+--- a/src/shared/util.h
++++ b/src/shared/util.h
+@@ -626,6 +626,7 @@ bool filename_is_safe(const char *p) _pure_;
+ bool path_is_safe(const char *p) _pure_;
+ bool string_is_safe(const char *p) _pure_;
+ bool string_has_cc(const char *p) _pure_;
++bool string_is_glob(const char *p) _pure_;
+ 
+ void *xbsearch_r(const void *key, const void *base, size_t nmemb, size_t size,
+                  int (*compar) (const void *, const void *, void *),
+diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
+index 6c9fa76..cba3f06 100644
+--- a/src/systemctl/systemctl.c
++++ b/src/systemctl/systemctl.c
+@@ -421,12 +421,10 @@ static void output_units_list(const UnitInfo *unit_infos, unsigned c) {
+                 const char *on, *off;
+ 
+                 if (n_shown) {
+-                        printf("\nLOAD   = Reflects whether the unit definition was properly loaded.\n"
+-                               "ACTIVE = The high-level unit activation state, i.e. generalization of SUB.\n"
+-                               "SUB    = The low-level unit activation state, values depend on unit type.\n");
+-                        if (job_count)
+-                                printf("JOB    = Pending job for the unit.\n");
+-                        puts("");
++                        puts("\nLOAD   = Reflects whether the unit definition was properly loaded.\n"
++                             "ACTIVE = The high-level unit activation state, i.e. generalization of SUB.\n"
++                             "SUB    = The low-level unit activation state, values depend on unit type.");
++                        puts(job_count ? "JOB    = Pending job for the unit.\n" : "");
+                         on = ansi_highlight();
+                         off = ansi_highlight_off();
+                 } else {
+@@ -1377,7 +1375,7 @@ static int list_dependencies(sd_bus *bus, char **args) {
+         assert(bus);
+ 
+         if (args[1]) {
+-                unit = unit_name_mangle(args[1]);
++                unit = unit_name_mangle(args[1], false);
+                 if (!unit)
+                         return log_oom();
+                 u = unit;
+@@ -1477,7 +1475,7 @@ static int set_default(sd_bus *bus, char **args) {
+         unsigned n_changes = 0;
+         int r;
+ 
+-        unit = unit_name_mangle_with_suffix(args[1], ".target");
++        unit = unit_name_mangle_with_suffix(args[1], false, ".target");
+         if (!unit)
+                 return log_oom();
+ 
+@@ -1706,17 +1704,12 @@ static int cancel_job(sd_bus *bus, char **args) {
+ 
+ static int need_daemon_reload(sd_bus *bus, const char *unit) {
+         _cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
+-        _cleanup_free_ char *n = NULL;
+         const char *path;
+         int b, r;
+ 
+         /* We ignore all errors here, since this is used to show a
+          * warning only */
+ 
+-        n = unit_name_mangle(unit);
+-        if (!n)
+-                return -ENOMEM;
+-
+         /* We don't use unit_dbus_path_from_name() directly since we
+          * don't want to load the unit if it isn't loaded. */
+ 
+@@ -1728,7 +1721,7 @@ static int need_daemon_reload(sd_bus *bus, const char *unit) {
+                         "GetUnit",
+                         NULL,
+                         &reply,
+-                        "s", n);
++                        "s", unit);
+         if (r < 0)
+                 return r;
+ 
+@@ -1894,8 +1887,10 @@ static int wait_for_jobs(sd_bus *bus, Set *s) {
+ 
+         while (!set_isempty(s)) {
+                 q = bus_process_wait(bus);
+-                if (q < 0)
++                if (q < 0) {
++                        log_error("Failed to wait for response: %s", strerror(-r));
+                         return q;
++                }
+ 
+                 if (d.result) {
+                         q = check_wait_response(&d);
+@@ -1903,6 +1898,8 @@ static int wait_for_jobs(sd_bus *bus, Set *s) {
+                          * meaningful. */
+                         if (q < 0 && r == 0)
+                                 r = q;
++                        log_debug("Got result %s/%s for job %s",
++                                  strna(d.result), strerror(-q), strna(d.name));
+                 }
+ 
+                 free(d.name);
+@@ -1927,7 +1924,7 @@ static int check_one_unit(sd_bus *bus, const char *name, const char *good_states
+ 
+         assert(name);
+ 
+-        n = unit_name_mangle(name);
++        n = unit_name_mangle(name, false);
+         if (!n)
+                 return log_oom();
+ 
+@@ -1984,7 +1981,7 @@ static int check_triggering_units(
+         char **i;
+         int r;
+ 
+-        n = unit_name_mangle(name);
++        n = unit_name_mangle(name, false);
+         if (!n)
+                 return log_oom();
+ 
+@@ -2051,7 +2048,6 @@ static int start_unit_one(
+                 Set *s) {
+ 
+         _cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
+-        _cleanup_free_ char *n;
+         const char *path;
+         int r;
+ 
+@@ -2060,10 +2056,7 @@ static int start_unit_one(
+         assert(mode);
+         assert(error);
+ 
+-        n = unit_name_mangle(name);
+-        if (!n)
+-                return log_oom();
+-
++        log_debug("Calling manager for %s on %s, %s", method, name, mode);
+         r = sd_bus_call_method(
+                         bus,
+                         "org.freedesktop.systemd1",
+@@ -2072,14 +2065,14 @@ static int start_unit_one(
+                         method,
+                         error,
+                         &reply,
+-                        "ss", n, mode);
++                        "ss", name, mode);
+         if (r < 0) {
+                 if (r == -ENOENT && arg_action != ACTION_SYSTEMCTL)
+                         /* There's always a fallback possible for
+                          * legacy actions. */
+                         return -EADDRNOTAVAIL;
+ 
+-                log_error("Failed to start %s: %s", name, bus_error_message(error, r));
++                log_error("Failed to %s %s: %s", method, name, bus_error_message(error, r));
+                 return r;
+         }
+ 
+@@ -2087,9 +2080,9 @@ static int start_unit_one(
+         if (r < 0)
+                 return bus_log_parse_error(r);
+ 
+-        if (need_daemon_reload(bus, n) > 0)
++        if (need_daemon_reload(bus, name) > 0)
+                 log_warning("Warning: Unit file of %s changed on disk, 'systemctl%s daemon-reload' recommended.",
+-                            n, arg_scope == UNIT_FILE_SYSTEM ? "" : " --user");
++                            name, arg_scope == UNIT_FILE_SYSTEM ? "" : " --user");
+ 
+         if (s) {
+                 char *p;
+@@ -2098,6 +2091,7 @@ static int start_unit_one(
+                 if (!p)
+                         return log_oom();
+ 
++                log_debug("Adding %s to the set", p);
+                 r = set_consume(s, p);
+                 if (r < 0)
+                         return log_oom();
+@@ -2106,6 +2100,52 @@ static int start_unit_one(
+         return 0;
+ }
+ 
++static int expand_names(sd_bus *bus, char **names, const char* suffix, char ***ret) {
++
++        _cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
++        _cleanup_strv_free_ char **mangled = NULL, **globs = NULL;
++        char **name;
++        int r = 0, i;
++
++        STRV_FOREACH(name, names) {
++                char *t;
++
++                if (suffix)
++                        t = unit_name_mangle_with_suffix(*name, true, suffix);
++                else
++                        t = unit_name_mangle(*name, true);
++                if (!t)
++                        return log_oom();
++
++                if (string_is_glob(t))
++                        r = strv_push(&globs, t);
++                else
++                        r = strv_push(&mangled, t);
++                if (r < 0) {
++                        free(t);
++                        return log_oom();
++                }
++        }
++
++        /* Query the manager only if any of the names are a glob, since
++         * this is fairly expensive */
++        if (!strv_isempty(globs)) {
++                _cleanup_free_ UnitInfo *unit_infos = NULL;
++
++                r = get_unit_list(bus, &reply, &unit_infos, globs);
++                if (r < 0)
++                        return r;
++
++                for (i = 0; i < r; i++)
++                        if (strv_extend(&mangled, unit_infos[i].id) < 0)
++                                return log_oom();
++        }
++
++        *ret = mangled;
++        mangled = NULL; /* do not free */
++        return 0;
++}
++
+ static const struct {
+         const char *target;
+         const char *verb;
+@@ -2139,12 +2179,11 @@ static enum action verb_to_action(const char *verb) {
+ }
+ 
+ static int start_unit(sd_bus *bus, char **args) {
+-        _cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
+         _cleanup_set_free_free_ Set *s = NULL;
+-        const char *method, *mode;
++        _cleanup_strv_free_ char **names = NULL;
++        const char *method, *mode, *one_name;
+         char **name;
+         int r = 0;
+-        char **names, *strv[] = {NULL, NULL}; /* at most one name */
+ 
+         assert(bus);
+ 
+@@ -2172,7 +2211,7 @@ static int start_unit(sd_bus *bus, char **args) {
+                 mode = streq(args[0], "isolate") ? "isolate" :
+                        action_table[action].mode ?: arg_job_mode;
+ 
+-                strv[0] = (char*) action_table[action].target;
++                one_name = action_table[action].target;
+         } else {
+                 assert(arg_action < ELEMENTSOF(action_table));
+                 assert(action_table[arg_action].target);
+@@ -2180,13 +2219,16 @@ static int start_unit(sd_bus *bus, char **args) {
+                 method = "StartUnit";
+ 
+                 mode = action_table[arg_action].mode;
+-                strv[0] = (char*) action_table[arg_action].target;
++                one_name = action_table[arg_action].target;
+         }
+ 
+-        if (strv[0])
+-                names = strv;
+-        else
+-                names = args + 1;
++        if (one_name)
++                names = strv_new(one_name, NULL);
++        else {
++                r = expand_names(bus, args + 1, NULL, &names);
++                if (r < 0)
++                        log_error("Failed to expand names: %s", strerror(-r));
++        }
+ 
+         if (!arg_no_block) {
+                 r = enable_wait_for_jobs(bus);
+@@ -2201,13 +2243,12 @@ static int start_unit(sd_bus *bus, char **args) {
+         }
+ 
+         STRV_FOREACH(name, names) {
++                _cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
+                 int q;
+ 
+                 q = start_unit_one(bus, method, *name, mode, &error, s);
+-                if (r == 0 && q < 0) {
++                if (r >= 0 && q < 0)
+                         r = translate_bus_error_to_exit_status(q, &error);
+-                        sd_bus_error_free(&error);
+-                }
+         }
+ 
+         if (!arg_no_block) {
+@@ -2444,17 +2485,23 @@ static int start_special(sd_bus *bus, char **args) {
+         return r;
+ }
+ 
+-static int check_unit_active(sd_bus *bus, char **args) {
++static int check_unit_generic(sd_bus *bus, int code, const char *good_states, char **args) {
++        _cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
++        _cleanup_strv_free_ char **names = NULL;
+         char **name;
+-        int r = 3; /* According to LSB: "program is not running" */
++        int r = code;
+ 
+         assert(bus);
+         assert(args);
+ 
+-        STRV_FOREACH(name, args+1) {
++        r = expand_names(bus, args, NULL, &names);
++        if (r < 0)
++                log_error("Failed to expand names: %s", strerror(-r));
++
++        STRV_FOREACH(name, names) {
+                 int state;
+ 
+-                state = check_one_unit(bus, *name, "active\0reloading\0", arg_quiet);
++                state = check_one_unit(bus, *name, good_states, arg_quiet);
+                 if (state < 0)
+                         return state;
+                 if (state > 0)
+@@ -2464,30 +2511,20 @@ static int check_unit_active(sd_bus *bus, char **args) {
+         return r;
+ }
+ 
+-static int check_unit_failed(sd_bus *bus, char **args) {
+-        char **name;
+-        int r = 1;
+-
+-        assert(bus);
+-        assert(args);
+-
+-        STRV_FOREACH(name, args+1) {
+-                int state;
+-
+-                state = check_one_unit(bus, *name, "failed\0", arg_quiet);
+-                if (state < 0)
+-                        return state;
+-                if (state > 0)
+-                        r = 0;
+-        }
++static int check_unit_active(sd_bus *bus, char **args) {
++        /* According to LSB: 3, "program is not running" */
++        return check_unit_generic(bus, 3, "active\0reloading\0", args + 1);
++}
+ 
+-        return r;
++static int check_unit_failed(sd_bus *bus, char **args) {
++        return check_unit_generic(bus, 1, "failed\0", args + 1);
+ }
+ 
+ static int kill_unit(sd_bus *bus, char **args) {
+         _cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
++        _cleanup_strv_free_ char **names = NULL;
+         char **name;
+-        int r = 0;
++        int r, q;
+ 
+         assert(bus);
+         assert(args);
+@@ -2495,14 +2532,12 @@ static int kill_unit(sd_bus *bus, char **args) {
+         if (!arg_kill_who)
+                 arg_kill_who = "all";
+ 
+-        STRV_FOREACH(name, args+1) {
+-                _cleanup_free_ char *n = NULL;
+-
+-                n = unit_name_mangle(*name);
+-                if (!n)
+-                        return log_oom();
++        r = expand_names(bus, args + 1, NULL, &names);
++        if (r < 0)
++                log_error("Failed to expand names: %s", strerror(-r));
+ 
+-                r = sd_bus_call_method(
++        STRV_FOREACH(name, names) {
++                q = sd_bus_call_method(
+                                 bus,
+                                 "org.freedesktop.systemd1",
+                                 "/org/freedesktop/systemd1",
+@@ -2510,14 +2545,16 @@ static int kill_unit(sd_bus *bus, char **args) {
+                                 "KillUnit",
+                                 &error,
+                                 NULL,
+-                                "ssi", n, arg_kill_who, arg_signal);
+-                if (r < 0) {
+-                        log_error("Failed to kill unit %s: %s", n, bus_error_message(&error, r));
+-                        return r;
++                                "ssi", *names, arg_kill_who, arg_signal);
++                if (q < 0) {
++                        log_error("Failed to kill unit %s: %s",
++                                  *names, bus_error_message(&error, r));
++                        if (r == 0)
++                                r = q;
+                 }
+         }
+ 
+-        return 0;
++        return r;
+ }
+ 
+ typedef struct ExecStatusInfo {
+@@ -3563,6 +3600,8 @@ static int show_one(
+         assert(path);
+         assert(new_line);
+ 
++        log_debug("Showing one %s", path);
++
+         r = sd_bus_call_method(
+                         bus,
+                         "org.freedesktop.systemd1",
+@@ -3735,33 +3774,34 @@ static int show_all(
+ }
+ 
+ static int cat(sd_bus *bus, char **args) {
+-        _cleanup_free_ char *unit = NULL, *n = NULL;
+-        int r = 0;
++        _cleanup_free_ char *unit = NULL;
++        _cleanup_strv_free_ char **names = NULL;
+         char **name;
+         bool first = true;
++        int r = 0;
+ 
+         assert(bus);
+         assert(args);
+ 
++        r = expand_names(bus, args + 1, NULL, &names);
++        if (r < 0)
++                log_error("Failed to expand names: %s", strerror(-r));
++
+         pager_open_if_enabled();
+ 
+-        STRV_FOREACH(name, args+1) {
++        STRV_FOREACH(name, names) {
+                 _cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
+                 _cleanup_strv_free_ char **dropin_paths = NULL;
+                 _cleanup_free_ char *fragment_path = NULL;
+                 char **path;
+ 
+-                n = unit_name_mangle(*name);
+-                if (!n)
+-                        return log_oom();
+-
+-                unit = unit_dbus_path_from_name(n);
++                unit = unit_dbus_path_from_name(*name);
+                 if (!unit)
+                         return log_oom();
+ 
+-                if (need_daemon_reload(bus, n) > 0)
++                if (need_daemon_reload(bus, *name) > 0)
+                         log_warning("Unit file of %s changed on disk. Run 'systemctl%s daemon-reload'.",
+-                                    n, arg_scope == UNIT_FILE_SYSTEM ? "" : " --user");
++                                    *name, arg_scope == UNIT_FILE_SYSTEM ? "" : " --user");
+ 
+                 r = sd_bus_get_property_string(
+                                 bus,
+@@ -3828,10 +3868,9 @@ static int cat(sd_bus *bus, char **args) {
+ }
+ 
+ static int show(sd_bus *bus, char **args) {
+-        int r, ret = 0;
+         bool show_properties, show_status, new_line = false;
+-        char **name;
+         bool ellipsized = false;
++        int r, ret = 0;
+ 
+         assert(bus);
+         assert(args);
+@@ -3849,23 +3888,19 @@ static int show(sd_bus *bus, char **args) {
+ 
+         if (show_status && strv_length(args) <= 1)
+                 ret = show_all(args[0], bus, false, &new_line, &ellipsized);
+-        else
+-                STRV_FOREACH(name, args+1) {
++        else {
++                _cleanup_free_ char **patterns = NULL;
++                char **name;
++
++                STRV_FOREACH(name, args + 1) {
+                         _cleanup_free_ char *unit = NULL;
+                         uint32_t id;
+ 
+                         if (safe_atou32(*name, &id) < 0) {
+-                                _cleanup_free_ char *n = NULL;
+-                                /* Interpret as unit name */
+-
+-                                n = unit_name_mangle(*name);
+-                                if (!n)
+-                                        return log_oom();
+-
+-                                unit = unit_dbus_path_from_name(n);
+-                                if (!unit)
++                                if (strv_push(&patterns, *name) < 0)
+                                         return log_oom();
+ 
++                                continue;
+                         } else if (show_properties) {
+                                 /* Interpret as job id */
+                                 if (asprintf(&unit, "/org/freedesktop/systemd1/job/%u", id) < 0)
+@@ -3883,6 +3918,25 @@ static int show(sd_bus *bus, char **args) {
+                         show_one(args[0], bus, unit, show_properties, &new_line, &ellipsized);
+                 }
+ 
++                if (!strv_isempty(patterns)) {
++                        _cleanup_strv_free_ char **names = NULL;
++
++                        r = expand_names(bus, patterns, NULL, &names);
++                        if (r < 0)
++                                log_error("Failed to expand names: %s", strerror(-r));
++
++                        STRV_FOREACH(name, names) {
++                                _cleanup_free_ char *unit;
++
++                                unit = unit_dbus_path_from_name(*name);
++                                if (!unit)
++                                        return log_oom();
++
++                                show_one(args[0], bus, unit, show_properties, &new_line, &ellipsized);
++                        }
++                }
++        }
++
+         if (ellipsized && !arg_quiet)
+                 printf("Hint: Some lines were ellipsized, use -l to show in full.\n");
+ 
+@@ -4063,7 +4117,7 @@ static int set_property(sd_bus *bus, char **args) {
+         if (r < 0)
+                 return bus_log_create_error(r);
+ 
+-        n = unit_name_mangle(args[1]);
++        n = unit_name_mangle(args[1], false);
+         if (!n)
+                 return log_oom();
+ 
+@@ -4110,7 +4164,7 @@ static int snapshot(sd_bus *bus, char **args) {
+         int r;
+ 
+         if (strv_length(args) > 1)
+-                n = unit_name_mangle_with_suffix(args[1], ".snapshot");
++                n = unit_name_mangle_with_suffix(args[1], false, ".snapshot");
+         else
+                 n = strdup("");
+         if (!n)
+@@ -4155,19 +4209,18 @@ static int snapshot(sd_bus *bus, char **args) {
+ 
+ static int delete_snapshot(sd_bus *bus, char **args) {
+         _cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
++        _cleanup_strv_free_ char **names = NULL;
+         char **name;
+-        int r;
++        int r, q;
+ 
+         assert(args);
+ 
+-        STRV_FOREACH(name, args+1) {
+-                _cleanup_free_ char *n = NULL;
+-
+-                n = unit_name_mangle_with_suffix(*name, ".snapshot");
+-                if (!n)
+-                        return log_oom();
++        r = expand_names(bus, args + 1, ".snapshot", &names);
++        if (r < 0)
++                log_error("Failed to expand names: %s", strerror(-r));
+ 
+-                r = sd_bus_call_method(
++        STRV_FOREACH(name, names) {
++                q = sd_bus_call_method(
+                                 bus,
+                                 "org.freedesktop.systemd1",
+                                 "/org/freedesktop/systemd1",
+@@ -4175,14 +4228,16 @@ static int delete_snapshot(sd_bus *bus, char **args) {
+                                 "RemoveSnapshot",
+                                 &error,
+                                 NULL,
+-                                "s", n);
+-                if (r < 0) {
+-                        log_error("Failed to remove snapshot %s: %s", n, bus_error_message(&error, r));
+-                        return r;
++                                "s", *name);
++                if (q < 0) {
++                        log_error("Failed to remove snapshot %s: %s",
++                                  *name, bus_error_message(&error, r));
++                        if (r == 0)
++                                r = q;
+                 }
+         }
+ 
+-        return 0;
++        return r;
+ }
+ 
+ static int daemon_reload(sd_bus *bus, char **args) {
+@@ -4236,20 +4291,19 @@ static int daemon_reload(sd_bus *bus, char **args) {
+ 
+ static int reset_failed(sd_bus *bus, char **args) {
+         _cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
++        _cleanup_strv_free_ char **names = NULL;
+         char **name;
+-        int r;
++        int r, q;
+ 
+         if (strv_length(args) <= 1)
+                 return daemon_reload(bus, args);
+ 
+-        STRV_FOREACH(name, args+1) {
+-                _cleanup_free_ char *n;
+-
+-                n = unit_name_mangle(*name);
+-                if (!n)
+-                        return log_oom();
++        r = expand_names(bus, args + 1, ".snapshot", &names);
++        if (r < 0)
++                log_error("Failed to expand names: %s", strerror(-r));
+ 
+-                r = sd_bus_call_method(
++        STRV_FOREACH(name, names) {
++                q = sd_bus_call_method(
+                                 bus,
+                                 "org.freedesktop.systemd1",
+                                 "/org/freedesktop/systemd1",
+@@ -4257,14 +4311,16 @@ static int reset_failed(sd_bus *bus, char **args) {
+                                 "ResetFailedUnit",
+                                 &error,
+                                 NULL,
+-                                "s", n);
+-                if (r < 0) {
+-                        log_error("Failed to reset failed state of unit %s: %s", n, bus_error_message(&error, r));
+-                        return r;
++                                "s", *name);
++                if (q < 0) {
++                        log_error("Failed to reset failed state of unit %s: %s",
++                                  *name, bus_error_message(&error, r));
++                        if (r == 0)
++                                r = q;
+                 }
+         }
+ 
+-        return 0;
++        return q;
+ }
+ 
+ static int show_environment(sd_bus *bus, char **args) {
+@@ -4563,7 +4619,7 @@ static int mangle_names(char **original_names, char ***mangled_names) {
+                 if (is_path(*name))
+                         *i = strdup(*name);
+                 else
+-                        *i = unit_name_mangle(*name);
++                        *i = unit_name_mangle(*name, false);
+ 
+                 if (!*i) {
+                         strv_free(l);
+@@ -4580,7 +4636,7 @@ static int mangle_names(char **original_names, char ***mangled_names) {
+ }
+ 
+ static int enable_unit(sd_bus *bus, char **args) {
+-        _cleanup_strv_free_ char **mangled_names = NULL;
++        _cleanup_strv_free_ char **names = NULL;
+         const char *verb = args[0];
+         UnitFileChange *changes = NULL;
+         unsigned n_changes = 0;
+@@ -4590,32 +4646,32 @@ static int enable_unit(sd_bus *bus, char **args) {
+         if (!args[1])
+                 return 0;
+ 
+-        r = mangle_names(args+1, &mangled_names);
++        r = mangle_names(args+1, &names);
+         if (r < 0)
+                 return r;
+ 
+-        r = enable_sysv_units(verb, mangled_names);
++        r = enable_sysv_units(verb, names);
+         if (r < 0)
+                 return r;
+ 
+         if (!bus || avoid_bus()) {
+                 if (streq(verb, "enable")) {
+-                        r = unit_file_enable(arg_scope, arg_runtime, arg_root, mangled_names, arg_force, &changes, &n_changes);
++                        r = unit_file_enable(arg_scope, arg_runtime, arg_root, names, arg_force, &changes, &n_changes);
+                         carries_install_info = r;
+                 } else if (streq(verb, "disable"))
+-                        r = unit_file_disable(arg_scope, arg_runtime, arg_root, mangled_names, &changes, &n_changes);
++                        r = unit_file_disable(arg_scope, arg_runtime, arg_root, names, &changes, &n_changes);
+                 else if (streq(verb, "reenable")) {
+-                        r = unit_file_reenable(arg_scope, arg_runtime, arg_root, mangled_names, arg_force, &changes, &n_changes);
++                        r = unit_file_reenable(arg_scope, arg_runtime, arg_root, names, arg_force, &changes, &n_changes);
+                         carries_install_info = r;
+                 } else if (streq(verb, "link"))
+-                        r = unit_file_link(arg_scope, arg_runtime, arg_root, mangled_names, arg_force, &changes, &n_changes);
++                        r = unit_file_link(arg_scope, arg_runtime, arg_root, names, arg_force, &changes, &n_changes);
+                 else if (streq(verb, "preset")) {
+-                        r = unit_file_preset(arg_scope, arg_runtime, arg_root, mangled_names, arg_force, &changes, &n_changes);
++                        r = unit_file_preset(arg_scope, arg_runtime, arg_root, names, arg_force, &changes, &n_changes);
+                         carries_install_info = r;
+                 } else if (streq(verb, "mask"))
+-                        r = unit_file_mask(arg_scope, arg_runtime, arg_root, mangled_names, arg_force, &changes, &n_changes);
++                        r = unit_file_mask(arg_scope, arg_runtime, arg_root, names, arg_force, &changes, &n_changes);
+                 else if (streq(verb, "unmask"))
+-                        r = unit_file_unmask(arg_scope, arg_runtime, arg_root, mangled_names, &changes, &n_changes);
++                        r = unit_file_unmask(arg_scope, arg_runtime, arg_root, names, &changes, &n_changes);
+                 else
+                         assert_not_reached("Unknown verb");
+ 
+@@ -4667,7 +4723,7 @@ static int enable_unit(sd_bus *bus, char **args) {
+                 if (r < 0)
+                         return bus_log_create_error(r);
+ 
+-                r = sd_bus_message_append_strv(m, mangled_names);
++                r = sd_bus_message_append_strv(m, names);
+                 if (r < 0)
+                         return bus_log_create_error(r);
+ 
+@@ -4724,16 +4780,16 @@ finish:
+ static int unit_is_enabled(sd_bus *bus, char **args) {
+ 
+         _cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
+-        _cleanup_strv_free_ char **mangled_names = NULL;
++        _cleanup_strv_free_ char **names = NULL;
+         bool enabled;
+         char **name;
+         int r;
+ 
+-        r = mangle_names(args+1, &mangled_names);
++        r = mangle_names(args+1, &names);
+         if (r < 0)
+                 return r;
+ 
+-        r = enable_sysv_units(args[0], mangled_names);
++        r = enable_sysv_units(args[0], names);
+         if (r < 0)
+                 return r;
+ 
+@@ -4741,7 +4797,7 @@ static int unit_is_enabled(sd_bus *bus, char **args) {
+ 
+         if (!bus || avoid_bus()) {
+ 
+-                STRV_FOREACH(name, mangled_names) {
++                STRV_FOREACH(name, names) {
+                         UnitFileState state;
+ 
+                         state = unit_file_get_state(arg_scope, arg_root, *name);
+@@ -4760,7 +4816,7 @@ static int unit_is_enabled(sd_bus *bus, char **args) {
+                 }
+ 
+         } else {
+-                STRV_FOREACH(name, mangled_names) {
++                STRV_FOREACH(name, names) {
+                         _cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
+                         const char *s;
+ 
+diff --git a/src/test/test-unit-name.c b/src/test/test-unit-name.c
+index 3041ae3..ad664bc 100644
+--- a/src/test/test-unit-name.c
++++ b/src/test/test-unit-name.c
+@@ -92,8 +92,8 @@ static void test_replacements(void) {
+ #define expect(pattern)                                                 \
+         {                                                               \
+                 _cleanup_free_ char *k, *t;                             \
+-                assert_se(t = unit_name_mangle(pattern));               \
+-                assert_se(k = unit_name_mangle(t));                     \
++                assert_se(t = unit_name_mangle(pattern, false));        \
++                assert_se(k = unit_name_mangle(t, false));              \
+                 puts(t);                                                \
+                 assert_se(streq(t, k));                                 \
+         }
+diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c
+index bbf5472..52634f1 100644
+--- a/src/udev/udev-rules.c
++++ b/src/udev/udev-rules.c
+@@ -961,7 +961,7 @@ static int rule_add_key(struct rule_tmp *rule_tmp, enum token_type type,
+                 int has_glob;
+ 
+                 has_split = (strchr(value, '|') != NULL);
+-                has_glob = (strchr(value, '*') != NULL || strchr(value, '?') != NULL || strchr(value, '[') != NULL);
++                has_glob = string_is_glob(value);
+                 if (has_split && has_glob) {
+                         glob = GL_SPLIT_GLOB;
+                 } else if (has_split) {
+-- 
+1.8.4.2
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 26 Dec 2013 18:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Lennart Poettering <lennart@poettering.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 26 Dec 2013 18:00:05 GMT) (full text, mbox, link).

+ +

Message #1447 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Lennart Poettering <lennart@poettering.net>
+
To: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
Cc: systemd-devel@lists.freedesktop.org, 727708@bugs.debian.org
+
Subject: Re: [PATCH] systemctl: allow globbing in commands which take + multiple unit names
+
Date: Thu, 26 Dec 2013 18:49:31 +0100
+
+
On Thu, 26.12.13 17:39, Zbigniew Jędrzejewski-Szmek (zbyszek@in.waw.pl) wrote:
+
+> As discussed on IRC, here's a patch which takes the simple approach of
+> allowing globbing on loaded unit names in various (almost all :)) systemctl
+> commands. Comments?
+
+Looks good. But maybe an additional warning should be printed if people
+use globs on the "systemctl start" command line? Some shorter version of
+the blurb you added to the man page? i am pretty sure people will run
+into this problem, and we should tell them what is going on...
+
+> +bool string_is_glob(const char *p) {
+> +        return strchr(p, '*') || strchr(p, '?') || strchr(p, '[');
+> +}
+> +
+
+This looks prettier:
+
+    #define GLOB_CHARS "*=["
+
+    bool string_is_glob(const char *p) {
+            return !!strpbrk(p, GLOB_CHARS);
+    }
+
+The macro should probably live in the header, next to ther others... And
+maybe the function too as static inline? given that is is just one
+function call internally that sounds pretty ok as static inline call?
+
+Lennart
+
+-- 
+Lennart Poettering, Red Hat
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 26 Dec 2013 18:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 26 Dec 2013 18:12:05 GMT) (full text, mbox, link).

+ +

Message #1452 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
Cc: 727708@bugs.debian.org, systemd-devel@lists.freedesktop.org, lennart@poettering.net
+
Subject: Re: Bug#727708: [PATCH] systemctl: allow globbing in commands which take multiple unit names
+
Date: Thu, 26 Dec 2013 10:09:23 -0800
+
+
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
+
+> As discussed on IRC, here's a patch which takes the simple approach of
+> allowing globbing on loaded unit names in various (almost all :)) systemctl
+> commands. Comments?
+
+I don't know the coding style of systemd, so please feel free to ignore
+this comment if it's not consistent with the style used elsewhere.  But
+since I saw this in passing:
+
+> diff --git a/src/core/device.c b/src/core/device.c
+> index 2c44dec..d3976c9 100644
+> --- a/src/core/device.c
+> +++ b/src/core/device.c
+> @@ -268,7 +268,7 @@ static int device_update_unit(Manager *m, struct udev_device *dev, const char *p
+>                                  memcpy(e, w, l);
+>                                  e[l] = 0;
+>  
+> -                                n = unit_name_mangle(e);
+> +                                n = unit_name_mangle(e, false);
+>                                  if (!n) {
+>                                          r = -ENOMEM;
+>                                          goto fail;
+
+A wise person convinced me a while back to avoid boolean arguments to C
+functions in most cases because the meaning of the argument is very
+inobvious at the call site.  "false" what?  What's disabled?  One has to
+go read the function definition to know, and while that's easy to find,
+particularly with a cross-referencing editor, it takes one more step.
+
+What I've switched to instead is using tiny enums for this purpose.  So:
+
+    enum mangle_type {
+        MANGLE_NOGLOB = 0,
+        MANGLE_GLOB   = 1
+    };
+
+and then at the call site:
+
+    n = unit_name_mangle(e, MANGLE_NOGLOB);
+
+which makes the meaning of that argument immediately obvious.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 26 Dec 2013 20:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Lennart Poettering <lennart@poettering.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 26 Dec 2013 20:45:04 GMT) (full text, mbox, link).

+ +

Message #1457 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Lennart Poettering <lennart@poettering.net>
+
To: Russ Allbery <rra@debian.org>
+
Cc: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>, + 727708@bugs.debian.org, systemd-devel@lists.freedesktop.org
+
Subject: Re: Bug#727708: [PATCH] systemctl: allow globbing in commands + which take multiple unit names
+
Date: Thu, 26 Dec 2013 21:41:42 +0100
+
+
On Thu, 26.12.13 10:09, Russ Allbery (rra@debian.org) wrote:
+
+> 
+> Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
+> 
+> > As discussed on IRC, here's a patch which takes the simple approach of
+> > allowing globbing on loaded unit names in various (almost all :)) systemctl
+> > commands. Comments?
+> 
+> I don't know the coding style of systemd, so please feel free to ignore
+> this comment if it's not consistent with the style used elsewhere.  But
+> since I saw this in passing:
+> 
+> > diff --git a/src/core/device.c b/src/core/device.c
+> > index 2c44dec..d3976c9 100644
+> > --- a/src/core/device.c
+> > +++ b/src/core/device.c
+> > @@ -268,7 +268,7 @@ static int device_update_unit(Manager *m, struct udev_device *dev, const char *p
+> >                                  memcpy(e, w, l);
+> >                                  e[l] = 0;
+> >  
+> > -                                n = unit_name_mangle(e);
+> > +                                n = unit_name_mangle(e, false);
+> >                                  if (!n) {
+> >                                          r = -ENOMEM;
+> >                                          goto fail;
+> 
+> A wise person convinced me a while back to avoid boolean arguments to C
+> functions in most cases because the meaning of the argument is very
+> inobvious at the call site.  "false" what?  What's disabled?  One has to
+> go read the function definition to know, and while that's easy to find,
+> particularly with a cross-referencing editor, it takes one more step.
+> 
+> What I've switched to instead is using tiny enums for this purpose.  So:
+> 
+>     enum mangle_type {
+>         MANGLE_NOGLOB = 0,
+>         MANGLE_GLOB   = 1
+>     };
+> 
+> and then at the call site:
+> 
+>     n = unit_name_mangle(e, MANGLE_NOGLOB);
+> 
+> which makes the meaning of that argument immediately obvious.
+
+As long as this is just one boolean arg on functions, or the functions
+are internally used I think booleans are fine to use.
+
+I don't think flag fields are necessarily the best choice for APIs in
+general. For APIs that are built around a context object seperate
+boolean setter calls are the better choice (i.e. foobar_set_waldo() to
+set som boolean called "waldo" on a context object "foobar). 
+
+Then in many APIs we exposed we actually return strings instead of
+enums, since that's much easier to extend. (libudev does this for
+example, and so does libsystemd-login)
+
+So, the summary is: keep it low on booleans, keep it low on flags. The
+middle ground where you don't have much of neither is the best, and in
+general having fewer options is better than having many...
+
+Lennart
+
+-- 
+Lennart Poettering, Red Hat
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 26 Dec 2013 21:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 26 Dec 2013 21:03:04 GMT) (full text, mbox, link).

+ +

Message #1462 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: Lennart Poettering <lennart@poettering.net>
+
Cc: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org, + systemd-devel@lists.freedesktop.org
+
Subject: Re: Bug#727708: [PATCH] systemctl: allow globbing in commands + which take multiple unit names
+
Date: Thu, 26 Dec 2013 21:58:41 +0100
+
+
On Thu, Dec 26, 2013 at 09:41:42PM +0100, Lennart Poettering wrote:
+> On Thu, 26.12.13 10:09, Russ Allbery (rra@debian.org) wrote:
+> > What I've switched to instead is using tiny enums for this purpose.  So:
+> > 
+> >     enum mangle_type {
+> >         MANGLE_NOGLOB = 0,
+> >         MANGLE_GLOB   = 1
+> >     };
+> > 
+> > and then at the call site:
+> > 
+> >     n = unit_name_mangle(e, MANGLE_NOGLOB);
+> > 
+> > which makes the meaning of that argument immediately obvious.
+> 
+> As long as this is just one boolean arg on functions, or the functions
+> are internally used I think booleans are fine to use.
+> 
+> I don't think flag fields are necessarily the best choice for APIs in
+> general. For APIs that are built around a context object seperate
+> boolean setter calls are the better choice (i.e. foobar_set_waldo() to
+> set som boolean called "waldo" on a context object "foobar). 
+I went ahead and added MANGLE_GLOB/NOGLOB as Russ suggested. I think
+that it make the code in systemctl (which is pretty convoluted) easier
+to read. It is a separate commit, so it's easy to revert if you think
+the change isn't worth it.
+
+Zbyszek
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 26 Dec 2013 21:03:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 26 Dec 2013 21:03:07 GMT) (full text, mbox, link).

+ +

Message #1467 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: Lennart Poettering <lennart@poettering.net>
+
Cc: systemd-devel@lists.freedesktop.org, 727708@bugs.debian.org
+
Subject: Re: [PATCH] systemctl: allow globbing in commands which take + multiple unit names
+
Date: Thu, 26 Dec 2013 22:00:48 +0100
+
+
On Thu, Dec 26, 2013 at 06:49:31PM +0100, Lennart Poettering wrote:
+> Looks good. But maybe an additional warning should be printed if people
+> use globs on the "systemctl start" command line? Some shorter version of
+> the blurb you added to the man page? i am pretty sure people will run
+> into this problem, and we should tell them what is going on...
+
+I'm afraid it's hard to distinguish what is on purpose, and what is not.
+One option might be to warn on start if no units were matched...
+I left it out for now.
+
+Zbyszek
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 26 Dec 2013 21:06:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 26 Dec 2013 21:06:17 GMT) (full text, mbox, link).

+ +

Message #1472 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: Russ Allbery <rra@debian.org>
+
Cc: Daniel Pocock <daniel@pocock.com.au>, 727708@bugs.debian.org, + debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: init multiple instances of a daemon
+
Date: Thu, 26 Dec 2013 22:05:34 +0100
+
+
On Sun, Dec 22, 2013 at 03:56:04PM -0800, Russ Allbery wrote:
+> Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
+> 
+> > But this should be safe for instance units, so I'd like to see
+> > 'systemctl stop/status/... server@*.service' implemented.
+> 
+> That would be very useful for distribution packagers.  If, for example,
+> you support a multiple-instance Tomcat configuration (which is quite nice
+> to do, since it isolates Java applications that may require different
+> override JARs), you want to restart all of them when you upgrade the
+> packaged Tomcat.
+
+This bug can be considered fixed upstream:
+http://cgit.freedesktop.org/systemd/systemd/commit/?id=e3e0314b56012f7
+
+I doubt that anyone would want to port it to systemd <= 208, because
+in the porting to libsystemd-bus has been completely rewritten from
+earlier versions. But it'll be part of systemd 209.
+
+Zbyszek
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 26 Dec 2013 21:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 26 Dec 2013 21:45:04 GMT) (full text, mbox, link).

+ +

Message #1477 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd vs. binfmt-support
+
Date: Thu, 26 Dec 2013 21:42:37 +0000
+
+
On Thu, Dec 26, 2013 at 08:49:11AM +0100, Tollef Fog Heen wrote:
+> > As I explain in the bug [1], I think that the facilities provided by
+> > binfmt-support are objectively superior; and even if they were broadly
+> > equivalent, I'd still question the utility of converting packages from
+> > an interface that's been well-established in Debian for over ten years.
+> > 
+> > What is the systemd maintainers' position on this bug?  I bring it up
+> > here mainly because it's an interesting example of integration.  Tollef
+> > said during the committee's last meeting on IRC that he hadn't thought
+> > much about binfmt before, so perhaps this is just a loose end.
+> 
+> binfmt-support is, AFAIK, only used in Debian and derivatives and in
+> general, I think having tools that are used across the ecosystem is more
+> valuable than having tools that are only used for parts of the
+> ecosystem.
+
+Arch uses binfmt-support as well, I believe (and now I search for it I
+see that it also ships systemd configuration for it, which will be
+useful).  I admit that I haven't put much effort into evangelising it,
+but there's nothing especially Debian-specific about binfmt-support and
+it ought to be trivial to make it work elsewhere.
+
+> In this particular case, as you write, I hadn't really given it any
+> consideration before, but what I think would make sense is to extend
+> systemd to support the same interface as binfmt-support and then people
+> who don't use systemd can use binfmt-support and those who use systemd
+> (on Debian or elsewhere) can use systemd-binfmt.  I'm guessing the
+> file format of binfmt-support is stable and unlikely to change
+> substantially in the future.
+
+I think the last non-trivial file format change was in 2010, but there
+are other interfaces (e.g. "update-binfmts --find", plus of course the
+various ones used by humans) which are in use.
+
+> This is the longer-term view. Short term, if there's any harm in having
+> both enabled, having binfmt-support disable systemd-binfmtd (by masking
+> it) would be fine.
+
+I don't think there's much harm in having both enabled as long as their
+files are disjoint, but it would probably be unwise to have them both
+try to process imports from /usr/share/binfmts/ into /var/lib/binfmts/.
+Some thought would be involved in terms of how the two approaches to
+site-specific configuration (creating files in /etc/ vs. running
+"update-binfmts --install" etc.) would interact.
+
+> Does this sound like a reasonable plan, or do you have a preference to
+> move in another direction?
+
+Thanks for your reply.  I can certainly see why you would have this
+preference, and I suppose we both have fairly predictable biases.  I'm
+afraid it leaves me rather cold, though.
+
+The first reason is, I suppose, rather selfish: I've been working on
+this on and off for fourteen years and it seems a bit rude for systemd
+to turn up and declare that it's now the standard on the strength of an
+underpowered implementation, without even mentioning it to me (I'll
+accept that this is irrational since the systemd authors probably
+weren't aware of the prior art, but it's certainly my gut reaction).  I
+suppose I'm concerned what the incentive is for people to innovate on
+this sort of thing in the future (and binfmt-support absolutely was
+innovative in terms of making the packaging of the underlying kernel
+technology trivially accessible) if they can be steamrollered at any
+time; in the long term I have more faith in the flexibility of many
+small projects than one big one.
+
+The second is that it seems like makework for the sake of aggrandising
+systemd.  systemd isn't bringing anything new to the table here; right
+now it's just exposing the raw underlying kernel interface in the form
+that's existed since 1997, and in a way that (AIUI) only works properly
+at boot time rather than doing sensible things when packages are
+installed or removed.  Of course you can put all the pieces together,
+but that was the point of binfmt-support.  This is straight
+wheel-reinvention and it seems like a total waste of everyone's time.
+Given that binfmt-support is doing a better job, my preference would be
+to put a small amount of work into making it more clearly an independent
+upstream project, and simply get more distributions using it.  Doing
+Fedora, Gentoo, and openSUSE would cover most of the bases.  Now that
+I'm aware of the effort being wasted on reinvention, I can move that
+sort of thing further up my list.
+
+Cheers,
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 28 Dec 2013 07:48:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 28 Dec 2013 07:48:09 GMT) (full text, mbox, link).

+ +

Message #1482 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: socket activation in upstart and systemd
+
Date: Fri, 27 Dec 2013 23:28:58 -0800
+
+
I've finished my first evaluation of the socket activation facilities
+provided by upstart and systemd.  I should note that I'm particularly
+interested in this functionality personally: I would use it heavily and
+intend to support it in my upstream projects, since it combines much of
+the resource minimization of xinetd with the speed of long-running daemons
+in a particularly satisfying way.
+
+I should note that I've only looked at network sockets, not UNIX domain or
+abstract sockets.
+
+The systemd socket activation support and configuration is extremely
+well-thought-out, thoroughly implemented, and well-documented.  I was
+quite impressed.  It's a lot to wrap one's mind around the first time you
+start using it, since there are several different types of units involved
+and another configuration file, and it takes a bit to get used to managing
+the service and socket somewhat separately.  But once I'd used it for a
+while, I got used to it and quite liked it.  It nicely handles all of the
+various socket binding scenarios that I've run across in years of
+maintaining socket-based network services.
+
+The upstart support... well, I think rudimentary is the kind term for it.
+Socket activation in upstart feels like a project that someone started and
+never really finished.  Unless I'm missing some trove of docs, the
+documentation seems almost non-existent (#732756).  UDP sockets appear not
+to be supported at all, which meant that I couldn't even finish my test
+case (which happened to be a UDP service).  On top of that, upstart's
+implementation appears to have the following major deficiencies compared
+to systemd's:
+
+* No IPv6 support.  Given Debian's long-standing and mostly-complete goal
+  of supporting IPv6 across the distribution, this is obviously a major
+  problem.  I'm looking at the source for upstart-socket-bridge.c right
+  now, since I wasn't sure from the documentation, but:
+
+      sock->addrlen = sizeof sock->sin_addr;
+      sock->sin_addr.sin_family = AF_INET;
+      sock->sin_addr.sin_addr.s_addr = INADDR_ANY;
+
+  seems fairly definitive.  No IPv6 support of course means that upstart
+  hasn't even started addressing the various IPv6 support issues that
+  daemons have to handle and that systemd already has addressed, such as
+  IPV6_V6ONLY behavior and IP_FREEBIND support.
+
+* One and only one bind address is supported.  This is an inherent
+  limitation in the upstart socket passing protocol, which can only pass a
+  single socket.  This is a significant problem for a lot of server
+  configuration scenarios, where daemons need to listen on specific IP
+  addresses and not on others.  All of the network daemons I maintain have
+  supported configuring multiple bind addresses for some time.
+
+There are also numerous minor features supported by systemd that aren't as
+important but that I think speak to the quality and completeness of the
+implementation, such as binding a socket to a particular network interface
+instead of address, configurable socket buffers, configuration for various
+TCP and IP options, and support for xinetd-style service activation that
+spawns a new process for each incoming connection.
+
+I believe upstart's socket activation code would need significant work
+before it could be realistically used in any useful way for network
+services in Debian.  systemd's support looks ready for widespread
+production use right now.  I intend to configure my package in the next
+upload to use socket activation with systemd if available.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 28 Dec 2013 22:48:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 28 Dec 2013 22:48:05 GMT) (full text, mbox, link).

+ +

Message #1487 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: systemd and upstart, a view from a daemon upstream
+
Date: Sat, 28 Dec 2013 22:46:13 +0000
+
+
Firstly: a warning note.  Throughout this exercise I have been
+persistently typing "upstart" when I mean "userv" and "userv" when I
+mean "upstart".  If something I say make no sense, please try reading
+it the other way :-).  (At least it gave me some extra bugs to
+experience debugging...)
+
+I have spent a while with the systemd and upstart reference manuals,
+and written and tested integration for both systems for userv.
+I didn't tackle OpenRC because AFAICT it has no reference manual.
+
+Both systems seemed to have the key facilities I would have expected,
+and I think (with minor enhancements) should be able to replace
+sysvinit at least on Linux, and allow us to do away with unsupervised
+(double-)forking daemons.
+
+It's clear that systemd is a lot more sophisticated - or, to put it
+another way, a lot more complex.  It took longer with systemd to see
+the wood for the trees.
+
+We have already discussed here the merits of systemd's daemon
+readiness protocol.  I won't go into that again.  As I say, I
+concluded that I wasn't willing to take any of the three plausible
+routes to providing that in userv.
+
+Conveniently, though, userv could be set up to use socket activation.
+So this allowed me to experiment with that.  I did the upstart
+integration with raise(SIGSTOP) and the systemd integration with
+socket activation.
+
+In both cases I invented a new command line option to specify the
+startup protocol.  userv already had an option to request non-daemonic
+startup, so this was a good fit.
+
+
+In terms of the amount of code in uservd itself:
+
+ * The upstart SIGSTOP readiness protocol was utterly trivial: exactly
+   the one line raise(SIGSTOP), plus the command-line option handling.
+
+   This was trivial to debug in an ad-hoc fashion, on my netbook which
+   is running squeeze and sysvinit.
+
+ * I had to write about 50 lines of environment-laundering code.  This
+   is particularly because systemd's choice of environment variables
+   for socket activation have very generic names: LISTEN_FDS and
+   LISTEN_PID.
+
+   systemd's theory AFAICT is that LISTEN_PID will prevent any process
+   other than the intended one from honouring the LISTEN_* variables.
+   That's of course not true of any other program which might already
+   be using these variable names for a different purpose.
+
+   I chose to also launder UPSTART_*, which is what made the
+   environment laundering process more complicated.  If I had only
+   wanted to unsetenv the two systemd variables it would have been
+   much shorter, and arguably that would have been sufficient.
+
+ * socket activation according to the systemd protocol was very short;
+   the actual code to extract the socket fd was a mere 6 loc (I ignore
+   LISTEN_PID, in violation of the nominal systemd protcol).
+   Laundering the environment could be cut down to around 4 loc.  Plus
+   command-line option handling, of course.
+
+   I didn't attempt to debug this on my local workstation.  Doing so
+   would probably have involved pratting about with socat plus a
+   wrapper script to massage the environment etc.
+
+   I didn't implement socket activation according to the upstart
+   protocol but I expect it would be nearly as easy.  UPSTART_FDS is a
+   bit more tricky because one has to tokenise it but userv only ever
+   has one socket so actually that would be a trivial sanity check.
+
+So overall my conclusions at this level are:
+
+ * socket activation is an attractive implementation target for an
+   upstream daemon author.
+
+ * upstart's SIGSTOP protocol is an attractive implementation target
+   for an upstream daemon author.
+
+ * systemd's readiness protocol is an unattractive implementation
+   target for an upstream daemon author.  I think this is an important
+   weakness, if it remains unaddressed.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 28 Dec 2013 22:48:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 28 Dec 2013 22:48:08 GMT) (full text, mbox, link).

+ +

Message #1492 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: systemd and upstart, a view from a daemon Debian maintainer
+
Date: Sat, 28 Dec 2013 22:46:55 +0000
+
+
As I have mentioned, I tried adapting userv to systemd and upstart.  I
+have already reported on my experience with the core daemon code.
+
+In this message I'll deal with the config fragments ("units" and "jobs"
+as they call them), and the Debian-specific packaging.
+
+I'm treating the config fragments as part of the packaging, rather
+than as something upstreamish, because in practice they are inherently
+un-debuggable without access to a system running the corresponding
+daemon.  They are also small enough that any distro which cares could
+easily ship their own (and might need to).
+
+
+I found configuring upstart to be utterly trivial.  There was little
+opportunity for error.  More guidance in debian-policy would be a good
+idea, including perhaps a reference to some example packages.
+
+The machinery neeeded in the package was also trivial.  For userv, I
+didn't need to modify the maintainer scripts at all; the existing
+invocations of update-rc.d and invoke-rc.d DTRT.  (userv is an old
+package whose packaging predates debhelper, let alone dh(1).)  I had
+to add a new call to dh_installinit and drop the upstart job file in
+the correct location.
+
+Debugging things was also very easy.  The logfiles were where I
+expected they would be and had the expected contents.
+
+I have read the documentation for the socket activation approach.
+Inevitably this would be a bit more fiddly but it seems like it would
+have been nearly as simple.
+
+
+systemd was rather more complex.
+
+There was less support from the Debian policy manual.  Perhaps there
+is some other systemd Debian packaging guidance somewhere which I
+didn't find.
+
+The unit files were somewhat harder to write.  It wasn't just that the
+systemd unit file offered a great many more options, although that was
+a factor.  The two-unit split of systemd socket activation was more
+fiddly.  And systemd wants each directive to be in a particular
+"[section]".
+
+The package maintainer scripts exposed more complexity too.  It was
+necessary to add new systemd-specific calls to "deb-systemd-helper".
+The boilerplate required here was too much to simply include in my
+existing scripts, so I had to switch the package to using
+debhelper-generated maintainer scripts.  (This is of course a good
+idea in the long run, but it would be better to require less
+yak-shaving.)
+
+Part of this complication results from systemd's curious approach to
+deciding which services need to run in which runlevel (or equivalent):
+once again we are expected to drop some symlinks into a magic
+directory - and provided with semiautomatic utilities for doing this.
+
+Also, the approach to the systemd integration introduces a new runtime
+package dependency on "init-system-helpers", which despite its
+generic-sounding name actually contains only helpers for systemd and
+is maintained in Debian by the systemd maintainers.
+
+Perhaps it would be possible to have more sophisticated maint script
+fragments which will cope if deb-systemd-helper is not installed -
+but, then, of course, the systemd maint script fragments will be even
+more complicated.
+
+I'm not sure at the moment whether I want to ship the systemd
+integration in my package :-/.
+
+
+Ian.
+
+
+
+ +

+ + + + +Bug 727708 cloned as bug 733452 +Request was from Ian Jackson <ijackson@chiark.greenend.org.uk> +to control@bugs.debian.org. + (Sat, 28 Dec 2013 22:48:14 GMT) (full text, mbox, link).

+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 28 Dec 2013 22:51:26 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 28 Dec 2013 22:51:26 GMT) (full text, mbox, link).

+ +

Message #1499 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: init system other points, and conclusion
+
Date: Sat, 28 Dec 2013 22:50:30 +0000
+
+
I have reported on my impressions and experiences of both systemd and
+upstart in my previous messagges.
+
+I'd like to run through the remaining points I want to make.  I'll
+then summarise and set out my primary conclusion.
+
+
+Firstly, unlike the systemd maintainers, I think portability to
+non-Linux systems is important.  It may be that our existing non-Linux
+ports are not very widely used, undermained, and/or not of production
+quality.  However, I think it is important for us to keep those
+options open.  Of course that provides a space for people to work on
+them and use them, directly, but more importantly it keeps Debian's
+options open for the future.  And the competition helps keep Linux
+honest, which is important because Linux is effectively unforkable,
+has a poor history of responsiveness to concerns of some of its
+downstream userbases, and has a nearly-unuseable governance setup.
+
+This by itself means that systemd would have to have very strong other
+advantages for me to want to choose it.  And I recognise that this
+point of view is not necessarily widely shared.  However, happily, I
+find that no conflict arises for me between my desire for portability
+and the other relevant criteria.
+
+
+It is important for a component like an init system to be flexible: it
+needs to act as glue between disparate software projects, and to
+accomodate their quirks.
+
+My experiences with systemd's Debian maintainers (and, indirectly,
+systemd's upstream) have been far from satisfactory in this regard.
+Instead of taking a flexible approach, and being willing to provide a
+range of glue facilities and approaches for different daemon
+upstreams, the systemd community seems doctrinaire.  Daemon authors
+are expected to do as they are told by systemd upstream, rather than
+systemd upstream making things comfortable for daemon developers.
+
+This is IMO the opposite of the proper attitude.
+
+The same appears to be the case for systemd's interactions with Debian
+as a downstream.  Pressure has had to be applied on issues such as
+separate /usr (and much documentation still contains claims that this
+is "broken"); I asked for systemd to be able to execute programs from
+PATH rather than requiring unit files to specify the absolute path and
+was rebuffed (#...)
+
+This is exacerbated by the fact that systemd's Debian maintainers are
+(IMO) much too deferential to upstream.
+
+Finally, the systemd community seems to havve a programme of replacing
+many other facilities throughout the system (including ones which
+other software already does better - see eg binfmt-support, #716812,
+and Colin's comments, which I agree with).  This is to be discouraged
+IMO.
+
+In short, the systemd community feels, to me, arrogant and
+controlling.  I am far from the first to say something like this, but
+I've now experienced things for myself and I concur with the
+criticism.
+
+
+upstart's minimalism is very appealing to me.
+
+It does, however, have a number of missing features.  Those I have in
+mind are:
+  - ability to log daemon output to syslog
+  - multiple socket activation (systemd socket activation protocol)
+  - socket activation for IPv6 (and datagram sockets)
+
+Of these Russ rightly points out that lack of IPv6 support is rather
+poor; it is arguably not suitable for release in jessie without this.
+
+However, crucially, these are all simple matters of programming,
+without difficult design decisions.  They IMO don't reveal structural
+problems with upstart's approach to things.
+
+Furthermore, in my view the responses of Debian's upstart maintainers
+to my bug reports about upstart have been exemplary.  There has been,
+for example, no resistance (from them or AFAICT from upstream) to
+supporting the systemd socket activation protocol.
+
+I am confident, therefore, that if we choose upstart in jessie, these
+lacunae (and any others we will discover) will be fixed.  These
+problems are certainly not blockers for selecting upstart as the
+default in jessie.
+
+
+So, to recap this and my previous mails and summarise:
+ * upstart is simpler than systemd (which leads to fewer bugs, etc.)
+ * upstart integration fits better into a daemon source code
+ * upstart is easier to package for than systemd
+ * upstart's community is much better to work with
+ * systemd's non-portability is (for me) a near-blocker
+ * upstart's remaining disadvantages are readily fixable SMOP
+ * upstart is therefore ready for adoption in jessie
+ * sysvinit has many longstanding bugs and deficiences
+ * openrc is not ready (I couldn't evaluate it due to lack of a manual)
+
+I therefore conclude that the default init system for jessie should be
+upstart.
+
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 28 Dec 2013 22:51:29 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 28 Dec 2013 22:51:29 GMT) (full text, mbox, link).

+ +

Message #1504 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: loose ends for init system decision
+
Date: Sat, 28 Dec 2013 22:50:42 +0000
+
+
We have been asked to decide the default init system for jessie.  As I
+have just said, my conclusion is that we should choose upstart.
+
+However, we also need to decide whether we intend to allow users to
+choose otherwise.  So we need to say what we expect of package
+maintainers in terms of support for other init system(s).
+
+It seems to me that the benefits of upstart integration are such that
+we should encourage transition to upstart jobs, subject to my concerns
+about the need for a new readiness protocol.
+
+
+I am not comfortable with the idea of /mandating/ use of upstart.  We
+may discover that despite our adoption, upstart loses the war, or we
+may find that we want to switch to openrc or another contender.  And,
+given the strong opinions on this topic, I think it is at the very
+least premature to tell our users and downstreams that they are on
+their own if they want to use systemd.
+
+At the moment, there is no meaningful compatibility layer between all
+these systems other than sysvinit scripts.  This is unfortunate, but
+given the current state of development of both systems I think this is
+to be expected.
+
+So I'm sorry to say that I think we need to continue to maintain
+sysvinit scripts in jessie.  The alternative would be to permit a
+package to drop sysvinit support if both systemd and upstart
+configuration were provided, but I'm not happy at this stage to burn
+our bridges like that.
+
+It would be worth researching some kind of compatibility options.
+Perhaps simple daemons with very formulaic upstart job files could
+have synthetic systemd units created.  Or something.
+
+
+I think we should give package maintainers some guidance on what kinds
+of upstart or systemd patches should be accepted.  Without this, it's
+likely we'll find ourselves adjudicating disputes that ought to have
+been settled in principle much earlier.
+
+I think that patches for either should:
+ - use a non-forking startup method
+ - avoid significant amounts of open-coded AF_UNIX socketry
+ - avoid embedded copies of daemon library code
+ - avoid extra build-dependencies (eg on libsystemd)
+ - avoid extra runtime dependencies (eg on deb-systemd-helper)
+(If the current state of the art in readiness protocols persists that
+means that upstart patches using raise(SIGSTOP) ought to be accepted,
+but systemd ones rejected unless they can use socket activation.)
+
+We should recommend:
+ - daemon authors and Debian maintainers should prefer command-line
+   options to environment variables
+ - whatever environment variables and fds are used, measures should be
+   taken to avoid them being inherited by daemons' arbitrary children
+
+IMO we should treat native non-forking upstart support as we have in
+the past done for release goals, ie with a low threshold NMU policy of
+some kind.
+
+
+But as I say I would like to see us try to get agreement or
+near-agreement on an improved startup protocol.  I would suggest that
+we allow (say) a month for this process, starting now.  Before this is
+settled we shouldn't go around converting a whole bunch of daemons.
+
+
+And, there are two loose ends about systemd in particular:
+ - There doesn't seem to be any Debian policy about how to
+   provide systemd units in Debian;
+ - systemd upstream and the Debian maintainers like to put much of the
+   configuration in /lib; this is controversial and someone needs to
+   decide whether this is appropriate.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 28 Dec 2013 23:33:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 28 Dec 2013 23:33:08 GMT) (full text, mbox, link).

+ +

Message #1509 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: systemd and upstart, a view from a daemon Debian maintainer
+
Date: Sun, 29 Dec 2013 00:29:50 +0100
+
+
Hi,
+
+Le samedi 28 décembre 2013 à 22:46 +0000, Ian Jackson a écrit : 
+> In this message I'll deal with the config fragments ("units" and "jobs"
+> as they call them), and the Debian-specific packaging.
+
+It is probably needless to say that I disagree with about 99% of what
+you wrote in tonight’s reports. I’m having a hard time understanding
+what you find complex in writing unit files, for example.
+
+But this is even more troubling: 
+> There was less support from the Debian policy manual.  Perhaps there
+> is some other systemd Debian packaging guidance somewhere which I
+> didn't find.
+
+Incorporating upstart packaging in the Debian policy before the decision
+that is currently being discussed was inappropriate and premature. From
+my point of view, it would be absurd to integrate a systemd policy
+before a decision to use it is made. It seems even more absurd that the
+lack of such a policy is used as an argument in the discussion that
+should lead to its writing.
+
+-- 
+ .''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 28 Dec 2013 23:45:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Vincent Bernat <bernat@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 28 Dec 2013 23:45:05 GMT) (full text, mbox, link).

+ +

Message #1514 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Vincent Bernat <bernat@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd and upstart, a view from a daemon Debian maintainer
+
Date: Sun, 29 Dec 2013 00:42:24 +0100
+
+
[Message part 1 (text/plain, inline)]
+
 ❦ 28 décembre 2013 23:46 CET, Ian Jackson <ijackson@chiark.greenend.org.uk> :
+
+> The package maintainer scripts exposed more complexity too.  It was
+> necessary to add new systemd-specific calls to "deb-systemd-helper".
+> The boilerplate required here was too much to simply include in my
+> existing scripts, so I had to switch the package to using
+> debhelper-generated maintainer scripts.  (This is of course a good
+> idea in the long run, but it would be better to require less
+> yak-shaving.)
+
+Most of this complexity is because systemd's maintainers are also trying
+to fix the problem with daemon automatically starting after
+install. They would have used triggers otherwise.
+-- 
+panic("kmem_cache_init(): Offsets are wrong - I've been messed with!");
+	2.2.16 /usr/src/linux/mm/slab.c
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 28 Dec 2013 23:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 28 Dec 2013 23:51:05 GMT) (full text, mbox, link).

+ +

Message #1519 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd and upstart, a view from a daemon upstream
+
Date: Sat, 28 Dec 2013 15:45:54 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> So overall my conclusions at this level are:
+
+>  * socket activation is an attractive implementation target for an
+>    upstream daemon author.
+
+>  * upstart's SIGSTOP protocol is an attractive implementation target
+>    for an upstream daemon author.
+
+>  * systemd's readiness protocol is an unattractive implementation
+>    target for an upstream daemon author.  I think this is an important
+>    weakness, if it remains unaddressed.
+
+I've indicated my disagreement with the last point elsewhere, but I wanted
+to note that I agree with both of the first points.  I have conceptual
+problems with upstart's synchronization protocol, but it's certainly easy
+to implement (in the form of a new flag) and test.
+
+For comparison purposes, the *total* burden, from my upstream perspective,
+of the two options was:
+
+* systemd: 14 lines (8 lines of code, 6 lines of build system)
+* upstart: 12 lines (6 lines of code, 6 lines of documentation)
+
+Since upstart synchronization required adding a new command-line flag, it
+needed documentation of the new flag; systemd's synchronization support
+didn't strike me as something that required documentation beyond a note
+that it was supported.
+
+Both of these are effectively trivial, and my current intention is to add
+support for both protocols to the daemons that I maintain.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 00:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 00:00:05 GMT) (full text, mbox, link).

+ +

Message #1524 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd and upstart, a view from a daemon Debian maintainer
+
Date: Sat, 28 Dec 2013 15:56:49 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I found configuring upstart to be utterly trivial.  There was little
+> opportunity for error.  More guidance in debian-policy would be a good
+> idea, including perhaps a reference to some example packages.
+
+I have a much longer message that goes into detail about what I found
+inadequate in the packaging side of the documentation and the upgrade
+issues that I encountered, which unfortunately is being rejected by the
+Debian email system as malware, probably due to some broken virus
+definition.  (I have a Debian RT ticket open about this.)  I'm happy to
+send this to anyone directly until we can figure out what's keeping it
+from making its way through the BTS and mail system.
+
+I had the opposite experience that you did: I found writing unit files for
+systemd trivial and upstart considerably more complex.  However, both can
+benefit from some additional guidance, and in neither case do I think the
+issues were particularly serious.
+
+> The package maintainer scripts exposed more complexity too.  It was
+> necessary to add new systemd-specific calls to "deb-systemd-helper".
+> The boilerplate required here was too much to simply include in my
+> existing scripts, so I had to switch the package to using
+> debhelper-generated maintainer scripts.  (This is of course a good idea
+> in the long run, but it would be better to require less yak-shaving.)
+
+It's worth noting that if you're using dh (which I was), this is trivial,
+and just involves a build-dependency on dh-systemd plus adding it to the
+dh invocation.
+
+> Also, the approach to the systemd integration introduces a new runtime
+> package dependency on "init-system-helpers", which despite its
+> generic-sounding name actually contains only helpers for systemd and is
+> maintained in Debian by the systemd maintainers.
+
+The maintainers of the package have openly offered any other useful
+helpers for any other init systems a home in that package.  I think it's
+more due to an accident of history and existing usage that the bit of
+necessary supporting glue for upstart ended up in lsb-base instead of
+init-system-helpers.
+
+It's worth noting that the systemd support in update-rc.d is substantially
+better than the upstart support.  (There's more about this in my other
+message that's being temporarily blocked.)
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 00:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 00:03:04 GMT) (full text, mbox, link).

+ +

Message #1529 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd and upstart, a view from a daemon upstream
+
Date: Sat, 28 Dec 2013 15:59:34 -0800
+
+
Russ Allbery <rra@debian.org> writes:
+
+> For comparison purposes, the *total* burden, from my upstream
+> perspective, of the two options was:
+
+> * systemd: 14 lines (8 lines of code, 6 lines of build system)
+> * upstart: 12 lines (6 lines of code, 6 lines of documentation)
+
+> Since upstart synchronization required adding a new command-line flag,
+> it needed documentation of the new flag; systemd's synchronization
+> support didn't strike me as something that required documentation beyond
+> a note that it was supported.
+
+> Both of these are effectively trivial, and my current intention is to
+> add support for both protocols to the daemons that I maintain.
+
+Sorry, this was misleading: that was for the synchronization protocol.
+For socket activation, the total upstream burden for systemd was 12 lines
+of code (10 for the implementation and 2 to stub out a call if the
+necessary library wasn't available), assuming the build system support
+already added for the synchronization protocol was in place.
+
+I was unable to add socket activation support for upstart due to its lack
+of support for SOCK_DGRAM sockets.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 00:48:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 00:48:05 GMT) (full text, mbox, link).

+ +

Message #1534 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sat, 28 Dec 2013 16:45:38 -0800
+
+
Resending this message, slightly edited, since Don pointed me in the right
+direction to figure out the erroneous virus definition and work around it.
+
+I've been continuing down the path of adding as complete of systemd and
+upstart support as is feasible to one of my packages, and have started
+working on upgrade scenarios from the existing package (which of course
+has only an init script).
+
+This has been a remarkably smooth process with systemd, far more than I
+expected.  My compliments to the systemd maintainers and packagers.  All
+the functionality that I needed was present, well-documented, and rather
+intuitive.  The process with upstart has been a bit rockier.  Experiences
+and some issues (also filed as bug reports) below.
+
+This package has an existing /etc/default conffile which supports two
+settings -- NO_START, which disables running the service, and DAEMON_OPTS,
+which adds additional options to the executable command-line.  (Well,
+right now it also contains a mandatory option, but since that option,
+setting the PID file, is only required for the init script and not for
+either systemd or upstart, I plan on adding it unconditionally in the init
+script and documenting that it's no longer needed in a NEWS entry.)
+
+NO_START was a bad idea and I regret ever adding it.  My intent is to fix
+this during the upgrade by converting any existing setting into a proper
+disabling of the init script.  So, in other words, in postinst:
+
+    . /etc/default/lbcd
+    if [ "$NO_START" = 1 ] ; then
+        update-rc.d lbcd disable
+    fi
+
+(protected by a conditional to only happen on upgrades from the older
+version).
+
+With systemd, this does the right thing.  With upstart, this is ignored
+entirely so far as I can tell (#733289).
+
+Am I missing something?  I didn't actually reboot the test machine that
+I'm working with to see if something somehow was reading the update-rc.d
+status inside upstart, but Google turned up multiple people reporting the
+same thing in Ubuntu: update-rc.d works for init scripts but not for
+services converted to upstart.
+
+I could work around this in the postinst with:
+
+    . /etc/default/lbcd
+    if [ "$NO_START" = 1 ] ; then
+        update-rc.d lbcd disable
+        echo manual > /etc/init/lbcd.override
+    fi
+
+but I'd need to add in more logic to be sure I'm not tromping on a user's
+existing override file, and the user now has to track the fact that this
+service is disabled in two different ways.  They can't just re-enable it
+with update-rc.d lbcd enable, and behavior will not necessarily be
+synchronized when they switch between init systems.
+
+Given that I would like to be able to recommend this approach to anyone
+who needs to get rid of the ill-advised /etc/default options to not start
+services (something that doesn't work well with any of the new init
+systems and was never a good idea in the first place), not having this
+integration is frustrating.
+
+The second supported option is DAEMON_OPTS, which sets additional flags to
+add to the process.  For as long as we need to support multiple init
+systems, this option needs to stay in /etc/default/lbcd and be read from
+there by all supported init systems so that configuration is preserved as
+the user moves between init systems.  With systemd, this is trivial.  Add
+the following to lbcd.service:
+
+    # Support for /etc/default/lbcd is here only for backward
+    # compatibility with the lbcd init script shipped with Debian.  It and
+    # the $DAEMON_OPTS reference can be dropped if this backward
+    # compatibility is not needed.
+    EnvironmentFile=-/etc/default/lbcd
+    ExecStart=/usr/sbin/lbcd -f -l $DAEMON_OPTS
+
+With upstart, it also turns out to be relatively simple, but the
+documentation is not very good right now, and I had multiple dead ends.
+
+First, I was using an exec line to run the daemon in my first draft of an
+upstart script.  The documentation indicated that switching to a script
+was the best way of handling this, so my first try was:
+
+    expect stop
+    script
+        if [ -f /etc/default/lbcd ] ; then
+            . /etc/default/lbcd
+        fi
+        /usr/sbin/lbcd -f -l -Z $DAEMON_OPTS
+    end script
+
+(well, my first try used
+
+    [ -f /etc/default/lbcd ] && . /etc/default/lbcd
+
+but upstart scripts use set -e, so this doesn't work, which is a standard
+set -e pitfall that should probably be mentioned in the docs for the aid
+of all the people who will be copying and pasting from init scripts).
+
+Folks familiar with upstart probably already know that this fails.  The
+last line needs an exec, or expect stop gets confused (#733287).  This is
+obvious in retrospect.
+
+After some more experimentation (the documentation doesn't say clearly
+whether pre-start can expose environment variables to exec or not), it
+looks like a better approach is:
+
+    expect stop
+
+    pre-start script
+        test -x /usr/sbin/lbcd || { stop; exit 0; }
+        if [ -f /etc/default/lbcd ] ; then 
+            . /etc/default/lbcd
+        fi
+    end script
+
+    # To change the default lbcd service, specify a command to run for the
+    # weight and interval, or do round-robin (-R), set the desired flags
+    # in DAEMON_OPTS in /etc/default/lbcd.
+    exec /usr/sbin/lbcd -f -l -Z $DAEMON_OPTS
+
+This seems to work and is what I will be uploading.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 01:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 01:27:04 GMT) (full text, mbox, link).

+ +

Message #1539 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sat, 28 Dec 2013 17:24:57 -0800
+
+
I have now uploaded lbcd 3.5.0-1 to the archive.  This contains what I
+believe to be a full implementation of systemd and upstart compatibility
+for a UDP-based daemon from both an upstream and packaging perspective,
+including dealing with some upgrade issues from previous bad decisions I'd
+made (as documented in the previous message).
+
+I'd welcome commentary or critique on anything I did incorrectly or not in
+keeping with the spirit of one of the init systems.  I was unable to do
+the same for OpenRC since I didn't have documentation or a test platform.
+
+By full, I mean:
+
+* upstart synchronization via SIGSTOP added as a command-line option.
+* systemd synchronization support added via sd_notify.
+* systemd socket activation support.
+* Upstream source installs unit files per daemon(7).
+
+I did this because I wanted to get a feel for everything that was involved
+in fully implementing upstream's recommendations.
+
+In addition, the Debian packaging provides a native upstart configuration
+file, and includes the upgrade code that I discussed in my previous
+message.  I did not attempt to support NO_START on upgrades for upstart
+systems, pending a better resolution of the update-rc.d issue.
+
+I'll have more to say about the relative merits of the two init systems
+later, but one thing I wanted to not briefly: this exercise was extremely
+valuable in helping me get a more realistic picture of both init systems.
+I had gone into this exercise with the vague impression that they were
+roughly at feature parity, and now realize that is not the case.
+
+My impression now is that systemd's init and service management component
+is a substantially more mature piece of software.  That's an odd thing to
+say given that upstart is older, but systemd has the feel of software
+that's been tested against a wide variety of different situations and has
+had the necessary adaptations and configuration added to meet those needs.
+In some cases, that's "simply" additional features; in some cases, that's
+more comprehensive and more scalable design.  The socket activation system
+in particular is night and day between the two systems.
+
+I spent more time working on systemd integration than upstart integration,
+but that's because systemd brought so much more to the table and I got
+much more benefit out of it.  Integrating with upstart felt like
+janitorial work: do things this way instead of that way, debug some
+things, and now I'm back to basically the same functionality as I had with
+an init script except without all the forking and PID files.  I don't mean
+to understate that, but I had that experience a decade ago with
+daemontools, so it isn't horribly exciting.  systemd, on the other hand,
+inspired me to experiment and to design because it felt like it was
+tackling larger problems and taking a broader view.  When doing systemd
+integration, I felt like I was making the software better in concrete and
+measurable ways, as opposed to just satisfying an integration requirement.
+
+I also want to call out the design of systemctl status, which is an
+absolutely lovely tool and which single-handedly sold me on the benefits
+of the systemd journal (something about which I was previously quite
+dubious).  Being able to run one command and see nearly everything of
+relevance to my daemon including all of its recent log messages was a
+delight, both as a developer and as a systems administrator.  The systemd
+folks did a great job here.
+
+For those who haven't seen it, here's sample systemctl status output:
+
+lbcd.service - responder for load balancing
+   Loaded: loaded (/lib/systemd/system/lbcd.service; enabled)
+   Active: active (running) since Sat 2013-12-28 17:18:11 PST; 40s ago
+     Docs: man:lbcd(8)
+           http://www.eyrie.org/~eagle/software/lbcd/
+ Main PID: 3465 (lbcd)
+   CGroup: name=systemd:/system/lbcd.service
+           └─3465 /usr/sbin/lbcd -f -l
+
+Dec 28 17:18:11 wanderer systemd[1]: Starting responder for load balancing...
+Dec 28 17:18:11 wanderer lbcd[3465]: ready to accept requests
+Dec 28 17:18:11 wanderer lbcd[3465]: request from ::1 (version 3)
+Dec 28 17:18:11 wanderer systemd[1]: Started responder for load balancing.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 02:27:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 02:27:19 GMT) (full text, mbox, link).

+ +

Message #1544 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sat, 28 Dec 2013 18:23:22 -0800
+
+
Russ Allbery <rra@debian.org> writes:
+
+> I have now uploaded lbcd 3.5.0-1 to the archive.
+
+And now lbcd 3.5.0-2, because I completely forgot to add the stanzas to
+the systemd unit and upstart configuration file to run lbcd as a non-root
+user.  Whoops.  (And, of course, I noticed one more problem after that
+upload, so 3.5.0-3 will be coming shortly to fix an architecture
+dependency for systemd support.)
+
+Since I'm thinking about it (I just added a patch in the Debian packaging
+to a unit file installed by a package for which I'm upstream), and since
+it came up on the thread previously, a note from the upstream perspective
+about portability of systemd unit files.
+
+I think the dream of using the exact same unit file with no changes on all
+distributions is just that, a dream.  It will work in some simple cases,
+and not work in many other cases.  This package is an excellent example:
+the Debian packaging installs a system non-root user, and the daemon runs
+as that user.  As upstream, I don't want to assume anything about users,
+and I certainly don't want to add a user and group to the system during
+make install, so the unit file I install runs lbcd as root (which should
+be harmless; running as a non-root user is defense in depth).  As a Debian
+packager, obviously I have the tools available to create a system user and
+should do so.  This is similar to the cases of changing paths.
+
+However, what is certainly true is that systemd unit files come far, far
+closer to being able to universally use the same configuration than init
+scripts, so much closer that it does make sense for upstream to install
+them.  By comparison, sharing init scripts between Red Hat and Debian is
+almost impossible, and upstream-provided init scripts almost always
+require significant changes or even complete rewrites.
+
+This is a real benefit over the sysvinit world.  However, it's not really
+a distinguishing feature between systemd and upstart.  upstart
+configuration files have basically the same necessary properties: much
+shorter, more features built into the init system so less dependence on
+various external files, and standardized functionality.  The systemd
+upstream has put more effort into making it easy for upstreams to install
+unit files than the upstart maintainers to date, but the basic design has
+similar properties.  So for me it's not a distinguishing point between the
+two.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 02:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 02:45:04 GMT) (full text, mbox, link).

+ +

Message #1549 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd and upstart, a view from a daemon Debian + maintainer
+
Date: Sat, 28 Dec 2013 18:41:45 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sun, Dec 29, 2013 at 12:29:50AM +0100, Josselin Mouette wrote:
+
+> But this is even more troubling: 
+> > There was less support from the Debian policy manual.  Perhaps there
+> > is some other systemd Debian packaging guidance somewhere which I
+> > didn't find.
+
+> Incorporating upstart packaging in the Debian policy before the decision
+> that is currently being discussed was inappropriate and premature. From
+> my point of view, it would be absurd to integrate a systemd policy
+> before a decision to use it is made. It seems even more absurd that the
+> lack of such a policy is used as an argument in the discussion that
+> should lead to its writing.
+
+The upstart packaging guidance was written into policy because integrating
+with a new init system requires changes that could in some cases be
+violations of existing policy.  It's not ok to simply ignore policy and
+deploy sweeping changes in the archive with our users as the guinea pigs.
+
+Packages are shipping systemd units in the archive today, and Policy
+*should* cover this case.  Currently, it covers this by saying "you can
+integrate with systemd, but must still provide compatibility with sysvinit",
+which I think is fine at this stage.
+
+It's never premature to be a good citizen in Debian.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 02:45:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 02:45:08 GMT) (full text, mbox, link).

+ +

Message #1554 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Vincent Bernat <bernat@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd and upstart, a view from a daemon Debian + maintainer
+
Date: Sat, 28 Dec 2013 18:42:59 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sun, Dec 29, 2013 at 12:42:24AM +0100, Vincent Bernat wrote:
+>  ❦ 28 décembre 2013 23:46 CET, Ian Jackson <ijackson@chiark.greenend.org.uk> :
+
+> > The package maintainer scripts exposed more complexity too.  It was
+> > necessary to add new systemd-specific calls to "deb-systemd-helper".
+> > The boilerplate required here was too much to simply include in my
+> > existing scripts, so I had to switch the package to using
+> > debhelper-generated maintainer scripts.  (This is of course a good
+> > idea in the long run, but it would be better to require less
+> > yak-shaving.)
+
+> Most of this complexity is because systemd's maintainers are also trying
+> to fix the problem with daemon automatically starting after
+> install. They would have used triggers otherwise.
+
+What "problem" do you refer to here?  Starting daemons automatically on
+install is a policy-driven expectation, not a problem.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 02:57:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 02:57:05 GMT) (full text, mbox, link).

+ +

Message #1559 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Sat, 28 Dec 2013 18:52:24 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> Firstly, unlike the systemd maintainers, I think portability to
+> non-Linux systems is important.  It may be that our existing non-Linux
+> ports are not very widely used, undermained, and/or not of production
+> quality.  However, I think it is important for us to keep those options
+> open.  Of course that provides a space for people to work on them and
+> use them, directly, but more importantly it keeps Debian's options open
+> for the future.  And the competition helps keep Linux honest, which is
+> important because Linux is effectively unforkable, has a poor history of
+> responsiveness to concerns of some of its downstream userbases, and has
+> a nearly-unuseable governance setup.
+
+> This by itself means that systemd would have to have very strong other
+> advantages for me to want to choose it.  And I recognise that this point
+> of view is not necessarily widely shared.  However, happily, I find that
+> no conflict arises for me between my desire for portability and the
+> other relevant criteria.
+
+I find this statement curious, given your recommendation of upstart, since
+my understanding is that neither upstart nor systemd have been ported to
+non-Linux systems.
+
+Is the porting work started by Dmitrijs Ledkovs farther along than I had
+thought?  The latest update I heard from November was that he had a fork
+of libnih that passed its test suite once several key features were
+disabled (inotify, abstract domain sockets), and very little of that work
+had been merged upstream.  (It's possibly worth noting here that the
+libnih upstream and Debian package maintainer is still Scott James
+Remnant, who previously expressed skepticism of a straight port to
+kFreeBSD.)
+
+I've been giving a lot of thought to the portability issue as well, but
+where I'm currently at is rather different than your sentiments above.  My
+feeling is that there is a slight advantage to upstart here in that the
+port has been started, but it's slight.  In both cases, there are
+Linux-specific APIs embedded deeply in the project, and in both cases
+porting would require substantial effort.
+
+The upstart porting effort appears to be working in exactly the right way:
+providing functionality in glibc and the kernel on FreeBSD that supports
+the APIs that libnih needs.  That would also be the first step in porting
+systemd to kFreeBSD/glibc.  It's great work and benefits both projects as
+well as many others, but I'm not sure it's a meaningful discriminator.
+
+I feel like you may be overly optimistic about future development in
+upstart and overly pessimistic about future development in systemd here.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 02:57:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Stapelberg <stapelberg@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 02:57:08 GMT) (full text, mbox, link).

+ +

Message #1564 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Stapelberg <stapelberg@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, <727708@bugs.debian.org>
+
Subject: Re: init system other points, and conclusion
+
Date: Sun, 29 Dec 2013 03:54:36 +0100
+
+
Hi Ian,
+
+My apologies in advance for answering only to one email, but quoting
+several. It could be that you had some threading in mind which my reply
+might break.
+
+Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> * systemd's readiness protocol is an unattractive implementation
+>   target for an upstream daemon author.  I think this is an important
+>   weakness, if it remains unaddressed.
+We talked about this in #732157 already, but I think it is worth
+summarizing it here: for modern daemons, libsystemd-daemon is a widely
+available library which can be trivially added. In case dependencies
+absolutely need to be kept at a minimum, the less preferably alternative
+of dropping that library’s code into the daemon’s code base exists. If
+both of those are unsatisfactory, one can implement it by oneself, which
+you deem unattractive. I tend to agree, but I think you are overstating
+this as an “important weakness”. Most daemons do not even need any
+readiness notification whatsoever. Using socket activation or forking
+after initialization is enough.
+
+> I'm treating the config fragments as part of the packaging, rather
+> than as something upstreamish, because in practice they are inherently
+> un-debuggable without access to a system running the corresponding
+> daemon.  They are also small enough that any distro which cares could
+> easily ship their own (and might need to).
+I don’t understand that reasoning. By “daemon”, do you mean init system
+or actual daemon for which the service file is intended? Also, why would
+a distro ship its own? Even in the rare case that an upstream-provided
+service file is (and stays!) unsuitable for Debian, a patch is all that
+is necessary.
+
+> There was less support from the Debian policy manual.  Perhaps there
+> is some other systemd Debian packaging guidance somewhere which I
+> didn't find.
+There is https://wiki.debian.org/Systemd/Packaging which is the first
+Google hit for “debian systemd packaging”. Until a while ago, the page
+was changing a lot while we were still hashing out details about
+packaging. By now, I’d say we could add this to the policy manual.
+
+> The unit files were somewhat harder to write.  It wasn't just that the
+> systemd unit file offered a great many more options, although that was
+> a factor.  The two-unit split of systemd socket activation was more
+> fiddly.  And systemd wants each directive to be in a particular
+> "[section]".
+See also http://0pointer.de/blog/projects/systemd-for-admins-3.html
+(“How Do I Convert A SysV Init Script Into A systemd Service File?”).
+I do admit that this is hard to find if you don’t know it exists. It
+_is_ linked to from the main systemd website, though, but I cannot
+expect that everybody reads the entire body of documentation.
+
+> Also, the approach to the systemd integration introduces a new runtime
+> package dependency on "init-system-helpers", which despite its
+> generic-sounding name actually contains only helpers for systemd and
+> is maintained in Debian by the systemd maintainers.
+It has already been pointed out elsewhere in the thread, but given that
+I introduced this package, I’d like to stress again that I will gladly
+accept other init system’s helper programs to this package. The package
+name and description is not misleading; I really mean it.
+
+> The same appears to be the case for systemd's interactions with Debian
+> as a downstream.  Pressure has had to be applied on issues such as
+> separate /usr (and much documentation still contains claims that this
+> is "broken"); I asked for systemd to be able to execute programs from
+> PATH rather than requiring unit files to specify the absolute path and
+> was rebuffed (#...)
+#732981 is the bug reference that you didn’t include by accident, I
+think :).
+
+> This is exacerbated by the fact that systemd's Debian maintainers are
+> (IMO) much too deferential to upstream.
+> […]
+> In short, the systemd community feels, to me, arrogant and
+> controlling.  I am far from the first to say something like this, but
+> I've now experienced things for myself and I concur with the
+> criticism.
+Given that I am the one who responded to both your referenced bug
+reports, let me provide my perspective in this bug. Upstream does not
+want to provide the features you asked for, and I’ll not comment on
+that, apart from stating that it’s not obvious that they are a good idea
+(one can see that from the discussion on the bugs).
+
+You then asked for these features to be carried as a patch in the Debian
+systemd package, and both requests were rejected. I think this is what
+you refer to when saying “the systemd Debian maintainers are much too
+deferential to upstream”. The reason why we don’t want to carry these
+patches is that they significantly alter the public API between systemd
+and the daemon authors — but in Debian only!
+
+As stated in the bug, my rule of thumb is whether people need to
+differentiate between Debian and “all other distributions”. E.g., with
+your simpler readiness notification proposal, daemon authors could use
+that on Debian, but would need to conditionally compile code for Debian
+while they also still need to ship code for the current API. This is not
+a simplification at all. Similarly, with the $PATH thing, we’d introduce
+the need to patch _every_ single upstream unit in our Debian
+packages. Even worse, unit file authors would be surprised when their
+unit file does not work on other systems when it was written and tested
+on Debian (where one could use $PATH).
+
+> Furthermore, in my view the responses of Debian's upstart maintainers
+> to my bug reports about upstart have been exemplary.  There has been,
+> for example, no resistance (from them or AFAICT from upstream) to
+> supporting the systemd socket activation protocol.
+I’d like to point out that with features that are universally accepted
+(and especially by upstream), the response of systemd contributors was
+exemplary, too. Zbigniew Jędrzejewski-Szmek in particular has reacted to
+documentation clarification requests and even feature requests like the
+globbing of units in record time. Thanks for that!
+
+-- 
+Best regards,
+Michael
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 02:57:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 02:57:11 GMT) (full text, mbox, link).

+ +

Message #1569 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org, Vincent Bernat <bernat@debian.org>
+
Subject: Re: Bug#727708: systemd and upstart, a view from a daemon Debian maintainer
+
Date: Sat, 28 Dec 2013 18:56:11 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+> On Sun, Dec 29, 2013 at 12:42:24AM +0100, Vincent Bernat wrote:
+>> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+>>> The package maintainer scripts exposed more complexity too.  It was
+>>> necessary to add new systemd-specific calls to "deb-systemd-helper".
+>>> The boilerplate required here was too much to simply include in my
+>>> existing scripts, so I had to switch the package to using
+>>> debhelper-generated maintainer scripts.  (This is of course a good
+>>> idea in the long run, but it would be better to require less
+>>> yak-shaving.)
+
+>> Most of this complexity is because systemd's maintainers are also
+>> trying to fix the problem with daemon automatically starting after
+>> install. They would have used triggers otherwise.
+
+> What "problem" do you refer to here?  Starting daemons automatically on
+> install is a policy-driven expectation, not a problem.
+
+The purpose of deb-systemd-helper is to set up the proper links for
+systemd unit files on a system where systemd is not installed, so that if
+you later install systemd, the right configuration (echoing the sysvinit
+configuration) is already in place.
+
+I think that's the installation that Vincent is referring to, not the
+installation of the package on a system with systemd already running.
+
+You can't use triggers in the systemd package to handle this because the
+whole point is that the systemd package is not necessarily installed.  If
+we standardized on systemd as the required init system, much of that
+complexity could be removed; it's there to be a good Debian citizen and
+interoperate with the rest of the archive, including switching back and
+forth between different init systems.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 03:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 03:03:04 GMT) (full text, mbox, link).

+ +

Message #1574 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: systemd and upstart, a view from a daemon Debian maintainer
+
Date: Sat, 28 Dec 2013 19:00:06 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> Packages are shipping systemd units in the archive today, and Policy
+> *should* cover this case.  Currently, it covers this by saying "you can
+> integrate with systemd, but must still provide compatibility with
+> sysvinit", which I think is fine at this stage.
+
+I think it's worth noting that the Policy documentation for both upstart
+and systemd is minimal at this point.  The only reason why there's any
+upstart documentation at all is that the upstart maintainers took the
+approach of requiring init scripts to disable themselves when upstart is
+running (requiring a Policy mention), whereas the systemd maintainers took
+the approach of ignoring init scripts that have the same name as systemd
+units and implementing all the required update-rc.d and invoke-rc.d glue
+to keep state in sync.
+
+(I have a mild preference for the systemd approach over the upstart
+approach here, but I don't think it's a significant difference.)
+
+In *both* cases, substantially more Policy documentation will be required
+if we adopt that init system, particularly around upgrade cases from
+sysvinit scripts and some of the edge cases such as /etc/default settings
+to disable starting a service.  I ran into several things with both
+upstart and systemd that would need Policy documentation to ensure that we
+did them consistently.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 03:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 03:15:05 GMT) (full text, mbox, link).

+ +

Message #1579 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Michael Stapelberg <stapelberg@debian.org>
+
Cc: 727708@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Sat, 28 Dec 2013 19:11:15 -0800
+
+
Michael Stapelberg <stapelberg@debian.org> writes:
+
+> You then asked for these features to be carried as a patch in the Debian
+> systemd package, and both requests were rejected. I think this is what
+> you refer to when saying “the systemd Debian maintainers are much too
+> deferential to upstream”. The reason why we don’t want to carry these
+> patches is that they significantly alter the public API between systemd
+> and the daemon authors — but in Debian only!
+
+> As stated in the bug, my rule of thumb is whether people need to
+> differentiate between Debian and “all other distributions”. E.g., with
+> your simpler readiness notification proposal, daemon authors could use
+> that on Debian, but would need to conditionally compile code for Debian
+> while they also still need to ship code for the current API. This is not
+> a simplification at all. Similarly, with the $PATH thing, we’d introduce
+> the need to patch _every_ single upstream unit in our Debian
+> packages. Even worse, unit file authors would be surprised when their
+> unit file does not work on other systems when it was written and tested
+> on Debian (where one could use $PATH).
+
+I agree with Michael on this point.  I think he would be doing a
+disservice to both Debian and upstreams to carry these sorts of changes as
+distribution-specific patches.
+
+Support for SIGSTOP is, I think, a debatable point, and I understand Ian's
+position.  I also understand Lennart's position.  If I were Lennart, I
+probably would have added it, but I can understand why he wants to
+discourage it.  I don't think it's a good long-term solution.  I do think
+a strong argument could be made for adding it, though... but not as a
+distribution-specific patch.  That seems like a recipe for user confusion.
+
+On $PATH searching, I just completely disagree with Ian.  Adding $PATH
+dependencies to unit files is something I consider a straight-out bad
+idea.  Patching unit files to adjust paths, even if it requires
+distribution-specific patches, is significantly better.  I would have told
+him no to this request were I systemd upstream as well.  It makes the
+whole init system more fragile in ways that aren't helpful.
+
+> I’d like to point out that with features that are universally accepted
+> (and especially by upstream), the response of systemd contributors was
+> exemplary, too. Zbigniew Jędrzejewski-Szmek in particular has reacted to
+> documentation clarification requests and even feature requests like the
+> globbing of units in record time. Thanks for that!
+
+I concur with this.  I have had exceptionally good interactions with both
+systemd upstream and the systemd package maintainers.
+
+I think Ian had the misfortune of having the two points he cared the most
+about both be objections to fundamental design decisions and places where
+upstream felt that implementing his approach would make the system more
+fragile.  In one case, I agree with them.  Rejecting such requests does
+not make for a bad upstream.  I would argue that's upstream's job.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 03:54:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 03:54:09 GMT) (full text, mbox, link).

+ +

Message #1584 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: 726763@bugs.debian.org, 729576@bugs.debian.org
+
Cc: 727708@bugs.debian.org, systemd@packages.debian.org
+
Subject: systemd-shim uploaded to NEW
+
Date: Sat, 28 Dec 2013 19:50:11 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Control: affects 726763 systemd
+
+I've just uploaded the systemd-shim package to the NEW queue.  This provides
+an implementation of the org.freedesktop.systemd1 dbus service which is
+compatible with non-systemd-using systems.  I have verified this service
+works with gdm3 in unstable, at least to the point of enabling shutdown from
+the GUI menu.
+
+There are, however, some remaining problems to sort out before systemd-shim
+will solve the hard dependency of GNOME on systemd in unstable.  The systemd
+maintainers have rejected my request to split the systemd binary package
+between the init system and the dbus services.  This is problematic, because
+systemd-shim provides an independent implementation of some, but not all, of
+the systemd dbus services: to be precise, it provides only
+org.freedesktop.systemd1.service, not any of
+org.freedesktop.hostname1.service, org.freedesktop.locale1.service,
+org.freedesktop.login1.service, and org.freedesktop.timedate1.service.  It
+does not provide these services because the existing implementations from
+systemd are perfectly usable on a stand-alone basis without pid1==systemd.
+As a result, systemd-shim has a Conflict with systemd (which is correct),
+but GNOME needs to be able to depend on all of the above dbus services
+installable together.
+
+So I repeat here my request that the systemd maintainers make a suitable
+split of the systemd binary package, so that systemd-shim will be
+coinstallable with the systemd-provided implementations of the other dbus
+services.  The only alternative I see is for systemd-shim to declare a
+Replaces: against systemd without a Conflicts, which would have the known
+problematic effect that anyone removing the systemd-shim package again
+(perhaps because they are choosing to switch to systemd) will be left
+without the Replaced files on disk.  I would prefer users not to be
+subjected to such poor integration, on top of the problems they've already
+been made to endure as a result of the GNOME packages gaining an
+ill-coordinated dependency on an init system; but of the available choices,
+this seems to be the lesser evil if the systemd maintainers continue to
+insist on a monolithic binary package.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 04:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 04:00:04 GMT) (full text, mbox, link).

+ +

Message #1589 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd vs. binfmt-support
+
Date: Sun, 29 Dec 2013 05:56:30 +0200
+
+
On Thu, 2013-12-26 at 21:42 +0000, Colin Watson wrote:
+> On Thu, Dec 26, 2013 at 08:49:11AM +0100, Tollef Fog Heen wrote:
+> > In this particular case, as you write, I hadn't really given it any
+> > consideration before, but what I think would make sense is to extend
+> > systemd to support the same interface as binfmt-support and then people
+> > who don't use systemd can use binfmt-support and those who use systemd
+> > (on Debian or elsewhere) can use systemd-binfmt.  I'm guessing the
+
+> afraid it leaves me rather cold, though.
+> 
+> The first reason is, I suppose, rather selfish: I've been working on
+> this on and off for fourteen years and it seems a bit rude for systemd
+> to turn up and declare that it's now the standard on the strength of an
+> underpowered implementation, without even mentioning it to me (I'll
+> accept that this is irrational since the systemd authors probably
+> weren't aware of the prior art, but it's certainly my gut reaction).  I
+
+I don't think systemd authors have made any declarations about binfmt in
+particular. The only thing they've actually done is add a very simple
+implementation (src/binfmt/binfmt.c, less than 200 lines of code, much
+of it argument parsing). I consider having a basic implementation to be
+a useful "batteries included" feature: systemd supports lots of
+different setups from embedded to desktop, and it's useful to have at
+least a basic implementation ready when building a system. It's easy
+enough to override if you want something different. Thus I consider any
+opinions saying systemd should not include a tool for setting binfmt, or
+that adding it was somehow objectionable behavior, to be wrong. Whether
+it would be preferable for the tool to support more complex
+functionality is another question.
+
+
+> suppose I'm concerned what the incentive is for people to innovate on
+> this sort of thing in the future (and binfmt-support absolutely was
+> innovative in terms of making the packaging of the underlying kernel
+> technology trivially accessible) if they can be steamrollered at any
+> time; in the long term I have more faith in the flexibility of many
+> small projects than one big one.
+
+I think this has been proven false by experience - systemd has innovated
+a lot in things where smaller projects were stagnant. And there's a
+fairly clear reason why this would be so: something like binfmt-support
+is too small a unit for independent development, both to design
+independently and to "sell" to every user individually.
+
+Binfmt support is not that complex a task in itself. In practice, a lot
+of the usability will depend on consistency with other system parts.
+Designing APIs for it only is too narrow a view; you need to consider
+other tools, and if you can do better, then it's quite likely you should
+change the other tools too (things like adding udev rules etc).
+
+Convincing every distro builder out there individually that your binfmt
+support code is best wastes effort, both yours and theirs. It's more
+efficient to have systemd upstream decide what is a reasonable default
+implementation, and then have only people with specific needs or
+opinions change it.
+
+
+> The second is that it seems like makework for the sake of aggrandising
+> systemd.  systemd isn't bringing anything new to the table here; right
+> now it's just exposing the raw underlying kernel interface in the form
+> that's existed since 1997, and in a way that (AIUI) only works properly
+> at boot time rather than doing sensible things when packages are
+> installed or removed.  Of course you can put all the pieces together,
+> but that was the point of binfmt-support.  This is straight
+> wheel-reinvention and it seems like a total waste of everyone's time.
+
+As above, I certainly disagree about including binfmt code being a waste
+of time; having to look at a separate project to get any support at all
+for something so simple would be a waste of time. Most likely supporting
+more features from binfmt-support would be an improvement, but that
+doesn't make having the current code a negative thing.
+
+I'm not sure whether including exact binfmt-support functionality would
+have been a reasonable option for systemd (GPL vs LGPL probably
+precludes code copy). At least the API would not be very consistent with
+other tools.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 05:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 05:06:04 GMT) (full text, mbox, link).

+ +

Message #1594 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 07:02:23 +0200
+
+
On Sat, 2013-12-28 at 17:24 -0800, Russ Allbery wrote:
+> * systemd synchronization support added via sd_notify.
+> * systemd socket activation support.
+
+Does sd_notify() actually give any positive effect compared to just
+using type=simple, given that you already have socket activation? The
+UDP socket should buffer packets until the daemon reads them. Explicit
+notify does have the negative effect that depending services can not be
+started in parallel.
+
+Or do you want to support running it as a systemd service but without
+using socket activation (would seem rather pointless)? You ship
+a .socket file by default, so it doesn't explain the use of type=notify
+in the provided file at least.
+
+I think the .service file should have a Requires= on the socket to make
+the service fail in case the socket could not be opened (probably
+doesn't matter otherwise). There's a typo "mutli-user.target".
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 05:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 05:33:05 GMT) (full text, mbox, link).

+ +

Message #1599 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sat, 28 Dec 2013 21:29:59 -0800
+
+
Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
+
+> Does sd_notify() actually give any positive effect compared to just
+> using type=simple, given that you already have socket activation? The
+> UDP socket should buffer packets until the daemon reads them. Explicit
+> notify does have the negative effect that depending services can not be
+> started in parallel.
+
+> Or do you want to support running it as a systemd service but without
+> using socket activation (would seem rather pointless)? You ship a
+> .socket file by default, so it doesn't explain the use of type=notify in
+> the provided file at least.
+
+The thought was the latter, combined with the intent to fully explore the
+whole systemd interface.  Also, there are situations where I believe that
+systemd will start the service without using socket activation even when
+socket activation is configured.  For example, if I disable both lbcd and
+lbcd.socket, and then manually start lbcd.service, lbcd.socket is not
+started, which I suspect means that socket activation is not used.
+
+None of those are particularly important, and I suspect that using socket
+activation is sufficient and synchronization isn't actually needed.  That
+said, I see no drawback to adding the sd_notify call to the upstream
+source; if people don't want to use socket activation, they can disable it
+in the unit file, and this way they don't have to use socket activation if
+they don't want to for some reason.  The code is so trivial to add
+(particularly if one is already using socket activation) that there
+doesn't seem to be a reason not to do it.
+
+Your point about depending services is a good one, though, and if this
+service is the sort of thing that anything else was likely to depend on,
+it would probably be better to just use socket activation with no
+synchronization if socket setup was all that was required.  Maybe I should
+just do that anyway; I'm probably reaching too hard for cases where the
+socket wouldn't be enabled.
+
+> I think the .service file should have a Requires= on the socket to make
+> the service fail in case the socket could not be opened (probably
+> doesn't matter otherwise).
+
+I think I misunderstood something I read in systemd.service(5) and thought
+it said not to do that, but it was talking about something different.
+That would probably also get rid of the case that I mentioned above.
+However, daemon(7) does say:
+
+    It is recommended to place a WantedBy=sockets.target directive in the
+    [Install] section, to automatically add such a dependency on
+    installation of a socket unit.  Unless DefaultDependencies=no is set
+    the necessary ordering dependencies are implicitly created for all
+    socket units.  For more information about sockets.target see
+    systemd.special(7).  It is not necessary or recommended to place any
+    additional dependencies on socket units (for example from
+    multi-user.target or suchlike) when one is installed in
+    sockets.target.
+
+I'm not entirely sure whether "any additional dependencies on socket
+units" is meant to imply that lbcd.service should not depend on
+lbcd.socket, or if that's just talking about the [Install] section of the
+socket file itself.
+
+Hm, reading daemon(7), I did mention this part:
+
+    Usually you also want to make sure that when your service is installed
+    your socket is installed too, hence add Also=foo.socket in your
+    service file foo.service, for a hypothetical program foo.
+
+I'll fix that, and that would also get rid of being able to independently
+enable or disable lbcd.service from lbcd.socket.
+
+> There's a typo "mutli-user.target".
+
+Huh, yes, indeed... ah, I see what happened.  I got this right when
+testing and then made a typo in the file in the package, so this was
+working on my test system.  Bleh.  I'll fix this in the Debian package.
+(I hate it when I upload four versions of a package within a day because I
+keep missing things.)
+
+Shouldn't there be a warning somewhere if a unit file specifies WantedBy
+on a target for which there's no *.target configuration installed?  Or is
+this intentional to allow systemd units written for other systems with
+different target naming conventions to be installed without trouble?
+(Still, some sort of lint program would be useful.)
+
+Thank you!
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 06:03:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 06:03:12 GMT) (full text, mbox, link).

+ +

Message #1604 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Cc: 726763@bugs.debian.org, 729576@bugs.debian.org, + systemd@packages.debian.org
+
Subject: Re: Bug#727708: systemd-shim uploaded to NEW
+
Date: Sun, 29 Dec 2013 01:00:10 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Dec 28, 2013 at 07:50:11PM -0800, Steve Langasek wrote:
+> I've just uploaded the systemd-shim package to the NEW queue.
+
+This package has been marked for ACCEPT. Please feel free to test it
+once dinstall runs and it gets sync'd to your local friendly mirror.
+
+Cheers,
+  Paul
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
+: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+`. `'`  http://people.debian.org/~paultag
+ `-     http://people.debian.org/~paultag/conduct-statement.txt
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 06:27:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 06:27:09 GMT) (full text, mbox, link).

+ +

Message #1609 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 08:22:48 +0200
+
+
On Sat, 2013-12-28 at 21:29 -0800, Russ Allbery wrote:
+> Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
+> > Does sd_notify() actually give any positive effect compared to just
+> > using type=simple, given that you already have socket activation? The
+> > UDP socket should buffer packets until the daemon reads them. Explicit
+> > notify does have the negative effect that depending services can not be
+> > started in parallel.
+> 
+> > Or do you want to support running it as a systemd service but without
+> > using socket activation (would seem rather pointless)? You ship a
+> > .socket file by default, so it doesn't explain the use of type=notify in
+> > the provided file at least.
+> 
+> The thought was the latter, combined with the intent to fully explore the
+> whole systemd interface.  Also, there are situations where I believe that
+> systemd will start the service without using socket activation even when
+> socket activation is configured.  For example, if I disable both lbcd and
+> lbcd.socket, and then manually start lbcd.service, lbcd.socket is not
+> started, which I suspect means that socket activation is not used.
+
+Adding the mentioned Requires=lbcd.socket line should ensure that the
+service is never started without the socket running. I'm quite sure that
+daemons intended to run under systemd should have no need to implement
+any socket-opening code themselves (unless they do something special
+like opening a socket in the middle of operation); anything which would
+contradict that should be a misunderstanding or a bug.
+
+
+> > I think the .service file should have a Requires= on the socket to make
+> > the service fail in case the socket could not be opened (probably
+> > doesn't matter otherwise).
+> 
+> I think I misunderstood something I read in systemd.service(5) and thought
+> it said not to do that, but it was talking about something different.
+> That would probably also get rid of the case that I mentioned above.
+> However, daemon(7) does say:
+> 
+>     It is recommended to place a WantedBy=sockets.target directive in the
+>     [Install] section, to automatically add such a dependency on
+>     installation of a socket unit.  Unless DefaultDependencies=no is set
+>     the necessary ordering dependencies are implicitly created for all
+>     socket units.  For more information about sockets.target see
+>     systemd.special(7).  It is not necessary or recommended to place any
+>     additional dependencies on socket units (for example from
+>     multi-user.target or suchlike) when one is installed in
+>     sockets.target.
+> 
+> I'm not entirely sure whether "any additional dependencies on socket
+> units" is meant to imply that lbcd.service should not depend on
+> lbcd.socket, or if that's just talking about the [Install] section of the
+> socket file itself.
+
+That wording really is unclear. I think it must mean the latter to make
+sense. Looking at the code, it seems that sockets automatically get a
+"Before:" dependency on identically named services, and the rarer
+explicit "Sockets:" in a .service file also adds "Wants:". So ordering
+should work by default, but a "Requires:" dependency must be explicit.
+I couldn't find where the automatic dependencies would be documented.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 06:33:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 06:33:10 GMT) (full text, mbox, link).

+ +

Message #1614 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sat, 28 Dec 2013 22:31:32 -0800
+
+
Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
+
+> Adding the mentioned Requires=lbcd.socket line should ensure that the
+> service is never started without the socket running. I'm quite sure that
+> daemons intended to run under systemd should have no need to implement
+> any socket-opening code themselves (unless they do something special
+> like opening a socket in the middle of operation); anything which would
+> contradict that should be a misunderstanding or a bug.
+
+Oh, good point, yes.  That's pretty clear from daemon(7), now that you
+mention it in that light.
+
+Okay, I'll take this approach in the next upload, after I get a chance to
+do some more experimentation with what that does with start and stop
+(probably tomorrow).
+
+Thank you for the review.  This was really helpful.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 09:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 09:15:04 GMT) (full text, mbox, link).

+ +

Message #1619 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 01:10:55 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Dec 28, 2013 at 10:31:32PM -0800, Russ Allbery wrote:
+> Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
+
+> > Adding the mentioned Requires=lbcd.socket line should ensure that the
+> > service is never started without the socket running. I'm quite sure that
+> > daemons intended to run under systemd should have no need to implement
+> > any socket-opening code themselves (unless they do something special
+> > like opening a socket in the middle of operation); anything which would
+> > contradict that should be a misunderstanding or a bug.
+
+> Oh, good point, yes.  That's pretty clear from daemon(7), now that you
+> mention it in that light.
+
+> Okay, I'll take this approach in the next upload, after I get a chance to
+> do some more experimentation with what that does with start and stop
+> (probably tomorrow).
+
+> Thank you for the review.  This was really helpful.
+
+However, I think this gets to the heart of why upstart upstream has avoided
+ever recommending the use of socket-based activation.  There are some fairly
+fundamental problems that basically halted development of socket-based
+activation in upstart (beyond merging of Scott's original implementation,
+which is rudimentary, as has been noted), and a look at systemd usage on
+Fedora led me to believe that systemd had not overcome these problems at
+all.
+
+If I'm not mistaken (no references to hand - sorry), systemd upstream has
+claimed in the course of discussions on debian-devel that lazy activation is
+not the purpose of socket-based activation, and that using socket-based
+activation does not require you to pay the service startup penalty at the
+time of first connection.  However, this is not borne out by my experiments
+with systemd on Fedora (which I would presume to be the go-to source for
+best practices of systemd service activation).
+
+On Fedora 20, after enabling the sshd and rsync service+socket units (both
+installed but disabled by default on Fedora per their policies on running
+services out-of-the-box) and rebooting, I find that both port 22 and port
+873 are bound by pid 1.  Only upon connecting to the socket does systemd
+actually spawn the server (in the case of sshd, it spawns it as 'sshd
+-i', so has to start up the server anew on each connection; in the case of
+rsyncd, the .service definition is completely incompatible with socket-based
+activation and any attempt to connect results in the rsyncd.socket unit
+landing in a 'failed' state).
+
+If what one is trying to accomplish here is to provide a replacement for
+inetd, then this is perfectly sufficient.  But if one is trying to use
+socket-based activation for the claimed purpose of ensuring service startup
+ordering without the need to declare explicit dependencies, then you must
+accept the penalty of lazy activation - which is almost never acceptable in
+a server context (where the purpose of the machine is to run the services
+that you have configured, and they should therefore not be started lazily),
+and suboptimal even in a client context (since not starting services that
+are on the critical path for boot until the client requests them will
+potentially lead to a significant boot-time slowdown, if all the services
+are doing this).
+
+As far as I've been able to tell, the only solutions that would allow
+non-lazy socket-based-activation of services in systemd all introduce
+significant boot-time races, whereby it is no longer assured that systemd
+will bind to the socket (and passing the socket information via the
+environemnt) before starting the service.  Indeed, when I looked at this
+problem on an earlier version of Fedora, I found what I believe to be a
+latent security problem in the cups units, because it was nondeterministic
+whether the service would start with sockets passed from systemd, or a
+different set of sockets as defined in the cups config!
+
+When I mentioned this to Lennart at DebConf this year, his response was that
+"cups was special".  Well, after further investigation, I don't think it's
+true that cups is special.  I think systemd socket-based activation is snake
+oil, that does not do what was promised without introducing hidden
+trade-offs which no one has been forced to acknowledge because too few
+developers are making use of this feature today to expose the integration
+problems.
+
+Of course, it's entirely possible that I've misunderstood something here, so
+I welcome your investigations with lbcd.  I'm very interested to see if your
+understanding of systemd socket-based activation best practices matches my
+own, and to have an opportunity to experiment with socket-based activation
+in the more relevant environment of Debian unstable rather than Fedora.
+
+FWIW, if indeed socket-based activation in systemd can't actually be used
+for anything besides a glorified inetd, I think that has implications for
+the discussion about daemon readiness protocols.  The argument for systemd
+seems to be "use sd_notify, or if you don't like having a library dependency
+then just use socket-based activation which is better anyway".  But I'm sure
+there will be upstreams who don't want lazy initialization any more than
+they want an external library dependency.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 09:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 09:33:05 GMT) (full text, mbox, link).

+ +

Message #1624 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 01:28:42 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Dec 28, 2013 at 05:24:57PM -0800, Russ Allbery wrote:
+
+> I'll have more to say about the relative merits of the two init systems
+> later, but one thing I wanted to not briefly: this exercise was extremely
+> valuable in helping me get a more realistic picture of both init systems.
+> I had gone into this exercise with the vague impression that they were
+> roughly at feature parity, and now realize that is not the case.
+
+> My impression now is that systemd's init and service management component
+> is a substantially more mature piece of software.  That's an odd thing to
+> say given that upstart is older, but systemd has the feel of software
+> that's been tested against a wide variety of different situations and has
+> had the necessary adaptations and configuration added to meet those needs.
+> In some cases, that's "simply" additional features; in some cases, that's
+> more comprehensive and more scalable design.  The socket activation system
+> in particular is night and day between the two systems.
+
+So to respond specifically to this point about the "night and day"
+difference between the socket-based activation systems: yes, upstart
+upstream has not invested in fleshing out its socket-based activation
+support, because earlier investigations led us to believe that socket-based
+activation is a red herring that will never deliver the promised benefits.
+
+The feature was made available for those who might prefer to start their
+services without the need for writing socket-handling code; but in my
+estimation, the flaws wrt system startup (which as far as I can see also
+affect the systemd implementation) make it altogether unsuitable for any
+services you're expecting to have started at boot, and we have deliberately
+avoided its use in Ubuntu.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 09:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 09:39:04 GMT) (full text, mbox, link).

+ +

Message #1629 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 01:35:01 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Dec 28, 2013 at 04:45:38PM -0800, Russ Allbery wrote:
+> After some more experimentation (the documentation doesn't say clearly
+> whether pre-start can expose environment variables to exec or not), it
+> looks like a better approach is:
+
+>     expect stop
+
+>     pre-start script
+>         test -x /usr/sbin/lbcd || { stop; exit 0; }
+>         if [ -f /etc/default/lbcd ] ; then 
+>             . /etc/default/lbcd
+>         fi
+>     end script
+
+>     # To change the default lbcd service, specify a command to run for the
+>     # weight and interval, or do round-robin (-R), set the desired flags
+>     # in DAEMON_OPTS in /etc/default/lbcd.
+>     exec /usr/sbin/lbcd -f -l -Z $DAEMON_OPTS
+
+> This seems to work and is what I will be uploading.
+
+Hmm, It seems to not be what you uploaded in practice... which stands to
+reason, since in fact no, the pre-start script cannot export environment
+variables to the main process (for standard unixy reasons - upstart doesn't
+do anything magical here to try to tie the process environments together, so
+when the pre-start script exits, its environment goes with it.  This could
+be documented better).  I guess you figured this out after having written
+this mail?
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 09:39:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Raphael Hertzog <hertzog@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 09:39:07 GMT) (full text, mbox, link).

+ +

Message #1634 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Raphael Hertzog <hertzog@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Sun, 29 Dec 2013 10:36:28 +0100
+
+
Hi,
+
+On Sat, 28 Dec 2013, Ian Jackson wrote:
+> It does, however, have a number of missing features.  Those I have in
+> mind are:
+>   - ability to log daemon output to syslog
+>   - multiple socket activation (systemd socket activation protocol)
+>   - socket activation for IPv6 (and datagram sockets)
+> 
+> Of these Russ rightly points out that lack of IPv6 support is rather
+> poor; it is arguably not suitable for release in jessie without this.
+> 
+> However, crucially, these are all simple matters of programming,
+> without difficult design decisions.  They IMO don't reveal structural
+> problems with upstart's approach to things.
+
+This is pretty much in opposition with the way that the tech-ctte has
+approached problems in the past. In used to only decide based on existing
+code that was ready to be deployed.
+
+This is troublesome because, in my eyes, you now look very much like the
+systemd fanboys that you criticize, except that you are in the upstart
+camp.
+
+Cheers,
+-- 
+Raphaël Hertzog ◈ Debian Developer
+
+Discover the Debian Administrator's Handbook:
+→ http://debian-handbook.info/get/
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 09:54:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 09:54:05 GMT) (full text, mbox, link).

+ +

Message #1639 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd and upstart, a view from a daemon Debian + maintainer
+
Date: Sun, 29 Dec 2013 01:51:50 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Dec 28, 2013 at 03:56:49PM -0800, Russ Allbery wrote:
+> > Also, the approach to the systemd integration introduces a new runtime
+> > package dependency on "init-system-helpers", which despite its
+> > generic-sounding name actually contains only helpers for systemd and is
+> > maintained in Debian by the systemd maintainers.
+
+> The maintainers of the package have openly offered any other useful
+> helpers for any other init systems a home in that package.  I think it's
+> more due to an accident of history and existing usage that the bit of
+> necessary supporting glue for upstart ended up in lsb-base instead of
+> init-system-helpers.
+
+I acknowledge the maintainers' offer in the spirit it was intended, but I
+see no reason at all that upstart needs to add any glue code to the
+init-system-helpers package.  The only outstanding integrations we would
+want to make are to have upstart automatically divert init scripts without
+the need for maintainers to edit each init script individually; and that's a
+change that should be made in the upstart package itself, not in a generic
+helper package.
+
+I also think that the extensive maintainer script changes required for any
+upstart-using package are quite deplorable (whether or not they're wrapped
+in a helper script + debhelper snippet).  I understand the reasons why a
+trigger is unsuitable given that the systemd package may not be installed,
+but I am of the firm opinion (having had it beaten into me by years of
+dealing with the resulting bugs) that the best maintainer script is the
+non-existent one, and I think this added maintainer script complexity is a
+move in the wrong direction.  If Debian adopts systemd as the default, I
+would hope to see these maintainer script snippets disappear in favor of a
+trigger, or rolled into the update-rc.d script which is already being
+called.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 10:24:03 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 10:24:04 GMT) (full text, mbox, link).

+ +

Message #1644 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 11:21:07 +0100
+
+
Le dimanche 29 décembre 2013 à 01:10 -0800, Steve Langasek a écrit : 
+> If I'm not mistaken (no references to hand - sorry), systemd upstream has
+> claimed in the course of discussions on debian-devel that lazy activation is
+> not the purpose of socket-based activation, and that using socket-based
+> activation does not require you to pay the service startup penalty at the
+> time of first connection.  However, this is not borne out by my experiments
+> with systemd on Fedora (which I would presume to be the go-to source for
+> best practices of systemd service activation).
+> 
+> On Fedora 20, after enabling the sshd and rsync service+socket units (both
+> installed but disabled by default on Fedora per their policies on running
+> services out-of-the-box) and rebooting, I find that both port 22 and port
+> 873 are bound by pid 1.  Only upon connecting to the socket does systemd
+> actually spawn the server (in the case of sshd, it spawns it as 'sshd
+> -i', so has to start up the server anew on each connection; in the case of
+> rsyncd, the .service definition is completely incompatible with socket-based
+> activation and any attempt to connect results in the rsyncd.socket unit
+> landing in a 'failed' state).
+
+I’m not sure you can conclude that socket activation is broken from such
+investigations. It looks to me that: 
+      * Fedora deliberately used an inetd-like sshd setup, which is more
+        suitable for a workstation to which you don’t ssh much, but not
+        for a production server. 
+      * You found a bug in Fedora’s rsyncd unit files.
+
+If you don’t want lazy activation, you just need to add a
+WantedBy=multi-user.target. This way, sockets will be bound by systemd
+at the earliest possible time, and passed to the daemon as it is
+started, but it will be started regardless of an incoming connection.
+
+This is described in more detailed in the “systemd for administrators”
+series:
+http://0pointer.de/blog/projects/socket-activation2.html
+
+-- 
+ .''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 14:03:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 14:03:12 GMT) (full text, mbox, link).

+ +

Message #1649 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd vs. binfmt-support
+
Date: Sun, 29 Dec 2013 14:02:25 +0000
+
+
On Sun, Dec 29, 2013 at 05:56:30AM +0200, Uoti Urpala wrote:
+> On Thu, 2013-12-26 at 21:42 +0000, Colin Watson wrote:
+> > The first reason is, I suppose, rather selfish: I've been working on
+> > this on and off for fourteen years and it seems a bit rude for systemd
+> > to turn up and declare that it's now the standard on the strength of an
+> > underpowered implementation, without even mentioning it to me (I'll
+> > accept that this is irrational since the systemd authors probably
+> > weren't aware of the prior art, but it's certainly my gut reaction).  I
+> 
+> I don't think systemd authors have made any declarations about binfmt in
+> particular. The only thing they've actually done is add a very simple
+> implementation (src/binfmt/binfmt.c, less than 200 lines of code, much
+> of it argument parsing). I consider having a basic implementation to be
+> a useful "batteries included" feature: systemd supports lots of
+> different setups from embedded to desktop, and it's useful to have at
+> least a basic implementation ready when building a system. It's easy
+> enough to override if you want something different.
+
+I agree with this part.  My comments above were imprecisely phrased,
+sorry (though I did flag them as a gut reaction); I'm mainly referring
+to the end result for Debian.
+
+> Thus I consider any opinions saying systemd should not include a tool
+> for setting binfmt, or that adding it was somehow objectionable
+> behavior, to be wrong.
+
+I was referring more to Tollef's position, really.  Debian systemd
+maintenance ought to take into account matters of Debian integration,
+which includes whether it fits well into best-of-breed Debian practice.
+
+If it's easy enough to override, then given that we have a better
+implementation in Debian then we should simply continue to use it.
+
+> I think this has been proven false by experience - systemd has innovated
+> a lot in things where smaller projects were stagnant. And there's a
+> fairly clear reason why this would be so: something like binfmt-support
+> is too small a unit for independent development, both to design
+> independently and to "sell" to every user individually.
+
+It's simply not true that it's too small a unit for independent
+development (what on earth gives you the authority to pronounce on this,
+please, given that I've been independently developing it and working
+with the people who consume it directly for much longer than systemd's
+been around?).  Besides, this is a red herring; there's no need to sell
+it to every user individually, only to distributions complex enough for
+it to be worth it, maybe half a dozen conversations.  Typical users get
+it by way of dependencies or similar.
+
+> Binfmt support is not that complex a task in itself. In practice, a lot
+> of the usability will depend on consistency with other system parts.
+> Designing APIs for it only is too narrow a view; you need to consider
+> other tools, and if you can do better, then it's quite likely you should
+> change the other tools too (things like adding udev rules etc).
+
+However, I've been thinking about this for rather a long time, and I'm
+actually quite familiar with the design issues.  binfmt-support is
+specifically designed to be suitable for distributions (not just Debian)
+shipping binfmt integration; in particular I have put much more effort
+than systemd has into how it fits into packaging.
+
+> Convincing every distro builder out there individually that your binfmt
+> support code is best wastes effort, both yours and theirs. It's more
+> efficient to have systemd upstream decide what is a reasonable default
+> implementation, and then have only people with specific needs or
+> opinions change it.
+
+This sounds very much like an argument from authority, and I'm afraid I
+don't subscribe to it.  I don't consider my effort wasted, and I don't
+consider it wasted effort for other distributions to take improved code
+either; nor do I think that something really not particularly tied to
+the init system needs to be developed under the systemd umbrella.
+
+Cheers,
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 15:18:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 15:18:09 GMT) (full text, mbox, link).

+ +

Message #1654 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Sun, 29 Dec 2013 16:15:17 +0100
+
+
]] Ian Jackson 
+
+> This is exacerbated by the fact that systemd's Debian maintainers are
+> (IMO) much too deferential to upstream.
+
+That's because the bits of systemd you've asked to change isn't just a
+piece of software.  It's a standardised API, and you're effectively
+asking us to change that API.  I think it's pretty clear why that is a
+bad idea.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 15:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 15:36:04 GMT) (full text, mbox, link).

+ +

Message #1659 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Sun, 29 Dec 2013 16:32:13 +0100
+
+
]] Ian Jackson 
+
+> As the upstream author of a daemon I'm
+>  - not willing to add a library dependency for this
+>  - not willing to write a 50-100 lines of tiresome socket code for this
+>  - not willing to copy the library file into my source tree
+> so the result is that userv upstream won't support systemd's readiness
+> protocol.
+
+Lennart provided http://fpaste.org/64821/32737713/ as a pretty minimal
+example of sd_notify which implements it in 18 lines of code.  It lacks
+a little bit of error handling, but even with that, it's hardly 50-100
+lines of tiresome socket code.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 16:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 16:57:04 GMT) (full text, mbox, link).

+ +

Message #1664 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 18:55:33 +0200
+
+
On Sun, 2013-12-29 at 01:10 -0800, Steve Langasek wrote:
+> However, I think this gets to the heart of why upstart upstream has avoided
+> ever recommending the use of socket-based activation.  There are some fairly
+> fundamental problems that basically halted development of socket-based
+> activation in upstart (beyond merging of Scott's original implementation,
+> which is rudimentary, as has been noted), and a look at systemd usage on
+> Fedora led me to believe that systemd had not overcome these problems at
+> all.
+
+As far as I can see, what you're saying here is 100% based on
+misconceptions only, and has no connection to any real issues
+whatsoever.
+
+
+> If I'm not mistaken (no references to hand - sorry), systemd upstream has
+> claimed in the course of discussions on debian-devel that lazy activation is
+> not the purpose of socket-based activation, and that using socket-based
+> activation does not require you to pay the service startup penalty at the
+> time of first connection.
+
+Yes, this is true. If you have a daemon configured to always start, and
+then add a .socket unit for socket activation, this does not in any way
+STOP the daemon from starting!
+
+Any mechanism that directly starts a .service will continue to do so
+regardless of the existence of a .socket. What a .socket adds is that
+you can have the socket active while the service is inactive, and in
+this state an incoming connection to the active socket will trigger
+start of the service. Other services which make requests through the
+socket can depend on the .socket only (as opposed to directly depending
+on the .service) to allow this state.
+
+
+> On Fedora 20, after enabling the sshd and rsync service+socket units (both
+> installed but disabled by default on Fedora per their policies on running
+> services out-of-the-box) and rebooting, I find that both port 22 and port
+> 873 are bound by pid 1.  Only upon connecting to the socket does systemd
+> actually spawn the server (in the case of sshd, it spawns it as 'sshd
+> -i', so has to start up the server anew on each connection; in the case of
+> rsyncd, the .service definition is completely incompatible with socket-based
+> activation and any attempt to connect results in the rsyncd.socket unit
+> landing in a 'failed' state).
+
+Assuming this is an accurate description, it sounds like an intentional
+decision for ssh and a bug in rsyncd (as Josselin already said).
+
+
+> If what one is trying to accomplish here is to provide a replacement for
+> inetd, then this is perfectly sufficient.  But if one is trying to use
+> socket-based activation for the claimed purpose of ensuring service startup
+> ordering without the need to declare explicit dependencies, then you must
+> accept the penalty of lazy activation - which is almost never acceptable in
+> a server context (where the purpose of the machine is to run the services
+> that you have configured, and they should therefore not be started lazily),
+> and suboptimal even in a client context (since not starting services that
+> are on the critical path for boot until the client requests them will
+> potentially lead to a significant boot-time slowdown, if all the services
+> are doing this).
+
+As above, your belief that systemd would force lazy activation has no
+basis in reality that I can see.
+
+
+> As far as I've been able to tell, the only solutions that would allow
+> non-lazy socket-based-activation of services in systemd all introduce
+> significant boot-time races, whereby it is no longer assured that systemd
+> will bind to the socket (and passing the socket information via the
+> environemnt) before starting the service.  Indeed, when I looked at this
+> problem on an earlier version of Fedora, I found what I believe to be a
+> latent security problem in the cups units, because it was nondeterministic
+> whether the service would start with sockets passed from systemd, or a
+> different set of sockets as defined in the cups config!
+> 
+> When I mentioned this to Lennart at DebConf this year, his response was that
+> "cups was special".  Well, after further investigation, I don't think it's
+> true that cups is special.  I think systemd socket-based activation is snake
+> oil, that does not do what was promised without introducing hidden
+> trade-offs which no one has been forced to acknowledge because too few
+> developers are making use of this feature today to expose the integration
+> problems.
+
+If foo.service has "Requires=foo.socket", then on general principles it
+would sound like a very obvious bug if the service ever starts without
+foo.socket active. I'd like to hear of some evidence of such a bug
+before taking it seriously. And even if such a bug somehow existed,
+fixing it should be a straightforward bugfix.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 18:06:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 18:06:08 GMT) (full text, mbox, link).

+ +

Message #1669 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 10:04:17 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+> On Sat, Dec 28, 2013 at 04:45:38PM -0800, Russ Allbery wrote:
+
+>> After some more experimentation (the documentation doesn't say clearly
+>> whether pre-start can expose environment variables to exec or not), it
+>> looks like a better approach is:
+
+>>     expect stop
+
+>>     pre-start script
+>>         test -x /usr/sbin/lbcd || { stop; exit 0; }
+>>         if [ -f /etc/default/lbcd ] ; then 
+>>             . /etc/default/lbcd
+>>         fi
+>>     end script
+
+>>     # To change the default lbcd service, specify a command to run for the
+>>     # weight and interval, or do round-robin (-R), set the desired flags
+>>     # in DAEMON_OPTS in /etc/default/lbcd.
+>>     exec /usr/sbin/lbcd -f -l -Z $DAEMON_OPTS
+
+>> This seems to work and is what I will be uploading.
+
+> Hmm, It seems to not be what you uploaded in practice... which stands to
+> reason, since in fact no, the pre-start script cannot export environment
+> variables to the main process (for standard unixy reasons - upstart
+> doesn't do anything magical here to try to tie the process environments
+> together, so when the pre-start script exits, its environment goes with
+> it.  This could be documented better).  I guess you figured this out
+> after having written this mail?
+
+Yes, indeed, sorry, that's correct.  This is the mail message that got
+stuck behind the buggy virus definition, and I forgot to go back and
+update it with the current results.  What I uploaded went back to using a
+script for the whole thing:
+
+    pre-start script
+        test -x /usr/sbin/lbcd || { stop; exit 0; }
+    end script
+    
+    # To change the default lbcd service, specify a command to run for the
+    # weight and interval, or do round-robin (-R), add the flags to
+    # DAEMON_OPTS in /etc/default/lbcd.  This will ensure consistent
+    # behavior across all init systems.
+    script
+        if [ -f /etc/default/lbcd ] ; then
+            . /etc/default/lbcd
+        fi
+        exec /usr/sbin/lbcd -f -l -Z $DAEMON_OPTS
+    end script
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 18:39:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 18:39:05 GMT) (full text, mbox, link).

+ +

Message #1674 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 10:37:03 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sun, Dec 29, 2013 at 11:21:07AM +0100, Josselin Mouette wrote:
+> Le dimanche 29 décembre 2013 à 01:10 -0800, Steve Langasek a écrit : 
+> > If I'm not mistaken (no references to hand - sorry), systemd upstream has
+> > claimed in the course of discussions on debian-devel that lazy activation is
+> > not the purpose of socket-based activation, and that using socket-based
+> > activation does not require you to pay the service startup penalty at the
+> > time of first connection.  However, this is not borne out by my experiments
+> > with systemd on Fedora (which I would presume to be the go-to source for
+> > best practices of systemd service activation).
+
+> > On Fedora 20, after enabling the sshd and rsync service+socket units (both
+> > installed but disabled by default on Fedora per their policies on running
+> > services out-of-the-box) and rebooting, I find that both port 22 and port
+> > 873 are bound by pid 1.  Only upon connecting to the socket does systemd
+> > actually spawn the server (in the case of sshd, it spawns it as 'sshd
+> > -i', so has to start up the server anew on each connection; in the case of
+> > rsyncd, the .service definition is completely incompatible with socket-based
+> > activation and any attempt to connect results in the rsyncd.socket unit
+> > landing in a 'failed' state).
+
+> I’m not sure you can conclude that socket activation is broken from such
+> investigations. It looks to me that: 
+>       * Fedora deliberately used an inetd-like sshd setup, which is more
+>         suitable for a workstation to which you don’t ssh much, but not
+>         for a production server. 
+>       * You found a bug in Fedora’s rsyncd unit files.
+
+> If you don’t want lazy activation, you just need to add a
+> WantedBy=multi-user.target. This way, sockets will be bound by systemd
+> at the earliest possible time, and passed to the daemon as it is
+> started, but it will be started regardless of an incoming connection.
+
+> This is described in more detailed in the “systemd for administrators”
+> series:
+> http://0pointer.de/blog/projects/socket-activation2.html
+
+It's quite possible that I am doing something wrong, but I don't think this
+is it.  Each of the .service units in question already had
+'WantedBy=multi-user.target', and each of the .socket units had
+'WantedBy=sockets.target'; on Fedora these were all disabled by default (to
+avoid any open ports by default), but upon enabling both the service and
+socket units, I get the behavior described.
+
+I was seeing the same behavior with the lbcd package in Debian, but it turns
+out this is due to the 'mutli-user' typo in lbcd.service.  Once I've fixed
+this (and created the proper 'enabled' symlink), I do see the lbcd process
+being started at boot.  So that much does seem to work as described, on
+Debian.  I'm not sure what to make of the Fedora setup, then, because other
+services that are linked into /etc/systemd/system/multi-user.target.wants do
+start up at boot, but neither sshd nor rsyncd is started when the .socket is
+enabled.  In that case, my concern is a different one - how can anyone claim
+that systemd's socket activation is ready for prime time if even a service
+as important as sshd hasn't been debugged in Fedora, one of the flagship
+adopters of systemd?  (BTW, there's also both an sshd.service and an
+sshd@.service here, adding to the confusion.  I've attached all of the sshd
+units in case you want to look at them.)
+
+This still leaves the concern I have about start-time races.  According to
+systemd.unit(5), using 'Requires=', as Uoti suggested to Russ, does *not*
+guarantee ordering:
+
+  Note that requirement dependencies do not influence the order in which
+  services are started or stopped.  This has to be configured independently
+  with the After= or Before= options.  If a unit foo.service requires a unit
+  bar.service as configured with Requires= and no ordering is configured
+  with After= or Before=, then both units will be started simultaneously and
+  without any delay between them if foo.service is activated.
+
+In my earlier investigations (which were on Fedora 17, IIRC), I definitely
+found races where a service configured with a corresponding .socket would
+*sometimes* start at boot time before the socket is bound, causing it to
+fall back to its own config file and binding to its own sockets... which
+could result in a completely different set of sockets being bound, and
+potentially introducing an unexpected security hole if the admin isn't
+diligently keeping the two implementations in sync.  Since
+LISTEN_FDS/LISTEN_PID is the defined API for systemd passing the socket
+information to the service, for systemd to ever fail to pass this socket
+information, resulting in the service deciding that it's not *actually*
+running under systemd and should fall back to a different mode, is
+potentially a very serious problem.
+
+Of course, it's possible that this has been fixed in systemd since the last
+time I looked.  I'll try to set up a reproducible test case for
+consideration.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[sshd.service (text/plain, attachment)]
+
[sshd@.service (text/plain, attachment)]
+
[sshd.socket (text/plain, attachment)]
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 18:39:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 18:39:08 GMT) (full text, mbox, link).

+ +

Message #1679 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 10:37:10 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> If I'm not mistaken (no references to hand - sorry), systemd upstream
+> has claimed in the course of discussions on debian-devel that lazy
+> activation is not the purpose of socket-based activation, and that using
+> socket-based activation does not require you to pay the service startup
+> penalty at the time of first connection.  However, this is not borne out
+> by my experiments with systemd on Fedora (which I would presume to be
+> the go-to source for best practices of systemd service activation).
+
+My understanding (not having looked at Fedora at all myself) is that
+rsyslog would be a better choice of package to look at.  It sounds like
+both of the packages you chose are inappropriate examples; for ssh, Fedora
+made an intentional choice to use inet-style activation, and for rsync, it
+sounds like the conversion is incomplete or untested.
+
+> As far as I've been able to tell, the only solutions that would allow
+> non-lazy socket-based-activation of services in systemd all introduce
+> significant boot-time races, whereby it is no longer assured that
+> systemd will bind to the socket (and passing the socket information via
+> the environemnt) before starting the service.
+
+I don't see any reason why this would be the case, although it does point
+out that I got my original implementation wrong in the ways that Uoti
+pointed out, and some additional documentation would be helpful.
+
+If the service is configured to use socket activation, it should depend on
+the corresponding socket unit (and in general, unless there is other
+necessary initialization beyond binding a socket, use Type=simple), at
+which point I don't see any reason why there would be boot-time races.
+Even if it doesn't, my understanding is that the socket target is started
+before any of the services in multi-user.target, so there still shouldn't
+be a problem.  (But the explicit dependency seems like better form.)
+
+> Indeed, when I looked at this problem on an earlier version of Fedora, I
+> found what I believe to be a latent security problem in the cups units,
+> because it was nondeterministic whether the service would start with
+> sockets passed from systemd, or a different set of sockets as defined in
+> the cups config!
+
+Did the cups service unit explicitly depend on its socket unit?
+
+> Of course, it's entirely possible that I've misunderstood something
+> here, so I welcome your investigations with lbcd.  I'm very interested
+> to see if your understanding of systemd socket-based activation best
+> practices matches my own, and to have an opportunity to experiment with
+> socket-based activation in the more relevant environment of Debian
+> unstable rather than Fedora.
+
+Uoti's reply to your message matches my experience.  I just rebooted the
+system on which I've been experimenting (after fixing the typo in the
+current unit file!), and here is the output from systemctl status lbcd
+immediately after boot:
+
+lbcd.service - responder for load balancing
+   Loaded: loaded (/lib/systemd/system/lbcd.service; enabled)
+   Active: active (running) since Sun 2013-12-29 10:20:19 PST; 57s ago
+     Docs: man:lbcd(8)
+           http://www.eyrie.org/~eagle/software/lbcd/
+ Main PID: 886 (lbcd)
+   CGroup: name=systemd:/system/lbcd.service
+           └─886 /usr/sbin/lbcd -f -l
+
+Dec 29 10:20:19 wanderer systemd[1]: Started responder for load balancing.
+Dec 29 10:20:19 wanderer lbcd[886]: ready to accept requests
+
+As you can see, lbcd was started immediately on boot and passed its
+socket.  I also confirmed with netstat that the socket was bound by
+systemd, not by the lbcd daemon.  So this all seems to be working the way
+I would expect, and is not lazy.
+
+One could of course make it lazy by not starting lbcd in the multi-user
+target, and I could see some circumstances where that would be useful, but
+that's not the default behavior.
+
+This does indeed not work correctly with the version of lbcd in the
+archive, but that's just due to my errors, specifically the typo in the
+WantedBy configuration.  I'll be making another upload later today fixing
+the issues that Uoti identified.  (This is the sort of thing that we would
+want to document in Policy.)
+
+I don't see any signs that the problems you're worried about are present.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 19:03:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 19:03:05 GMT) (full text, mbox, link).

+ +

Message #1684 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 11:01:15 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> This still leaves the concern I have about start-time races.  According
+> to systemd.unit(5), using 'Requires=', as Uoti suggested to Russ, does
+> *not* guarantee ordering:
+
+>   Note that requirement dependencies do not influence the order in which
+>   services are started or stopped.  This has to be configured
+>   independently with the After= or Before= options.  If a unit
+>   foo.service requires a unit bar.service as configured with Requires=
+>   and no ordering is configured with After= or Before=, then both units
+>   will be started simultaneously and without any delay between them if
+>   foo.service is activated.
+
+Well, one can certainly add a Before= stanza to the socket file to resolve
+this.  However, whether this is necessary again revolves around the
+interpretation of a few bits of unclear documentation.  My understanding
+from the documentation is that all of sockets.target is always started
+before any services that are part of multi-user.target, so there's no need
+for these explicit dependencies.
+
+And, indeed, that appears to be correct given the contents of the various
+target files.  multi-user.target depends (with After=) on basic.target,
+which in turn depends (with After=) on sockets.target.  sockets.target
+happens very early in the boot.  I think you only have to worry about this
+ordering if you're writing an early-boot service unit that will be started
+before basic.target for some reason.
+
+It would, however, be nice if this were more clearly stated, since the
+guidance to the author of the unit file about what dependencies one should
+or should not explicitly add is a bit sparse.  In particular, I wonder if
+there is an implicit After= dependency in a service unit on a socket unit
+of the same name (which would make sense given how Sockets= works), or if
+that's something that one should explicitly add.
+
+I should note that I think Uoti's point about Requires= is more about
+ensuring that one can't create weird situations where the socket is
+inactive but the daemon is active, which I was able to create in testing
+because I didn't have that setting.  I can confirm that adding Requires=
+now does the right thing: if the socket is explicitly stopped, the service
+is stopped as well, and if the service is then started, the socket is also
+started first.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 20:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 20:15:04 GMT) (full text, mbox, link).

+ +

Message #1689 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 22:12:21 +0200
+
+
On Sun, 2013-12-29 at 10:37 -0800, Steve Langasek wrote:
+> It's quite possible that I am doing something wrong, but I don't think this
+> is it.  Each of the .service units in question already had
+> 'WantedBy=multi-user.target', and each of the .socket units had
+> 'WantedBy=sockets.target'; on Fedora these were all disabled by default (to
+> avoid any open ports by default), but upon enabling both the service and
+> socket units, I get the behavior described.
+> 
+> I was seeing the same behavior with the lbcd package in Debian, but it turns
+> out this is due to the 'mutli-user' typo in lbcd.service.  Once I've fixed
+> this (and created the proper 'enabled' symlink), I do see the lbcd process
+> being started at boot.  So that much does seem to work as described, on
+> Debian.  I'm not sure what to make of the Fedora setup, then, because other
+> services that are linked into /etc/systemd/system/multi-user.target.wants do
+> start up at boot, but neither sshd nor rsyncd is started when the .socket is
+> enabled.
+
+Enabling .socket is only supposed to start the socket, and the daemon
+only if a connection arrives. If you want the daemon to start
+unconditionally, you should enable the .service, not just the .socket.
+
+>   In that case, my concern is a different one - how can anyone claim
+> that systemd's socket activation is ready for prime time if even a service
+> as important as sshd hasn't been debugged in Fedora, one of the flagship
+> adopters of systemd?
+
+What makes you think it is buggy? So far I have seen no clear indication
+of any bugs, only use of per-connection daemon instances which you
+didn't like. And even if there were bugs, it is fairly easy to imagine
+how an ssh maintainer could break it in one release independent of any
+systemd issues.
+
+
+>   (BTW, there's also both an sshd.service and an
+> sshd@.service here, adding to the confusion.  I've attached all of the sshd
+> units in case you want to look at them.)
+
+Those look like there are alternative units for a persistent daemon and
+a per-connection daemon used with an "Accept=true" socket. The
+sshd.service one is persistent and does not use socket activation. The
+sshd@.service is a per-connection one instantiated for each connection
+to sshd.socket. You're probably supposed to enable either sshd.socket
+(for per-connection daemons) or sshd.service (for a persistent daemon).
+
+
+> This still leaves the concern I have about start-time races.  According to
+> systemd.unit(5), using 'Requires=', as Uoti suggested to Russ, does *not*
+> guarantee ordering:
+
+but as I said at the end of
+https://lists.debian.org/debian-ctte/2013/12/msg00206.html
+there's an automatic "Before:" dependency created from sockets to
+identically named services. So it shouldn't be necessary to give it
+explicitly.
+
+> In my earlier investigations (which were on Fedora 17, IIRC), I definitely
+> found races where a service configured with a corresponding .socket would
+> *sometimes* start at boot time before the socket is bound, causing it to
+> fall back to its own config file and binding to its own sockets... which
+
+I'm not sure if some parts of the behavior have differed before. At
+least the code setting the default dependencies has not stayed exactly
+the same; I didn't try to find out whether the behavior has actually
+changed.
+
+Even with current systemd you could probably produce such behavior with
+suitable configuration - at least if you do NOT add a "Requires=" and
+create an "early boot" service that can run before sockets.target.
+
+> diligently keeping the two implementations in sync.  Since
+> LISTEN_FDS/LISTEN_PID is the defined API for systemd passing the socket
+> information to the service, for systemd to ever fail to pass this socket
+> information, resulting in the service deciding that it's not *actually*
+> running under systemd and should fall back to a different mode, is
+> potentially a very serious problem.
+
+If you want to make sure your service never tries to start without
+socket activation, it should have Requires=foo.socket; none of the
+default relations are strong enough to strictly prohibit starting
+without a socket. I think at least the case where creating the socket
+fails and admin manually says "systemctl start foo.service" would always
+start the service without a socket otherwise.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 20:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 20:27:04 GMT) (full text, mbox, link).

+ +

Message #1694 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 12:23:27 -0800
+
+
Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
+
+> but as I said at the end of
+> https://lists.debian.org/debian-ctte/2013/12/msg00206.html there's an
+> automatic "Before:" dependency created from sockets to identically named
+> services. So it shouldn't be necessary to give it explicitly.
+
+Ah!  You did say this, and I forgot.  Thank you, that answers my remaining
+question about the dependency ordering.  It would be good to get this
+explicitly documented somewhere.
+
+I should probably open a bug on systemd for the documentation issues we
+discussed during this thread.
+
+> If you want to make sure your service never tries to start without
+> socket activation, it should have Requires=foo.socket; none of the
+> default relations are strong enough to strictly prohibit starting
+> without a socket. I think at least the case where creating the socket
+> fails and admin manually says "systemctl start foo.service" would always
+> start the service without a socket otherwise.
+
+Yes, that matches my experience.  Adding Requires= fixed that case.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 21:09:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 21:09:09 GMT) (full text, mbox, link).

+ +

Message #1699 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 22:05:17 +0100
+
+
]] Russ Allbery 
+
+> It would, however, be nice if this were more clearly stated, since the
+> guidance to the author of the unit file about what dependencies one should
+> or should not explicitly add is a bit sparse.  In particular, I wonder if
+> there is an implicit After= dependency in a service unit on a socket unit
+> of the same name (which would make sense given how Sockets= works), or if
+> that's something that one should explicitly add.
+
+http://www.freedesktop.org/software/systemd/man/bootup.html has some
+graphs.  In addition, as long as your service is not doing anything in
+the early boot, DefaultDependencies will be true and you'll have an
+After=basic.target in your service.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 21:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 21:21:04 GMT) (full text, mbox, link).

+ +

Message #1704 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 13:18:00 -0800
+
+
Tollef Fog Heen <tfheen@err.no> writes:
+
+> ]] Russ Allbery 
+
+>> It would, however, be nice if this were more clearly stated, since the
+>> guidance to the author of the unit file about what dependencies one should
+>> or should not explicitly add is a bit sparse.  In particular, I wonder if
+>> there is an implicit After= dependency in a service unit on a socket unit
+>> of the same name (which would make sense given how Sockets= works), or if
+>> that's something that one should explicitly add.
+
+> http://www.freedesktop.org/software/systemd/man/bootup.html has some
+> graphs.  In addition, as long as your service is not doing anything in
+> the early boot, DefaultDependencies will be true and you'll have an
+> After=basic.target in your service.
+
+This by itself doesn't fully replace the implicit dependency.  It ensures
+ordering is correct for boot, but not that ordering is correct when
+starting deactivated services, where the service startup is not happening
+in the context of target processing.  (Unless target processing happens in
+more places than I think it does.)
+
+It sounds, from Uoti's investigations, that the code also directly adds an
+implicit dependency, which would ensure correct behavior in those cases as
+well.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 21:21:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 21:21:07 GMT) (full text, mbox, link).

+ +

Message #1709 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd vs. binfmt-support
+
Date: Sun, 29 Dec 2013 17:30:24 +0100
+
+
]] Colin Watson 
+
+> On Thu, Dec 26, 2013 at 08:49:11AM +0100, Tollef Fog Heen wrote:
+> > > As I explain in the bug [1], I think that the facilities provided by
+> > > binfmt-support are objectively superior; and even if they were broadly
+> > > equivalent, I'd still question the utility of converting packages from
+> > > an interface that's been well-established in Debian for over ten years.
+> > > 
+> > > What is the systemd maintainers' position on this bug?  I bring it up
+> > > here mainly because it's an interesting example of integration.  Tollef
+> > > said during the committee's last meeting on IRC that he hadn't thought
+> > > much about binfmt before, so perhaps this is just a loose end.
+> > 
+> > binfmt-support is, AFAIK, only used in Debian and derivatives and in
+> > general, I think having tools that are used across the ecosystem is more
+> > valuable than having tools that are only used for parts of the
+> > ecosystem.
+> 
+> Arch uses binfmt-support as well, I believe (and now I search for it I
+> see that it also ships systemd configuration for it, which will be
+> useful).  I admit that I haven't put much effort into evangelising it,
+> but there's nothing especially Debian-specific about binfmt-support and
+> it ought to be trivial to make it work elsewhere.
+
+Correction wrt Arch accepted, and I wasn't trying to imply it was
+Debian-specific, merely that it is used in Debian and derivatives.
+
+[...]
+
+> Given that binfmt-support is doing a better job, my preference would be
+> to put a small amount of work into making it more clearly an independent
+> upstream project, and simply get more distributions using it.  Doing
+> Fedora, Gentoo, and openSUSE would cover most of the bases.  Now that
+> I'm aware of the effort being wasted on reinvention, I can move that
+> sort of thing further up my list.
+
+Great, if it becomes the standard in all those distros, I'm fairly sure
+systemd will deprecate or drop the binfmt support there.  I'll hold off
+on asking upstream for any support for the more advanced features that
+binfmt-support offers, then.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 22:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 22:21:04 GMT) (full text, mbox, link).

+ +

Message #1714 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: 727708@bugs.debian.org
+
Cc: Steve Langasek <vorlon@debian.org>
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 13:43:59 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+> On Sat, Dec 28, 2013 at 05:24:57PM -0800, Russ Allbery wrote:
+>
+>> I'll have more to say about the relative merits of the two init systems
+>> later, but one thing I wanted to not briefly: this exercise was extremely
+>> valuable in helping me get a more realistic picture of both init systems.
+>> I had gone into this exercise with the vague impression that they were
+>> roughly at feature parity, and now realize that is not the case.
+>
+>> My impression now is that systemd's init and service management component
+>> is a substantially more mature piece of software.  That's an odd thing to
+>> say given that upstart is older, but systemd has the feel of software
+>> that's been tested against a wide variety of different situations and has
+>> had the necessary adaptations and configuration added to meet those needs.
+>> In some cases, that's "simply" additional features; in some cases, that's
+>> more comprehensive and more scalable design.  The socket activation system
+>> in particular is night and day between the two systems.
+>
+> So to respond specifically to this point about the "night and day"
+> difference between the socket-based activation systems: yes, upstart
+> upstream has not invested in fleshing out its socket-based activation
+> support, because earlier investigations led us to believe that socket-based
+> activation is a red herring that will never deliver the promised benefits.
+>
+> The feature was made available for those who might prefer to start their
+> services without the need for writing socket-handling code; but in my
+> estimation, the flaws wrt system startup (which as far as I can see also
+> affect the systemd implementation) make it altogether unsuitable for any
+> services you're expecting to have started at boot, and we have deliberately
+> avoided its use in Ubuntu.
+
+I'm a bit surprised that you mention this only now, after Russ'
+extensive mail. Could you tell us if there are there other components in
+systemd that you think are similarly flawed, and/or are if there other
+features in upstart that you think will never deliver the benefits one
+would naively expect from them?
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 22:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 22:33:05 GMT) (full text, mbox, link).

+ +

Message #1719 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd vs. binfmt-support
+
Date: Mon, 30 Dec 2013 00:28:29 +0200
+
+
On Sun, 2013-12-29 at 14:02 +0000, Colin Watson wrote:
+> I was referring more to Tollef's position, really.  Debian systemd
+> maintenance ought to take into account matters of Debian integration,
+> which includes whether it fits well into best-of-breed Debian practice.
+> 
+> If it's easy enough to override, then given that we have a better
+> implementation in Debian then we should simply continue to use it.
+
+I think Tollef's post was a reasonable first reaction at least -
+minimizing Debian-specific code (even if it's used somewhere else,
+Tollef was apparently not aware of that).
+
+
+> > I think this has been proven false by experience - systemd has innovated
+> > a lot in things where smaller projects were stagnant. And there's a
+> > fairly clear reason why this would be so: something like binfmt-support
+> > is too small a unit for independent development, both to design
+> > independently and to "sell" to every user individually.
+> 
+> It's simply not true that it's too small a unit for independent
+> development (what on earth gives you the authority to pronounce on this,
+
+> > Binfmt support is not that complex a task in itself. In practice, a lot
+> > of the usability will depend on consistency with other system parts.
+> > Designing APIs for it only is too narrow a view; you need to consider
+> > other tools, and if you can do better, then it's quite likely you should
+> > change the other tools too (things like adding udev rules etc).
+> 
+> However, I've been thinking about this for rather a long time, and I'm
+> actually quite familiar with the design issues.  binfmt-support is
+> specifically designed to be suitable for distributions (not just Debian)
+> shipping binfmt integration; in particular I have put much more effort
+> than systemd has into how it fits into packaging.
+
+I'm not saying that it would be too small to do anything useful with.
+But is it really different enough from other cases of setting kernel
+parameters to justify a completely unique approach? My gut feeling is
+that either binfmt-support should be closer to other tools, or the other
+tools should be changed to take into account lessons from
+binfmt-support.
+
+
+> > Convincing every distro builder out there individually that your binfmt
+> > support code is best wastes effort, both yours and theirs. It's more
+> > efficient to have systemd upstream decide what is a reasonable default
+> > implementation, and then have only people with specific needs or
+> > opinions change it.
+> 
+> This sounds very much like an argument from authority, and I'm afraid I
+> don't subscribe to it.  I don't consider my effort wasted, and I don't
+
+It's not an argument from authority - I'm not saying "that
+implementation is best, because systemd upstream chose it"; in fact I
+was not trying to argue the benefits of any implementation. What I meant
+was that I think it's beneficial to have default choices, and that
+choices made by systemd upstream are more likely to be correct than the
+collective average of people who would make such choices individually
+(plus everyone making individual choices would use more effort).
+Accepting this as true does not require accepting systemd upstream as an
+authority whose opinion would automatically decide an issue.
+
+It's also beneficial to use shared standard methods as much as possible,
+and systemd upstream is probably about as close as you'll get to a
+shared standard in an actively developing area in practice (I certainly
+don't believe that any committee could do better). I think avoiding
+unnecessary deviations from the shared code has benefits similar to
+doing things according to POSIX when possible; that does not mean that I
+would consider POSIX authors to be authorities who could dictate how
+things should be done.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 29 Dec 2013 22:57:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 29 Dec 2013 22:57:12 GMT) (full text, mbox, link).

+ +

Message #1724 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Sun, 29 Dec 2013 14:55:24 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> It does, however, have a number of missing features.  Those I have in
+> mind are:
+>   - ability to log daemon output to syslog
+>   - multiple socket activation (systemd socket activation protocol)
+>   - socket activation for IPv6 (and datagram sockets)
+>
+> Of these Russ rightly points out that lack of IPv6 support is rather
+> poor; it is arguably not suitable for release in jessie without this.
+>
+> However, crucially, these are all simple matters of programming,
+> without difficult design decisions.  They IMO don't reveal structural
+> problems with upstart's approach to things.
+
+I don't understand this argument. Even turning systemd into a 1:1
+upstart copy is "simple programming" (and vice versa), so by that argument
+there'd be no technical reason to pick one init system over the other at
+all. In some sense, it seems to me that you are proposing that the
+Debian *Technical* Committee make its decision for the init system based
+on the *developers* of each project, because the technical differences
+are mere metters of programming.
+
+(I'm not sure why the "structural" and "design decisions" would make a
+difference either, changing from one existing design to another existing
+design is also just programming).
+
+Best,
+Nikolaus
+
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 00:12:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 00:12:08 GMT) (full text, mbox, link).

+ +

Message #1729 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Sun, 29 Dec 2013 16:10:10 -0800
+
+
We seem to be at the point of the process where at least those of us who
+did early investigation are stating conclusions.  I think I have enough
+information to state mine, so will attempt to do so here.
+
+This is probably going to be rather long, as there were quite a few
+factors that concerned me and that I wanted to investigate.
+
+The brief summary is that I believe Debian should adopt systemd as its
+default init system on Linux.  There are two separate conceptual areas in
+which I think systemd offers substantial advantages over upstart, each of
+which I would consider sufficient to choose systemd on its own.  Together,
+they make a compelling case for systemd.  This position would have
+substantial implications for upgrade paths and for non-Linux ports; I'll
+discuss a bit of that below, but most of it in the separate branch of this
+bug report that Ian opened on that topic.
+
+Below, I first discuss the other choices before us besides systemd and
+upstart.  Then I look at a straight technical comparison between the two
+init systems, and finally look at issues of maintenance, community,
+ecosystem, and portability.  The three main criteria on which I was
+evaluating both systems were technical capabilities, surrounding
+ecosystem, and portability.  The latter two turned out to be deeply
+entangled, so I discuss them together.
+
+
+1. Other Choices
+
+First, other choices besides systemd and upstart.
+
+There were three replacement init systems proposed to the Technical
+Committee to replace sysvinit, plus the existing status quo.  The third
+option, OpenRC, is a more conservative and less revolutionary change than
+either systemd or upstart.  It continues to use the existing sysvinit init
+process but replaces the startup script management with a more robust
+shell library and additional features.
+
+I think the OpenRC developers are great people and I wish them all the
+success in the world with their project, but I just don't think it's
+ambitious enough for Debian's needs.  If we're going to the effort of
+replacing init systems and changing our startup scripts, a bare minimum
+requirement for me is that we at least address the known weaknesses of the
+sysvinit mechanism, namely:
+
+* Lack of integration with kernel-level events to properly order startup.
+* No mechanism for process monitoring and restarting beyond inittab.
+* Heavy reliance on shell scripting rather than declarative syntax.
+* A fork and exit with PID file model for daemon startup.
+
+My impression of OpenRC is that it is not attempting to solve these issues
+in the same way that systemd and upstart are.  To the extent that these
+issues are on the OpenRC roadmap, it's not as far along as either systemd
+or upstart is.  It's difficult to evaluate since the OpenRC documentation
+is rather sparse and lacks the comprehensive manual available to both
+systemd and upstart, which is itself a sign of a lack of project maturity.
+
+I don't think that switching to OpenRC offers enough clear benefit over
+the status quo.
+
+That raises the other obvious option: sticking with sysvinit.  I've made
+my position on this fairly clear in other threads, so I won't reiterate it
+here at length.  The short version is that I turned to other tools to
+manage daemons years ago because sysvinit was simply inadequate, and my
+feeling on that hasn't changed.  The model of fork and exit without clear
+synchronization points is inherently racy, the boot model encoded into
+sysvinit doesn't reflect a modern system boot, and maintaining large and
+complex init scripts as conffiles has been painful for years.  Nearly
+every init script, including the ones in my own packages, have various
+edge-case bugs or problems because it's very hard to write robust service
+startup in shell, even with the excellent helper programs and shell
+libraries that Debian has available.  A quick perusal of
+/etc/init.d/skeleton and the complex case statements and careful attention
+to status codes required for a proper init script makes this case clear.
+
+I think the choice of a default init system for Linux is a choice between
+systemd and upstart.  We would be doing ourselves and our users a
+disservice to stick with the status quo, or even a moderate update of the
+status quo to add a simpler service definition.  The limitations have been
+well-known for years, and I think it's telling that most other operating
+systems, even fairly conservative ones, have moved away from the System V
+init script model.
+
+The last option that was before us was supporting multiple init systems.
+I consider this a variation on a transition plan, with a possibly infinite
+time horizon, and will discuss this separately when I talk about
+transition plans.
+
+
+2. Core Service Management Functionality
+
+As reported to this bug, I did a fairly extensive evaluation of both
+upstart and systemd by converting one of my packages, which provides a
+network UDP service, to a native configuration with both systems.  While
+doing so, I tried to approach each init system on its own terms and
+investigate what full, native support of that init system would look like,
+both from a Debian packaging perspective and from an upstream perspective.
+I also tried to work through the upgrade path from an existing init script
+with an external /etc/default configuration file and how that would be
+handled with both systemd and upstart.
+
+I started this process with the expectation that systemd and upstart would
+be roughly evenly matched in capabilities.  My expectation was that I
+would uncover some minor differences and variations, and some different
+philosophical approaches, but no deeply compelling differentiation.
+
+To my surprise, that's not what happened.  Rather, I concluded that
+systemd has a substantial technical advantage over upstart, primarily in
+terms of available useful features, but also in terms of fundamental
+design.
+
+2.1. General Impressions
+
+systemd feels like a software package that has been used and pounded on in
+a wide variety of real-world situations, and has grown the flexibility and
+adaptibility that is required to make a wide variety of use cases work.
+upstart, on the other hand, has a minimal design and a ready escape to
+shell scripting, which may have discouraged directly tackling a broader
+array of use cases.  Regardless, there are a bunch of cases that systemd
+handles cleanly with simple configuration that would require shell script
+fragments or other workarounds in Ubuntu, which in turn makes the startup
+configurations less reliable and harder to debug.
+
+I was quite impressed throughout the process of developing systemd unit
+files.  Every time I realized I needed some piece of functionality to
+configure the daemon properly, systemd already had it.
+
+2.2. Major Functionality Gaps
+
+Here are the major pieces of functionality that I think would have to be
+added to upstart for rough feature parity:
+
+* Socket activation, by which I don't mean lazy start of daemons, although
+  it enables that, but init management of socket setup so that daemons can
+  start in parallel.
+
+  This has been discussed elsewhere on the thread, but I want to note here
+  that systemd's approach is bold and innovative.  We've had multiple
+  discussions in Debian lists in the past where people have felt somewhat
+  depressed or discouraged about Debian's lack of innovation or
+  unwillingness to tackle sweeping improvements.  After having studied and
+  implemented socket activation, I think this is one of those
+  opportunities, and we should not pass it by.
+
+  There are a variety of advantages to socket activation that have been
+  discussed elsewhere, and I'm not going to repeat them all here.  But one
+  I want to call out is the advantage for an enterprise systems
+  administration environment.  Right now, in order to configure bind
+  addresses or IPv6 behavior for my services, I have to dig into the
+  individual configuration syntax or command-line flags of each separate
+  daemon, and often there's no easy way to set these parameters without
+  making intrusive changes to daemon startup.  Socket activation lets me
+  manage all of this through a simple configuration override that I drop
+  into /etc via (for example) Puppet, and the syntax is the same for every
+  service that uses it.  It would obviously take quite some time to get
+  there, but that's a really nice vision of the future, and one that would
+  make a real difference for Debian use cases I care about.
+
+  upstart has a socket activation protocol, but it would need an
+  almost-complete redesign in order to be used the way that systemd's can
+  be used.  It doesn't support passing multiple sockets (required for
+  complex daemons, some IPv6 scenarios, and binding to multiple but not
+  all interfaces), it doesn't support IPv6 at all, it doesn't support UDP
+  sockets, and its configuration syntax is inadequate to represent the
+  parameters that would be useful in a real-world case.  It also doesn't
+  separate the socket configuration from the daemon configuration, which
+  makes it harder for a local systems administrator to control binding
+  behavior without changing other properties of daemon initialization.
+
+* Integrated daemon status.  This one caught me by surprise, since the
+  systemd journal was functionality that I expected to dislike.  But I was
+  surprised at how well-implemented it is, and systemctl status blew me
+  away.  I think any systems administrator who has tried to debug a
+  running service will be immediately struck by the differences between
+  upstart:
+
+  lbcd start/running, process 32294
+
+  and systemd:
+
+    lbcd.service - responder for load balancing
+     Loaded: loaded (/lib/systemd/system/lbcd.service; enabled)
+     Active: active (running) since Sun 2013-12-29 13:01:24 PST; 1h 11min ago
+       Docs: man:lbcd(8)
+             http://www.eyrie.org/~eagle/software/lbcd/
+   Main PID: 25290 (lbcd)
+     CGroup: name=systemd:/system/lbcd.service
+             └─25290 /usr/sbin/lbcd -f -l
+
+  Dec 29 13:01:24 wanderer systemd[1]: Starting responder for load balancing...
+  Dec 29 13:01:24 wanderer systemd[1]: Started responder for load balancing.
+  Dec 29 13:01:24 wanderer lbcd[25290]: ready to accept requests
+  Dec 29 13:01:43 wanderer lbcd[25290]: request from ::1 (version 3)
+
+  Both are clearly superior to sysvinit, which bails on the problem
+  entirely and forces reimplementation in every init script, but the
+  systemd approach takes this to another level.  And this is not an easy
+  change for upstart.  While some more data could be added, like the
+  command line taken from ps, the most useful addition in systemd is the
+  log summary.  And that relies on the journal, which is a fundamental
+  design decision of systemd.
+
+  And yes, all of those log messages are also in the syslog files where
+  one would expect to find them.  And systemd can also capture standard
+  output and standard error from daemons and drop that in the journal and
+  from there into syslog, which makes it much easier to uncover daemon
+  startup problems that resulted in complaints to standard error instead
+  of syslog.  This cannot even be easily replaced with something that
+  might parse the syslog files, even given output forwarding to syslog
+  (something upstart currently doesn't have), since the journal will
+  continue to work properly even if all syslog messages are forwarded off
+  the host, stored in some other format, or stored in some other file.
+  systemd is agnostic to the underlying syslog implementation.
+
+* Security defense in depth.  Both upstart and systemd support the basics
+  (setting the user and group, process limits, and so forth).  However,
+  systemd adds a multitude of additional defense in depth features,
+  ranging from capability limits to private namespaces or the ability to
+  deny a job access to the network.  This is just a simple matter of
+  programming on the upstart side, but it still contributes to the general
+  feature deficit; the capabilities in systemd exist today.  I'm sure I'm
+  not the only systems administrator who is expecting security features
+  and this sort of defense in depth to become increasingly important over
+  the next few years.
+
+  Here again, I think we have an opportunity for Debian to be more
+  innovative and forward-looking in what we attempt to accomplish in the
+  archive by adopting frameworks that let us incorporate the principles of
+  least privilege and defense in depth into our standard daemon
+  configurations.
+
+There are also a plethora of minor features and tuning available in
+systemd but not in upstart.  None of this is as significant as the points
+mentioned above, and none of it is as difficult to implement, but it's not
+currently implemented, and I think it speaks to systemd having been tested
+against a broader array of use cases.
+
+2.3. Event vs. Dependency Model
+
+There is one UI design difference between systemd and upstart that's less
+clear-cut, but which I think will surprise people.  systemd is built
+around familiar dependencies between services, and starts services in
+dependency order.  There are some twists, such as allowing a service to
+create a reverse dependency (make another service depend on it), but it's
+the basic design that's familiar to any packager, or to users of languages
+like Puppet.  upstart, on the other hand, uses a message bus model:
+services are started when particular events are received, and dependencies
+are expressed by listing the events required to trigger startup (or some
+other action).
+
+Conceptually, both of these designs are equivalent.  They both construct a
+DAG that's used to order service startup.  However, upstart complicates
+matters by having two types of messages on its message bus: signals and
+methods (technically, there are also hooks, but the distinction doesn't
+matter for this point).  Signals behave like the typical asynchronous
+message bus event, or like a dependency: they trigger services to start,
+but the service issuing the signal does not care whether anyone listens or
+not.  Methods do not; methods are effectively synchronous calls and the
+service issuing a method event waits until the method event has been acted
+on before continuing.
+
+The UI problem with this approach is that it creates a pitfall with rather
+noticable consequences.  If someone ever confuses a signal event and a
+method event and starts a service on a method event instead, it is then
+very easy to block startup of some fundamental system service because its
+method event never completes due to deadlock.  This is made somewhat more
+likely by the fact that method events are the default in initctl emit
+commands, whereas signal events require a flag.
+
+Again, this is not a fundamental issue with either system; either
+representation is mathematically convertable into the other.  But it's
+difficult to mess up dependencies in quite the same way.  One can create
+cycles, but unless one is modifying the dependencies of core services,
+it's hard to create a cycle that involves a core service.  upstart
+provides a way to shoot oneself in the foot by blocking startup of a core
+service by listening to the wrong type of event.  This model doesn't, so
+far as I could find, offer any clear advantages over a dependency
+structure in compensation.
+
+2.4. Configuration File Model
+
+There is one place where I came into this evaluation preferring the
+upstart design over the systemd design, and came away with a continued
+preference, but a more mild one: the configuration file model.  systemd
+uses an /etc overrides /lib model, where all unit configurations are
+installed in /lib and only local overrides and some configuration goes
+into /etc.  upstart uses the (more familiar to Debian) model where the
+daemon configuration is a conffile in /etc.
+
+Both approaches have real advantages, but I think the upstart approach has
+slightly more.  The systemd model means that one no longer has to add
+various guards to daemon configurations to allow for the possibility that
+the package has been uninstalled but not purged.  Those continue to be
+necessary with upstart (and continue to be written in shell; systemd
+actually has a nicer language for doing this, even though it's not
+needed).  However, the upstart approach makes it easier to preserve and
+merge local changes with upstream changes.  In the systemd model, the
+local administrator has line-by-line granularity on overrides of systemd
+unit configurations, which while solving much of the problem does not help
+with the specific case of wanting to change the flags passed to the
+daemon.  If the package later changes the flags in some orthogonal way,
+it's easy for the system to miss that change.  This is something that,
+under systemd, will probably require development of new tools to warn the
+adminsitrator of what's happened.  upstart avoids this problem by having
+the whole configuration be managed as a conffile.
+
+I think the upstart approach is better, but I think the drawbacks of the
+systemd approach could be mostly overcome with some fairly simple Debian
+tools.
+
+2.5. Summary
+
+I think the technical comparison between upstart and systemd as both
+projects exist today substantially favors systemd, at both the feature and
+design level.  When picking between both products as they currently exist
+on the basis of their current capabilities and future adaptibility, I have
+no qualms about picking systemd.
+
+
+3. Ecosystem and Portability
+
+One of the primary concerns from the start of this conversation has been
+around portability of any new init system.  One advantage of the extreme
+simplicity of sysvinit is that it's extremely portable; this advantage
+continues to be shared by OpenRC.  Both of the more-functional init
+systems are Linux-specific.  However, upstream attitudes towards
+portability differ.  This ties directly into the development models of
+both systemd and upstart, the community momentum, and the larger
+surrounding ecosystem.
+
+3.1. Ecosystem Reality Check
+
+One of the points that I think may have been obscured in the discussion,
+but which is important to highlight, is that basically all parties have
+agreed that Debian will adopt large portions of systemd.  systemd is an
+umbrella project that includes multiple components, some more significant
+than others.  Most of those components are clearly superior to anything we
+have available now on Linux platforms and will be used in the distribution
+going forward.
+
+In other words, this debate is not actually about systemd vs. upstart in
+the most obvious sense.  Rather, the question, assuming one has narrowed
+the choices to those two contenders, is between adopting all the major
+components of systemd including the init system, or adopting most of the
+major components of systemd but replacing the init system with upstart.
+Either way, we'll be running udev, logind, some systemd D-Bus services,
+and most likely timedated and possibly hostnamed for desktop environments.
+
+I think this changes the nature of the discussion in some key ways.  We're
+not really talking about choosing between two competing ecosystems.
+Rather, we're talking about whether or not to swap out a core component of
+an existing integrated ecosystem with a component that we like better.
+
+Now, I am generally on the side that says loose coupling of ecosystems is
+an inherent good.  However, I don't agree that it's such an inherent good
+that we should disassemble things just for the sake of having disassembled
+things.  At feature parity, and absent any compelling reason to swap
+components, I think we should take the path of least resistance and use
+the integrations that other people have already developed.  Debian has
+more than enough hard integration problems to solve without creating new
+ones for ourselves unnecessarily.  But that's the key word: unnecessarily.
+If we do have a reason for doing this, we should seriously consider it.
+
+Therefore, I believe the burden of proof is on upstart to show that it is
+a clearly superior init system along some axis, whether that be
+functionality or portability or flexibility or maintainability, to warrant
+going to the effort of disassembling a part of the systemd ecosystem and
+swapping in our own component.
+
+3.2. Portability
+
+This is a difficult topic to clearly discuss, since it is, in essence, all
+future speculation at this point.
+
+I should state up front that, in making these sorts of decisions around
+free software projects, I have a relatively high future discount rate.  In
+other words, I give substantially less credit to something that does not
+exist now but could exist in the future.  I don't discount it to zero, but
+I do discount it relatively strongly.  Others may not.
+
+I do this because free software projects and volunteer projects are
+inherently unpredictable.  The free software world is stuffed to the gills
+with roadmaps that never actually happened, through no fault of any of the
+people involved.  It's easy to agree that something would be a good idea,
+and another matter to actually drive it through to completion.
+
+Right now, neither systemd nor upstart work on non-Linux platforms.
+Therefore, right now, adopting either of them means that we either
+jettison our non-Linux ports or adopt a transition plan that retains
+support for sysvinit scripts.  Right now, there is minimal difference
+between the two projects in terms of portability; they both make extensive
+use of Linux-specific APIs and have hooks for Linux-specific actions.
+
+However, there is a porting effort for upstart to kFreeBSD underway, and
+the current upstart maintainers have indicated more interest in
+portability than the systemd maintainers.  That's been a point of
+significant friction over systemd (and was, in the past, also a point of
+friction with the previous upstart upstream, although that's subsequently
+changed).  So there is a real advantage for upstart here, but it's one
+that has to be discounted because it's potential future work that could
+happen, but which is certainly not guaranteed to happen.
+
+Another point worth considering here is that the best way, from Debian's
+perspective, of porting either project to kFreeBSD or the Hurd is to
+implement the currently Linux-specific interfaces on those platforms in
+some fashion.  (An inotify and epoll API that uses kqueue under the hood,
+for example.)  To the extent that this is possible, it benefits both
+upstart and systemd equally, as well as many other programs in the
+archive that are written to currently Linux-specific APIs.  This is an
+approach that's been common for years in different porting scenarios; I
+use it myself to maintain compatibility with both MIT Kerberos and Heimdal
+in the Kerberos-related packages I maintain.
+
+Finally, note the ecosystem point above.  To maintain feature parity
+across Debian's ports, there already appears to be widespread agreement
+that components of systemd will have to be ported, particularly logind and
+possibly some of the other services.  Now, that's not quite the same thing
+as porting the init system: it's possible those components use fewer
+Linux-specific interfaces (I've not checked), it's possible that
+alternative implementations of the same functionality can be provided
+(which IIRC is what happened with udev in some fashion), and not being
+able to run major desktop environments is not the same thing as not being
+able to boot.  But I do think it blunts some of the porting argument.  The
+non-Linux ports are going to have to port, fork, or replace systemd
+components anyway, regardless of the choice of init system, or drop out of
+feature parity with the Linux ports.
+
+So, in short, I consider portability to be a possible benefit of upstart,
+but I'm inclined to discount that advantage for several reasons.  One,
+it's not yet actually materialized and still may not, and two, systemd
+porting looks like it's going to be on the table regardless.  I therefore
+think that we should deal with this issue through how we structure a
+transition plan, rather than taking it as a reason to choose upstart over
+systemd.  More on that in another message.
+
+3.3. Project Momentum
+
+One of the reasons why I'm leery of the future portability argument for
+upstart, and one of the reasons why I'm leery of upstart in general, is
+that I'm quite worried upstart will prove to be a blind alley.
+
+I think there are several reasons to be concerned here.  None of them is
+persuasive in isolation, but taken together I think they raise significant
+cause for concern:
+
+* Red Hat adopted upstart but never did a wholescale conversion, and then
+  abandoned upstart in favor of systemd.  Obviously, one should not put
+  too much weight on this; Red Hat is a commercial company that has a
+  wealth of reasons for its actions that do not apply to Debian.  But I
+  think it's still worth noting that the only non-Ubuntu major adopter of
+  upstart backed away from it.
+
+* upstart is older than systemd but has significantly fewer features.
+  Now, the danger of this sort of metric is that features can be added as
+  "padding" without any real significance or advantage.  But having spent
+  serious time with both systems, I don't believe that's the case here.
+  systemd is not adding extraneous features; rather, it's adding
+  significant, useful functionality and real-world adaptability, and
+  upstart is trailing despite being an older project.
+
+* systemd has a broader community.  SuSE and Red Hat are both converting,
+  there is significant interest across the general Linux community, major
+  upstreams of Debian such as GNOME and KDE are adopting systemd support
+  (and in some cases even requiring it), and systemd is tackling
+  significant problems, such as logind, that everyone agrees need to be
+  solved.  By comparison, upstart is effectively used only by Ubuntu, and
+  there isn't the same sort of enthusiasm or attempts to tackle broad
+  problems happening at present in the upstart community so far as I can
+  see.  This is reasonable if upstart is mature and mostly complete
+  software, but that was not my personal experience.
+
+* There appears to be some direct tension between GNOME upstream and
+  upstart, not mostly due to upstart itself but because of corporate
+  direction at Canonical.  Again, this can easily be overstated.  But I do
+  think that Debian will want to continue to support GNOME going forward,
+  and doing that with upstart will clearly require more work within the
+  project than doing that with systemd.  This is another case where we
+  shouldn't shy away from the work if it's necessary, but we also
+  shouldn't adopt unnecessary work.
+
+Over the past few months, I've also put out some feelers to other
+colleagues, and the uniform reaction I got in response is that systemd is
+a better technical solution than upstart.  I think this speaks to the
+general momentum around systemd, and will directly affect our ease of
+integration in the future.  I know that after my personal experience with
+both projects, I'm excited to add systemd support to my projects as
+upstream, and not particularly enthused about upstart from an upstream
+perspective since it doesn't offer me any clear benefits.
+
+3.4. Summary
+
+I'm concerned that, if we adopt upstart, in two or three years we'll end
+up wanting to do the same thing that Red Hat did, back out, and switch to
+systemd.  That would be a huge amount of wasted effort.  Even worse would
+be to end up in that situation and decide that the conversion is too much
+work, and then just settle for an init system that is harder to integrate
+and provides less functionality.
+
+I remain unconvinced of the long-term growth curve of the upstart project.
+I don't think it's going to be abandoned completely, at least unless
+Ubuntu decides to switch (which seems unlikely at the moment) or Canonical
+dissolves (which also seems unlikely).  I do think there's a significant
+danger that it will stagnate and fall behind in terms of desired features,
+particularly since this appears to already be happening.  I don't have
+faith in the path that takes upstart from where it is now to something
+with feature parity with systemd as it is now, let alone something that's
+clearly better than systemd.  And I think Debian as a project should be
+aiming for better, not merely sufficient.
+
+The portability issues are significant.  However, I don't think they
+provide a clear advantage to upstart.  It's possible that they will in the
+future, at which point the ecosystem argument becomes much more difficult
+and much narrower.  But the fact remains that we'll be using large
+components of systemd across the distribution anyway, which means that
+swapping out the init system doesn't add as much portability as one might
+hope, and increases our integration burden.
+
+I think we should make wise decisions about which areas we want to invest
+project effort.  I dislike investing significant project effort in
+catch-up efforts that, when complete, merely get us back to where we would
+have been if we'd chosen a different solution.  I don't think that's wise
+stewardship of project resources.  I want to see Debian focus its efforts
+on places where we can make a real difference, where we can be leaders.
+That means adopting the best-of-breed existing solutions and building on
+top of them, not reinventing wheels and thereby starting from a trailing
+position.
+
+
+4. Conclusion
+
+If I'm correct in my analysis of the community and ecosystem dynamics, I
+think upstart needs to show that it is a significantly better technical
+choice than systemd in order to warrant the additional project work that
+will be required to build on top of upstart.  Given feature parity, I
+believe we should adopt systemd so that we can focus our efforts on
+interesting new problems rather than on redoing integrations that other
+people have already done.
+
+My personal analysis did not show that upstart was significantly better
+than systemd, or even at feature parity.  Rather, I believe it is
+currently trailing systemd substantially in multiple areas, some of which
+will require significant design changes.
+
+Given that, I believe systemd is the clear choice, despite the portability
+issues that we will incur by choosing it.  However, I think that means we
+need to be very careful about how we handle a transition.  I intend to
+comment on that in a separate message (which will probably be tomorrow
+given how long writing this message took).
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 06:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 06:00:04 GMT) (full text, mbox, link).

+ +

Message #1734 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: 727708@bugs.debian.org, Steve Langasek <vorlon@debian.org>
+
Subject: socket activation
+
Date: Mon, 30 Dec 2013 06:57:06 +0100
+
+
Steve Langasek <vorlon@debian.org> wrote:
+> However, I think this gets to the heart of why upstart upstream has avoided
+> ever recommending the use of socket-based activation.  There are some fairly
+> fundamental problems that basically halted development of socket-based
+> activation in upstart, and a look at systemd usage on
+> Fedora led me to believe that systemd had not overcome these problems at
+> all.
+Your e-mail raises serious doubts about socket activation, so I'll
+respond to try to clear up some issues even though most or all points
+have been rebutted in other replies in this thread.
+
+Before I do that though, let me say that your mail doesn't show the
+level of dilligence that I'd expect from a seasoned Debian developer
+and a member of the Technical Committee.
+
+> If I'm not mistaken (no references to hand - sorry), systemd upstream has
+> claimed in the course of discussions on debian-devel that lazy activation is
+> not the purpose of socket-based activation, and that using socket-based
+> activation does not require you to pay the service startup penalty at the
+> time of first connection.
+You get the *possiblity* of lazy activation, it is one of the
+reasons. [1, 2, 3] list many good reasons (rootless access to ports < 1024,
+simplification of daemons, no explicit dependencies between services,
+upgrades and restarts while keeping the socket open, and also lazy activation).
+They are all non-conflicting. [3] shows great things that can be done
+with lazy activation.
+
+[1] http://0pointer.de/blog/projects/socket-activation.html
+[2] http://0pointer.de/blog/projects/systemd.html
+[3] http://0pointer.de/blog/projects/socket-activated-containers.html
+
+There are also further plans (at the implemented-but-not-merged stage)
+for further functionality: spawning multiple workers using SO_REUSEPORT [4].
+
+[4] http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/15364/focus=15598
+
+> However, this is not borne out by my experiments
+> with systemd on Fedora (which I would presume to be the go-to source for
+> best practices of systemd service activation).
+Fedora has something like 800 unit files. I'm sure that quite a few
+could be improved. I don't think that proves anything.
+
+> On Fedora 20, after enabling the sshd and rsync service+socket units (both
+> installed but disabled by default on Fedora per their policies on running
+> services out-of-the-box) and rebooting, I find that both port 22 and port
+> 873 are bound by pid 1.  Only upon connecting to the socket does systemd
+> actually spawn the server (in the case of sshd, it spawns it as 'sshd
+> -i', so has to start up the server anew on each connection;
+You can switch to non-lazy single-instance mode by 'systemctl disable
+sshd.socket; systemctl enable sshd.service', and back by 'systemctl
+disable sshd.service; systemctl enable sshd.socket'.
+
+It'd have been much better to simply ask "How do I do (lazy
+activation|inetd-style activation| non-lazy activation)?" without
+drawing all those premature conclusions. I added some more
+documentation do systemd.socket(5) [5]. I'm also happy to take any
+further documentation rfe's.
+
+[5] http://cgit.freedesktop.org/systemd/systemd/commit/?id=3cf148f
+
+> in the case of
+> rsyncd, the .service definition is completely incompatible with socket-based
+> activation and any attempt to connect results in the rsyncd.socket unit
+> landing in a 'failed' state).
+Like Russ, Uoti, and Josselin said, it a bug. Actually rsyncd.service
+is fine, but rsyncd.socket is broken. This has been fixed for F19 [6],
+but apparently not for F20. F20 came out a week ago, so probably
+nobody has noticed so far.  Bug filed [7].
+
+[6] https://bugzilla.redhat.com/show_bug.cgi?id=1018520
+[7] https://bugzilla.redhat.com/show_bug.cgi?id=1047236
+
+> If what one is trying to accomplish here is to provide a replacement for
+> inetd, then this is perfectly sufficient.  But if one is trying to use
+> socket-based activation for the claimed purpose of ensuring service startup
+> ordering without the need to declare explicit dependencies, then you must
+> accept the penalty of lazy activation
+No, this is a complete misunderstanding.
+
+> - which is almost never acceptable in
+> a server context (where the purpose of the machine is to run the services
+> that you have configured, and they should therefore not be started lazily),
+Complete non sequitur. For many services the initialization time
+(usually in miliseconds) is an acceptable delay on the first connection.
+Probably it is even unnoticable compared to network latency. Please remember
+that this is not for sysvinit scripts which do sleep in a loop. [8] is a
+nice example of lazy socket activation of services on a massive scale.
+
+[8] https://www.getpantheon.com/blog/pantheon-running-over-500000-systemd-units
+
+> and suboptimal even in a client context (since not starting services that
+> are on the critical path for boot until the client requests them will
+> potentially lead to a significant boot-time slowdown, if all the services
+> are doing this).
+No. If you have all services started lazily, which could happen on a server,
+the boot-time is great, the system is up in a couple hundred milliseconds.
+When a connection comes in, things necessary for this connection are
+started and nothing else. In some cases you want that, in others not.
+Lazy activation you can turn on and off, so there's really no issue
+here.
+
+> As far as I've been able to tell, the only solutions that would allow
+> non-lazy socket-based-activation of services in systemd all introduce
+> significant boot-time races, whereby it is no longer assured that systemd
+> will bind to the socket
+Please look at [9]. Sockets will be bound before services are started.
+Also, even if it happened that systemd and the service itself, or two
+different services for that matter, would try to bind the same socket,
+it's hardly the end of the world. You'd get an error in one of the units.
+In the normal case automatic ordering requirements added by systemd
+will be enough.
+
+[9] http://www.freedesktop.org/software/systemd/man/bootup.html#System%20Manager%20Bootup
+
+> (and passing the socket information via the
+> environemnt) before starting the service.  Indeed, when I looked at this
+> problem on an earlier version of Fedora, I found what I believe to be a
+> latent security problem in the cups units, because it was nondeterministic
+> whether the service would start with sockets passed from systemd, or a
+> different set of sockets as defined in the cups config!
+I fail to see a "security problem" here. It's not like cups opening its
+sockets the way it has done for years suddently starts being insecure.
+Even if systemd would compete with cups here. All that said, cups.socket
+has Before=cups.service, so systemd should always bind the socket earlier
+or not at all.
+
+> When I mentioned this to Lennart at DebConf this year, his response was that
+> "cups was special".  Well, after further investigation, I don't think it's
+> true that cups is special. 
+cups.service is (a) socket activated (at least sometimes, (b) hardware activated
+when usb printers are plugged in, (c) dbus activated when necessary, and/or
+(d) started as part of the boot process. It *is* special because most services
+don't have this complexity.
+
+And actually doing this all in the init manager makes sense, because if
+any two of those things happen at once, there's still no race condition.
+
+> I think systemd socket-based activation is snake
+> oil, that does not do what was promised without introducing hidden
+> trade-offs which no one has been forced to acknowledge because too few
+> developers are making use of this feature today to expose the integration
+> problems.
+Wow.
+
+> Of course, it's entirely possible that I've misunderstood something here, so
+> I welcome your investigations with lbcd.  I'm very interested to see if your
+> understanding of systemd socket-based activation best practices matches my
+> own, and to have an opportunity to experiment with socket-based activation
+> in the more relevant environment of Debian unstable rather than Fedora.
+> 
+> FWIW, if indeed socket-based activation in systemd can't actually be used
+> for anything besides a glorified inetd,
+Wow.
+
+> I think that has implications for
+> the discussion about daemon readiness protocols.  The argument for systemd
+> seems to be "use sd_notify, or if you don't like having a library dependency
+> then just use socket-based activation which is better anyway".  But I'm sure
+> there will be upstreams who don't want lazy initialization any more than
+> they want an external library dependency.
+Certainly true (if we ignore the part about lazy activation) for some
+upstreams. But it's not an argument for *this* discussion, unless
+those fears have basis in truth.
+
+Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote
+> On Sun, 2013-12-29 at 10:37 -0800, Steve Langasek wrote:
+> > diligently keeping the two implementations in sync.  Since
+> > LISTEN_FDS/LISTEN_PID is the defined API for systemd passing the socket
+> > information to the service, for systemd to ever fail to pass this socket
+> > information, resulting in the service deciding that it's not *actually*
+> > running under systemd and should fall back to a different mode, is
+> > potentially a very serious problem.
+> 
+> If you want to make sure your service never tries to start without
+> socket activation, it should have Requires=foo.socket; none of the
+> default relations are strong enough to strictly prohit starting
+> without a socket.
+Exactly. All this is because systemd doesn't *force* you to use socket
+activation. If you have a .socket file with Accept=no and a .service
+file, you can have the service enabled alone (so no socket activation),
+both enabled (socket activation), just the socket enabled (lazy
+socket activation). Then you could even have a second .socket
+file with Accept=yes and .service template file (with @ in the name),
+and have inetd-style per-connection activation. With choice comes
+complexity.
+
+Zbyszek
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 06:54:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 06:54:05 GMT) (full text, mbox, link).

+ +

Message #1739 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Sun, 29 Dec 2013 22:50:17 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sun, Dec 29, 2013 at 01:43:59PM -0800, Nikolaus Rath wrote:
+> I'm a bit surprised that you mention this only now, after Russ'
+> extensive mail. Could you tell us if there are there other components in
+> systemd that you think are similarly flawed,
+
+Why should it have been mentioned before now?  I don't consider socket-based
+activation to be a decisive difference between the two systems.  The systemd
+implementation of socket-based activation is clearly more featureful than
+the upstart implementation, and it sounds like it's also more robust - at
+the cost of a significant amount of implementation complexity, and quite a
+bit of hidden policy that's difficult to discern.
+
+The fundamental reason for systemd's more complete implementation of
+socket-based activation is relative priorities, not that the upstart
+developers somehow tried and failed to match systemd.  With an
+already-debugged set of dependency declarations, as we have in Debian for
+sysvinit/insserv and in Ubuntu for upstart, socket-based activation provides
+only incremental benefits which I am skeptical that it's worth Debian
+investing in.
+
+I think there's some serious misestimation here of the relative costs to
+Debian of resolving any issues in upstart that the members of the TC might
+consider blockers, vs. the work to integrate systemd throughout the
+distribution - an integration that would need to be evolved from first
+principles in a Debian context, not copied wholesale from another
+distribution like Fedora with different policies and architectural choices.
+
+To be clear: speaking as part of the upstart upstream team, if the TC
+decided that they considered socket-based activation the correct model for
+Debian to adopt going forward, and that having a full-featured socket
+activation implementation was therefore a precondition for adopting upstart,
+I think we would have no trouble at all delivering that for jessie.  There's
+already agreement in principle with improving upstart's socket-based
+activation support for compatibility with systemd's; and the lack of ipv6
+support is something I reported a bug about quite a while ago myself
+(https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/942955).  It's only
+a question of priorities - improved socket activation support hasn't been a
+priority, because the existing facilities have been giving upstart's
+downstreams what they need.
+
+> and/or are if there other features in upstart that you think will never
+> deliver the benefits one would naively expect from them?
+
+Socket-based activation has never been a feature that upstart upstream has
+promoted the use of.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 08:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 08:45:04 GMT) (full text, mbox, link).

+ +

Message #1744 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Mon, 30 Dec 2013 09:40:29 +0100
+
+
]] Russ Allbery 
+
+First, thanks to both you and Ian for the quite comprehensive
+write-ups.
+
+> If the package later changes the flags in some orthogonal way, it's
+> easy for the system to miss that change.  This is something that,
+> under systemd, will probably require development of new tools to warn
+> the adminsitrator of what's happened.  upstart avoids this problem by
+> having the whole configuration be managed as a conffile.
+
+You might want to have a look at systemd-delta.  On my quite boring home
+machine:
+
+: tfheen@xoog ~ > systemd-delta
+[MASKED]     /etc/udev/rules.d/75-persistent-net-generator.rules → /lib/udev/rules.d/75-persistent-net-generator.rules
+
+1 overridden configuration files found.
+: tfheen@xoog ~ > 
+
+It can also output diffs.
+
+> I think the upstart approach is better, but I think the drawbacks of the
+> systemd approach could be mostly overcome with some fairly simple Debian
+> tools.
+
+We were initially considering using ucf and checking if the file in /etc
+had changed (before we had per-line overrides and such), but with the
+more complex overrides now available, I think systemd-delta is a better
+solution.  I guess we could integrate that into the packaging somehow
+and present a useful UI if you've overridden a line that changes.
+
+[...]
+
+> But I do think it blunts some of the porting argument.  The non-Linux
+> ports are going to have to port, fork, or replace systemd components
+> anyway, regardless of the choice of init system, or drop out of
+> feature parity with the Linux ports.
+
+It's not like we have feature parity today.  Hurd has the whole
+translators setup.  kFreeBSD has jails and ZFS.  Nobody is arguing that
+we must ship those with Linux too, so why should the feature parity have
+to go in the other direction?  Personally, I think the more interesting
+use case for kFreeBSD is on the server side, and not as a GNOME
+workstation.  I also realise a file system is not on the same magnitude
+for a distribution as an entire desktop environment, but we're looking
+at degrees here anyway, not a black and white picture.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 08:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 08:54:04 GMT) (full text, mbox, link).

+ +

Message #1749 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: debian-ctte@lists.debian.org, Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Mon, 30 Dec 2013 00:51:03 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sun, Dec 29, 2013 at 10:05:17PM +0100, Tollef Fog Heen wrote:
+> > It would, however, be nice if this were more clearly stated, since the
+> > guidance to the author of the unit file about what dependencies one should
+> > or should not explicitly add is a bit sparse.  In particular, I wonder if
+> > there is an implicit After= dependency in a service unit on a socket unit
+> > of the same name (which would make sense given how Sockets= works), or if
+> > that's something that one should explicitly add.
+
+> http://www.freedesktop.org/software/systemd/man/bootup.html has some
+> graphs.  In addition, as long as your service is not doing anything in
+> the early boot, DefaultDependencies will be true and you'll have an
+> After=basic.target in your service.
+
+On Sun, Dec 29, 2013 at 01:18:00PM -0800, Russ Allbery wrote:
+> Tollef Fog Heen <tfheen@err.no> writes:
+
+> > ]] Russ Allbery 
+
+> >> It would, however, be nice if this were more clearly stated, since the
+> >> guidance to the author of the unit file about what dependencies one should
+> >> or should not explicitly add is a bit sparse.  In particular, I wonder if
+> >> there is an implicit After= dependency in a service unit on a socket unit
+> >> of the same name (which would make sense given how Sockets= works), or if
+> >> that's something that one should explicitly add.
+
+> > http://www.freedesktop.org/software/systemd/man/bootup.html has some
+> > graphs.  In addition, as long as your service is not doing anything in
+> > the early boot, DefaultDependencies will be true and you'll have an
+> > After=basic.target in your service.
+
+> This by itself doesn't fully replace the implicit dependency.  It ensures
+> ordering is correct for boot, but not that ordering is correct when
+> starting deactivated services, where the service startup is not happening
+> in the context of target processing.  (Unless target processing happens in
+> more places than I think it does.)
+
+> It sounds, from Uoti's investigations, that the code also directly adds an
+> implicit dependency, which would ensure correct behavior in those cases as
+> well.
+
+Right.  So between these two aspects of systemd's implied dependencies
+(which I believe postdate my previous investigations, given the behavior I
+observed at the time), it sounds like there are no races here for the
+general case, and I agree that this provides a solid mechanism for
+activation of services whose authors wish to avoid handling sockets
+directly.
+
+I'm also interested to know how systemd purports to handle the exceptional
+cases, where a dependency on basic.target is not possible.  For instance,
+NFS mounts at boot: modern NFS on Linux requires a complex set of
+interdependent RPC daemons to be started on the client before an NFS share
+can be mounted.  In my experience, these are some of the most complex
+boot-time interdependencies around, which would most benefit from something
+like socket-based activation to implicitly resolve ordering constraints.
+
+The nfs-common and rpcbind packages currently have no integration with
+systemd, so they get the default behavior for SysV services in rcS.d:
+WantedBy=sysinit.target, Before=sysinit.target.  But there's nothing which
+documents that sysinit.target is a precondition for remote-fs.target, so in
+its current state, mounting of remote filesystems at boot is almost
+certainly racy with systemd in Debian.  What does a correct implementation
+of NFS support on systemd look like?  I've tried installing nfs-utils on
+Fedora 20, and while it provides a full set of native systemd units,
+surprisingly, the only one that references remote-fs-pre.target is nfs-lock. 
+So it looks to me like this is another case where no one has actually done
+the work yet to properly integrate with systemd, and a migration to systemd
+would cause regressions for users of this configuration (and probably
+others).
+
+What is the right way to make nfs-common behave correctly on startup with
+systemd?  Is there a reason that sockets.target is only a dependency of
+basic.target, not of remote-fs-pre.target, which would enable use of
+socket-based activation for fs helper daemons like those in nfs-common? 
+(Note, of course, that nfs-utils currently has no support for the systemd
+socket activation protocol.  However, if one of the arguments for systemd is
+socket activation, then I think we should explore the limits of how we think
+it should be used.)
+
+Thanks,
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 09:12:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 09:12:05 GMT) (full text, mbox, link).

+ +

Message #1754 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org, + 733452@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, + Andreas Barth <aba@ayous.org>
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more + messages]
+
Date: Mon, 30 Dec 2013 01:09:29 -0800
+
+
[Message part 1 (text/plain, inline)]
+
[Started drafting this before Ian forked the bug; sending to both bug
+reports now]
+
+On Fri, Dec 20, 2013 at 03:41:55PM -0800, Russ Allbery wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > Russ Allbery writes:
+
+> >> I'd like to see both of them support systemd's method, since it's
+> >> extensible and provides more general functionality.  I think the
+> >> benefit of support for SIGSTOP is marginal; adding sd_notify calls is
+> >> not that much harder and doesn't have the conceptual weirdness of
+> >> stopping the daemon to notify the init system that it's running.
+
+> > I strongly disagreee.
+
+> > As the upstream author of a daemon I'm
+> >  - not willing to add a library dependency for this
+> >  - not willing to write a 50-100 lines of tiresome socket code for this
+> >  - not willing to copy the library file into my source tree
+> > so the result is that userv upstream won't support systemd's readiness
+> > protocol.
+
+> Yes, we completely disagree.
+
+> Among other things, that's about the smallest and least-impactful library
+> dependency I can imagine.  My intent in integrating support for sd_notify
+> is to just stub out the call when not built with systemd support, which is
+> pretty trivial to do with Autoconf and means that those who want systemd
+> integration get it and those who don't care can easily ignore it.
+
+The lowest-impact library dependency is still pretty large, from the
+perspective of the typical daemon upstream.  Plenty of projects don't use
+autoconf.  Some aren't written in C at all and would need bindings (or to
+reimplement the base logic natively).
+
+There is an elegance to sd_notify() that appeals to you, I can understand
+that.  But as Ian's response demonstrates, it doesn't appeal to everybody.
+
+I think the next-generation init system should bring solutions that improve
+things for all consumers, not just to those maintainers for whom introducing
+an init-system-specific external library dependency is compatible with their
+sense of aesthetics.  You say that both upstart and systemd are
+backwards-compatible, for those who don't want to adopt their respective
+readiness interfaces.  That's true, but that just means
+backwards-compatibility with a world of bugs that we should strive to
+eliminate.  There are all kinds of race conditions in the init scripts we
+have today in Debian, caused by improper daemonization (forking/detaching
+before listening, etc.).  I think declaring that upstreams that don't want
+to use sd_notify() (or change to use socket-based activation) can just use
+the backwards-compatibility means we fall short of the kind of
+across-the-board uplift that we should seek to achieve.
+
+This discussion makes it clear to me that the SIGSTOP approach /also/
+doesn't achieve that, due to equal but opposite aesthetic preferences on the
+part of different groups of maintainers.  :) So I'm in favor of upstart
+implementing sd_notify, alongside its existing SIGSTOP handling.
+
+But I think it doesn't make sense to treat it as a mark against upstart, for
+Debian's purposes, that upstart started from the more conservative end of
+the spectrum on this question while systemd was more ambitious.  If
+anything, the long time it's taken Debian to even seriously consider the
+question of moving to upstart shows that by at least one relevant measure,
+even upstart was being too aggressive. :/
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 09:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 09:33:05 GMT) (full text, mbox, link).

+ +

Message #1759 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd and support for other distros
+
Date: Mon, 30 Dec 2013 01:29:17 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 02, 2013 at 02:48:52PM -0800, Russ Allbery wrote:
+> > Sure.  Both systemd and upstart manage to avoid the problem of
+> > inconsistent behavior due to tainted admin environments, because daemons
+> > are always started as children of init and not of the admin's login
+> > shell.  That being the case, hard-coding the path to an executable in
+> > your initscript equivalent doesn't buy you much added protection,
+> > compared with just using the system $PATH, and does cause gratuitous
+> > incompatibilities in exactly those cases that Debian Policy's
+> > prohibition on hard-coded paths is meant to address.
+
+> I have never seen a gratuitous incompatibility caused by this.  Do you
+> have any examples?
+
+I would argue that every single result returned by
+'ls -l /usr/sbin/ /usr/bin|grep /bin', preventing us from merging /usr/
+into / by default, is an example of such historical incompatibilities.  But
+any other cases where binaries have moved from one directory or another
+without providing such compat symlinks would also qualify.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 09:33:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 09:33:08 GMT) (full text, mbox, link).

+ +

Message #1764 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Mon, 30 Dec 2013 10:31:33 +0100
+
+
]] Steve Langasek 
+
+> I'm also interested to know how systemd purports to handle the exceptional
+> cases, where a dependency on basic.target is not possible.  
+
+In general «you need to write the dependencies manually, then».  As
+you're pointing out in your mail, that can get tricky to get right.
+
+> The nfs-common and rpcbind packages currently have no integration with
+> systemd, so they get the default behavior for SysV services in rcS.d:
+> WantedBy=sysinit.target, Before=sysinit.target.  But there's nothing which
+> documents that sysinit.target is a precondition for remote-fs.target, so in
+> its current state, mounting of remote filesystems at boot is almost
+> certainly racy with systemd in Debian.
+
+That looks buggy or racy indeed.
+
+> What is the right way to make nfs-common behave correctly on startup with
+> systemd?  Is there a reason that sockets.target is only a dependency of
+> basic.target, not of remote-fs-pre.target, which would enable use of
+> socket-based activation for fs helper daemons like those in nfs-common? 
+
+rpcbind.socket would have a Before=rpcbind.service automatically
+(assuming we want socket activation).  In addition, I imagine you'd want
+the various daemons to have After + Wants on rpcbind.service and
+rpcbind.service to be before=remote-fs-pre.target and
+WantedBy=remote-fs-pre.target.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 10:06:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 10:06:07 GMT) (full text, mbox, link).

+ +

Message #1769 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Cc: James Hunt <james.hunt@ubuntu.com>
+
Subject: Re: Bug#727708: upstart user jobs
+
Date: Mon, 30 Dec 2013 02:03:22 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Hi Ian,
+
+On Sat, Dec 14, 2013 at 12:31:57PM +0000, Ian Jackson wrote:
+> I have some questions about these.  Forgive me if I could just have
+> looked up the answers:
+
+> Are they enabled by default in jessie/sid ?
+> (If the answer is "no" then feel free not to answer the rest...)
+
+"No" :)
+
+Using upstart user jobs in Debian would imply a whole added level of
+transition above and beyond adoption of upstart as init, and would require
+coordination with maintainers of e.g. desktop environment packages and
+display manager packages.  I think it would be a logical next step for
+Debian to consider, if it adopted upstart as a default; but so long as
+upstart is not the default in Debian I don't think it would be a good idea
+to try to support this in Debian.
+
+> In the manpage I read:
+>   | Note that a user job configuration file cannot have the same name
+>   | as a system job configuration file.
+> I don't understand this restriction.  It's sounds like it's referring
+> to the pathnames in which case it's trivially true, so I assume it's
+> referring to job names.
+
+Hmm, this sounds like a documentation bug, a throwback to an earlier
+iteration of the user job support.  Which manpage did you find this in?
+
+The current implementation certainly has no such restriction.  For instance,
+on an Ubuntu system there are both /etc/init/dbus.conf and
+/usr/share/upstart/sessions/dbus.conf, for the system bus and the session
+bus respectively, and these do not collide.  System-level events are visible
+to the user session, but they are qualified with a disambiguating ":sys:"
+prefix.
+
+> Does anything that user jobs do depend on upstart being pid 1, or
+> being root ?  Does the thing which reads (and watches) the user's
+> configuration files run as root, or as the user ?  I.e., what is the
+> privilege separation ?
+
+The upstart "session init" runs as the user, not as root.  I'm not sure if
+upstart as a user session has any dependencies on upstart being PID 1. 
+Cc:ing James, who would know better - James, do you know if upstart session
+init works on non-upstart systems?
+
+> The docs say:
+>  | Files in this directory will be read and an inotify(7) watch
+>  | created the first time a user runs initctl(8).
+> Does this really mean that if I'm fiddling around with writing some
+> jobs, but not quite ready yet, and say "initctl --help", my jobs will
+> start to run ?  Also, it would appear to imply that user jobs aren't
+> started automatically at boot.
+
+This seems to be a quote from the 1.6.1 version of the manpage, in wheezy. 
+The user session support in the current releases of upstart (the only
+implementation that's been used in production in Ubuntu) doesn't work this
+way; and the manpage has been updated to match.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 14:24:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Florian Weimer <fw@deneb.enyo.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 14:24:19 GMT) (full text, mbox, link).

+ +

Message #1774 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Florian Weimer <fw@deneb.enyo.de>
+
To: Josselin Mouette <joss@debian.org>
+
Cc: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: systemd jessie -> jessie+1 upgrade problems
+
Date: Mon, 30 Dec 2013 15:04:40 +0100
+
+
* Josselin Mouette:
+
+> Le mardi 17 décembre 2013 à 12:26 -0800, Russ Allbery a écrit :
+>> > Is there actually any implementation other than glib2.0 and libdbus that
+>> > would be affected by a switch to kdbus?
+>> 
+>> This is an interesting question.  Josselin, is GNOME (for example) likely
+>> to acquire a hard dependency on kdbus through some mechanism?  I don't
+>> understand the plumbing of this stuff well enough to know where the
+>> dependencies could surface.
+>
+> That doesn’t seem very likely to me. In terms of library API, kdbus
+> doesn’t change anything, so there is no need for applications to depend
+> on it.
+
+Isn't it fairly likely that some libraries or applications will use
+kdbus directly because their developers dislike the existing
+libraries?  It happens all the time with other kernel functionality
+(inotify and its cousins, netlink, etc.).
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 16:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 16:45:04 GMT) (full text, mbox, link).

+ +

Message #1779 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org, 733452@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>, Andreas Barth <aba@ayous.org>
+
Subject: Re: Bug#727708: upstart proposed policy in Debian [and 1 more messages]
+
Date: Mon, 30 Dec 2013 08:44:07 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> The lowest-impact library dependency is still pretty large, from the
+> perspective of the typical daemon upstream.  Plenty of projects don't
+> use autoconf.  Some aren't written in C at all and would need bindings
+> (or to reimplement the base logic natively).
+
+I still don't entirely agree with this, although the point about language
+bindings is certainly valid.  (I'm tempted to just fix that problem for
+Perl, since no one seems to have to date, but that supports your point.)
+But I don't think there's a need to debate it, since as noted below I'm
+not sure it really matters.
+
+> But I think it doesn't make sense to treat it as a mark against upstart,
+> for Debian's purposes, that upstart started from the more conservative
+> end of the spectrum on this question while systemd was more ambitious.
+> If anything, the long time it's taken Debian to even seriously consider
+> the question of moving to upstart shows that by at least one relevant
+> measure, even upstart was being too aggressive. :/
+
+Note that I didn't include anything about the notification policy in my
+writeup.  That's because after further consideration, I agreed: I don't
+consider this a notable advantage to either system.
+
+(I probably owe everyone an additional followup message listing some of
+the things that I don't think are differentiators, in part to call out
+what I consider exemplary support from multiple different projects over
+the course of this evaluation.  I'm very grateful to both the upstart and
+the systemd teams for the work they've already done on integration and
+their responses during my discovery process.)
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 16:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 16:48:04 GMT) (full text, mbox, link).

+ +

Message #1784 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd and support for other distros
+
Date: Mon, 30 Dec 2013 08:45:21 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+> On Mon, Dec 02, 2013 at 02:48:52PM -0800, Russ Allbery wrote:
+
+>> I have never seen a gratuitous incompatibility caused by this.  Do you
+>> have any examples?
+
+> I would argue that every single result returned by 'ls -l /usr/sbin/
+> /usr/bin|grep /bin', preventing us from merging /usr/ into / by default,
+> is an example of such historical incompatibilities.  But any other cases
+> where binaries have moved from one directory or another without
+> providing such compat symlinks would also qualify.
+
+Ah, yes, thank you.  Having to maintain those compatibility symlinks is
+indeed a burden that's incurred by using fully-qualified paths.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 16:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 16:54:04 GMT) (full text, mbox, link).

+ +

Message #1789 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Mon, 30 Dec 2013 08:51:13 -0800
+
+
Tollef Fog Heen <tfheen@err.no> writes:
+> ]] Russ Allbery 
+
+>> I think the upstart approach is better, but I think the drawbacks of
+>> the systemd approach could be mostly overcome with some fairly simple
+>> Debian tools.
+
+> We were initially considering using ucf and checking if the file in /etc
+> had changed (before we had per-line overrides and such), but with the
+> more complex overrides now available, I think systemd-delta is a better
+> solution.  I guess we could integrate that into the packaging somehow
+> and present a useful UI if you've overridden a line that changes.
+
+Right, several people have pointed me at systemd-delta, but your last
+sentence was the tool that I was driving at.  systemd-delta tells you
+whether you're currently overriding something, which is a useful building
+block, but which doesn't restore conffile upgrade handling.  What's needed
+to keep existing Debian behavior is a tool that tells you whether the
+maintainer and the local system administrator have changed the
+configuration in conflicting ways so that something is now being
+overridden that was not being overridden before.
+
+In other words, systemd-delta does a two-way diff, but what's needed here
+is a three-way diff plus integration into the packaging system so that, as
+with conffile changes now, the upgrade (by default) stops and prompts the
+local systems administrator with the orthogonal differences and lets them
+choose how to handle the situation.
+
+I don't think this would be particularly difficult to implement on top of
+systemd-delta, although the details may be tricky to get right and may
+require a few iterations.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 16:54:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 16:54:07 GMT) (full text, mbox, link).

+ +

Message #1794 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve Langasek <vorlon@debian.org>, + 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: systemd and upstart, a view from a daemon Debian maintainer
+
Date: Mon, 30 Dec 2013 16:51:55 +0000
+
+
Steve Langasek writes ("Bug#727708: systemd and upstart, a view from a daemon Debian maintainer"):
+> I also think that the extensive maintainer script changes required for any
+> upstart-using package are quite deplorable (whether or not they're wrapped
+> in a helper script + debhelper snippet).  [...]
+
+Did you mean 
+  the extensive maintainer script changes required for any
+  systemd-using package are quite deplorable
+  ^^^^^^^
+?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 17:03:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 17:03:12 GMT) (full text, mbox, link).

+ +

Message #1799 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Tollef Fog Heen <tfheen@err.no>, + 733452@bugs.debian.org, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion [and 1 more messages]
+
Date: Mon, 30 Dec 2013 17:01:33 +0000
+
+
Tollef Fog Heen writes ("Bug#727708: init system other points, and conclusion"):
+> Ian Jackson:
+> > This is exacerbated by the fact that systemd's Debian maintainers are
+> > (IMO) much too deferential to upstream.
+> 
+> That's because the bits of systemd you've asked to change isn't just a
+> piece of software.  It's a standardised API, and you're effectively
+> asking us to change that API.  I think it's pretty clear why that is a
+> bad idea.
+
+Which of my three rejected proposals are you discussing ?
+
+That systemd support SIGSTOP readiness indication; that it support a
+different simpler readiness protocol; or that it allow relative
+pathnames in unit files ?
+
+Of these your objection clearly doesn't apply to the first two.
+systemd already supports around four readiness signally protocols
+(depending how count them); adding another would certainly not break
+anything.
+
+The last one - relative pathnames - is a strict enhancement.  The
+only effect would be that Debian's unit files wouldn't necessarily
+work on older systemds which didn't have the patch.
+
+Tollef Fog Heen writes ("Bug#733452: init system daemon readiness protocol"):
+> It seems Lennart read the proposal and responded in
+> https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/37AWJLE3XcJ
+
+In the light of this message from Lennart, and the example code, it
+seems that the documentation is not adequate.
+
+Lennart writes:
+ | sending a message to $NOTIFY_SOCKET would require setting
+ | SCM_CREDENTIALS (wrong!),
+
+But the only documentaton I can find for this protocol is in
+sd_notify(3), which says[1]:
+
+ | The datagram is accompanied by the process
+ | credentials of the sending daemon, using SCM_CREDENTIALS.
+
+If this is not required by systemd, why is it done by sd_notify ?
+Is this actually the right documentation to be reading ?
+
+Ian.
+
+
+[1] http://manpages.debian.net/cgi-bin/man.cgi?query=sd_notify&sektion=3&apropos=0&manpath=Debian+testing+jessie&locale=
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 17:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 17:09:04 GMT) (full text, mbox, link).

+ +

Message #1804 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Mon, 30 Dec 2013 09:05:57 -0800
+
+
Russ Allbery <rra@debian.org> writes:
+
+> * Red Hat adopted upstart but never did a wholescale conversion, and then
+>   abandoned upstart in favor of systemd.  Obviously, one should not put
+>   too much weight on this; Red Hat is a commercial company that has a
+>   wealth of reasons for its actions that do not apply to Debian.  But I
+>   think it's still worth noting that the only non-Ubuntu major adopter of
+>   upstart backed away from it.
+
+[...]
+
+>   By comparison, upstart is effectively used only by Ubuntu, [...]
+
+Both of these statements are incorrect.
+
+I'm sure that somewhere in the many vast threads that we've had over the
+init system, someone pointed out to me that Google's Chromium OS and
+Chrome OS use upstart.  Now that I've been reminded of this, I think Steve
+also mentioned it in the discussion of how upstart's upstream and
+packaging development were handled.  However, it had completely dropped
+out of my mind and I was unaware of it while writing the above statements.
+
+I apologize for the misrepresentation.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 17:39:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 17:39:08 GMT) (full text, mbox, link).

+ +

Message #1809 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org, + James Hunt <james.hunt@ubuntu.com>
+
Subject: Re: Bug#727708: upstart user jobs
+
Date: Mon, 30 Dec 2013 17:35:49 +0000
+
+
Steve Langasek writes ("Re: Bug#727708: upstart user jobs"):
+> On Sat, Dec 14, 2013 at 12:31:57PM +0000, Ian Jackson wrote:
+> > I have some questions about these.  Forgive me if I could just have
+> > looked up the answers:
+> 
+> > Are they enabled by default in jessie/sid ?
+> > (If the answer is "no" then feel free not to answer the rest...)
+> 
+> "No" :)
+> 
+> Using upstart user jobs in Debian would imply a whole added level of
+> transition above and beyond adoption of upstart as init, and would require
+> coordination with maintainers of e.g. desktop environment packages and
+> display manager packages.  I think it would be a logical next step for
+> Debian to consider, if it adopted upstart as a default; but so long as
+> upstart is not the default in Debian I don't think it would be a good idea
+> to try to support this in Debian.
+
+I'm not sure I see the connection.  AIUI user jobs are a way to do
+roughly what cron's @reboot facility does, only better.
+
+> > In the manpage I read:
+> >   | Note that a user job configuration file cannot have the same name
+> >   | as a system job configuration file.
+> > I don't understand this restriction.  It's sounds like it's referring
+> > to the pathnames in which case it's trivially true, so I assume it's
+> > referring to job names.
+> 
+> Hmm, this sounds like a documentation bug, a throwback to an earlier
+> iteration of the user job support.  Which manpage did you find this in?
+
+http://manpages.debian.net/cgi-bin/man.cgi?query=init&sektion=5&apropos=0&manpath=Debian+testing+jessie&locale=
+
+> > The docs say:
+> >  | Files in this directory will be read and an inotify(7) watch
+> >  | created the first time a user runs initctl(8).
+> > Does this really mean that if I'm fiddling around with writing some
+> > jobs, but not quite ready yet, and say "initctl --help", my jobs will
+> > start to run ?  Also, it would appear to imply that user jobs aren't
+> > started automatically at boot.
+> 
+> This seems to be a quote from the 1.6.1 version of the manpage, in wheezy. 
+> The user session support in the current releases of upstart (the only
+> implementation that's been used in production in Ubuntu) doesn't work this
+> way; and the manpage has been updated to match.
+
+OK, good, thanks.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 17:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 17:45:04 GMT) (full text, mbox, link).

+ +

Message #1814 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion [and 1 more messages]
+
Date: Mon, 30 Dec 2013 18:43:07 +0100
+
+
]] Ian Jackson 
+
+> Tollef Fog Heen writes ("Bug#727708: init system other points, and conclusion"):
+> > Ian Jackson:
+> > > This is exacerbated by the fact that systemd's Debian maintainers are
+> > > (IMO) much too deferential to upstream.
+> > 
+> > That's because the bits of systemd you've asked to change isn't just a
+> > piece of software.  It's a standardised API, and you're effectively
+> > asking us to change that API.  I think it's pretty clear why that is a
+> > bad idea.
+> 
+> Which of my three rejected proposals are you discussing ?
+
+All of them.  It means that you can't test and verify that a daemon
+works correctly with systemd in Debian and expect it to work the same
+with systemd in other distributions.
+
+I'm not saying those kinds of changes are unwanted.  I'm saying they
+should go upstream and that I am unwilling to carry those patches in the
+Debian package.
+
+> Tollef Fog Heen writes ("Bug#733452: init system daemon readiness protocol"):
+> > It seems Lennart read the proposal and responded in
+> > https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/37AWJLE3XcJ
+> 
+> In the light of this message from Lennart, and the example code, it
+> seems that the documentation is not adequate.
+
+I think you're just being confused by it giving you some information you
+don't need.  The documentation in question reads: 
+
+  Internally, these functions send a single datagram with the state
+  string as payload to the AF_UNIX socket referenced in the
+  $NOTIFY_SOCKET environment variable. If the first character of
+  $NOTIFY_SOCKET is «@», the string is understood as Linux abstract
+  namespace socket. The datagram is accompanied by the process
+  credentials of the sending daemon, using SCM_CREDENTIALS.
+
+  For details about the algorithms check the liberally licensed
+  reference implementation sources:
+  http://cgit.freedesktop.org/systemd/systemd/plain/src/libsystemd-daemon/sd-daemon.c
+  and
+  http://cgit.freedesktop.org/systemd/systemd/plain/src/systemd/sd-daemon.h
+
+SCM_CREDENTIALS is generally not something the sender sends, it's
+something the receiver sets on the socket using SO_PASSCRED.
+
+> If this is not required by systemd, why is it done by sd_notify ?
+
+It's not.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 18:12:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to gregor herrmann <gregoa@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 18:12:11 GMT) (full text, mbox, link).

+ +

Message #1819 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: gregor herrmann <gregoa@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Mon, 30 Dec 2013 19:09:21 +0100
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, 30 Dec 2013 09:05:57 -0800, Russ Allbery wrote:
+
+> >   By comparison, upstart is effectively used only by Ubuntu, [...]
+> Both of these statements are incorrect.
+> I'm sure that somewhere in the many vast threads that we've had over the
+> init system, someone pointed out to me that Google's Chromium OS and
+> Chrome OS use upstart.  
+
+Maemo5 also uses upstart (a quite old version but after all, almost
+everything there is quite old).
+
+Cheers,
+gregor
+
+-- 
+ .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
+ : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
+ `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
+   `-   NP: Supertramp: Ain't Nobody But Me
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 18:33:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 18:33:08 GMT) (full text, mbox, link).

+ +

Message #1824 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve Langasek <vorlon@debian.org>, + 727708@bugs.debian.org
+
Cc: 726763@bugs.debian.org, + 729576@bugs.debian.org, + systemd@packages.debian.org
+
Subject: Re: Bug#727708: systemd-shim uploaded to NEW
+
Date: Mon, 30 Dec 2013 18:29:10 +0000
+
+
Steve Langasek writes ("Bug#727708: systemd-shim uploaded to NEW"):
+> So I repeat here my request that the systemd maintainers make a suitable
+> split of the systemd binary package, so that systemd-shim will be
+> coinstallable with the systemd-provided implementations of the other dbus
+> services.
+
+Is there a summary of the systemd maintainers' response to this
+request ?  I glanced #726763 and #729576 but they were very long and
+if the answer is in there I probably wouldn't have found it.
+
+>  The only alternative I see is for systemd-shim to declare a
+> Replaces: against systemd without a Conflicts,
+
+This would be quite wrong; Replaces is not supposed to be used like
+that (but you apparently know that).
+
+How do the systemd maintainers think this problem should be solved ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 18:45:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Raphael Hertzog <hertzog@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 18:45:12 GMT) (full text, mbox, link).

+ +

Message #1829 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Raphael Hertzog <hertzog@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Cc: Steve Langasek <vorlon@debian.org>, 726763@bugs.debian.org, + 729576@bugs.debian.org, systemd@packages.debian.org
+
Subject: Re: Bug#727708: systemd-shim uploaded to NEW
+
Date: Mon, 30 Dec 2013 19:42:58 +0100
+
+
On Mon, 30 Dec 2013, Ian Jackson wrote:
+> >  The only alternative I see is for systemd-shim to declare a
+> > Replaces: against systemd without a Conflicts,
+> 
+> This would be quite wrong; Replaces is not supposed to be used like
+> that (but you apparently know that).
+> 
+> How do the systemd maintainers think this problem should be solved ?
+
+I don't know the specifics of systemd-shim, but dpkg-divert is the usual
+answer when you need/want to replace something without the consent of the
+other side.
+
+Cheers,
+-- 
+Raphaël Hertzog ◈ Debian Developer
+
+Discover the Debian Administrator's Handbook:
+→ http://debian-handbook.info/get/
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 18:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 18:48:04 GMT) (full text, mbox, link).

+ +

Message #1834 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Mon, 30 Dec 2013 10:47:16 -0800
+
+
This message is about a transition plan for an init system replacement and
+about how to handle portability to our non-Linux ports.  I'm keeping the
+same subject as Ian's message on the same basic topics and attaching it to
+the same thread, but this is more of a separate writeup than a reply.
+I'll reply to Ian's message separately.
+
+I've expressed my opinion separately about which init system we should
+choose.  This message is written from the assumption that we will choose
+either upstart or systemd as the init system for the non-Linux ports.  I
+believe either system would pose basically the same concerns.
+
+
+1. Role of Non-Linux Ports in Debian
+
+There has been a lot of discussion in various places, including the Debian
+mailing lists, about the utility of the non-Linux ports and about how much
+they should play a role in project decisions.  I think this deserves to be
+addressed directly here.
+
+One of the things that I love about Debian, and one of the reasons why I
+am involved in this project as opposed to a different distribution, is
+that it is a labor of love.  Debian is not driven by market forces; we
+have users and we want the distribution to work for them, but we're not
+competing for market share.  Debian does not make decisions based on
+simple popularity, or on customer counts.  Rather, Debian is a project of
+mutual cooperation among Debian's contributors.  We work on what we care
+about, regardless of whether that makes economic sense.
+
+It is not, in general, necessary to justify what you want to do in Debian.
+It doesn't matter if it's going to be used by thousands of people or two
+people.  If you can do your work to the standards that we expect to be
+maintained across the archive, and without negative impact on Debian's
+other contributors, you can work on whatever you love.  And, furthermore,
+we all support each other in our passions.  Debian is built on a culture
+of deference to other people's work, and reasonable accomodation to the
+projects that other people want to work on.
+
+Now, there is a fine balance here.  Deference to other people's work does
+not mean a requirement to join their work.  Reasonable accomodation does
+not mean that every Debian developer is required to test their software on
+non-Linux ports.  The goal is that all of us should be empowered to work
+on the things we are passionate about, which implicitly includes being
+empowered to not work on the things that are not of interest to us.
+Therefore, for some efforts, and specifically for the non-Linux port
+efforts, the work is mostly born by the porters.  They're expected to
+test, diagnose problems, and submit patches.  The deference and reasonable
+accomodation that we expect of Debian contributors is to merge those
+patches when they are reasonable, to not undermine the porting effort when
+there is a reasonable approach that preserves it, and to be aware of the
+implications of their packaging for those ports in the broad sense (such
+as qualifying build-dependencies with [linux-any] where appropriate).
+
+We do not expect Debian contributors to reject significant new upstream
+versions or significant new integrations because they will affect the
+non-Linux ports, or, for that matter, other projects in Debian.  We do
+expect those changes to follow the standards that we expect of Debian as a
+whole, and that porting efforts will be treated with deference and
+reasonable accomodation.
+
+I think this status applies to both our Hurd port and our kFreeBSD port.
+Those ports have different challenges, and arguably different levels of
+utility to general users, but as mentioned, I don't consider popularity to
+be a useful metric here.  It doesn't make any difference to me if the port
+is used by thousands of people or if it's only used by the people actively
+working on it: the same principles of deference and reasonable
+accomodation apply.
+
+I believe strongly that this is something that defines Debian as a project
+and is worth preserving.
+
+It's also worth saying here that I don't believe any of the above is
+particularly controversial within the project.  We have wide-ranging
+arguments about it in the abstract, and quite a few disparaging comments
+have been thrown around about the non-Linux ports in the init system
+discussion, which makes me sad.  But when it comes to the day-to-day work
+in the project, nearly all maintainers are quite good (and have been for
+years) about merging required patches for the Hurd and pushing them
+upstream, responding to bug reports on systems they don't use, and making
+a reasonable effort to accomodate other people's projects.
+
+Similarly, our non-Linux porters have been exemplary.  Neither the Hurd
+nor the kFreeBSD ports have expected every Debian contributor to directly
+support their platforms.  They track down problems, develop patches, and
+submit tested patches to the BTS.  They have developed their own solutions
+for packages that are not portable and worked out how to integrate them
+with the archive.
+
+Despite the often off-putting public arguments, and despite occasional
+tensions and counterexamples, by and large we do a good job at this.  And
+we should be proud of that.
+
+This is, of course, directly applicable to the init system discussion
+since neither systemd nor upstart are currently portable to either of our
+non-Linux ports.  It will continue to be directly applicable to this
+discussion even if upstart is ported to kFreeBSD until such time as it's
+also ported to the Hurd (or the Hurd porting group decides they're no
+longer interested in working on the port, but I don't expect that to
+happen).
+
+
+2. Impact of Multiple Init Systems
+
+Obviously, the ideal situation for project-wide integration and support,
+and for Debian's ability to make full use of the capabilities of new init
+systems, is for all of Debian's ports to be running the same init system.
+Attempting to support multiple init systems has several obvious drawbacks:
+
+* Packages will either be limited by the functionality of the least
+  capable init system or will behave differently (and have to be
+  configured differently) on different ports.
+
+* Nearly all Debian contributors are personally only going to be running
+  the default init system on the amd64 or i386 ports.  It's not viable to
+  ask them to test all packages on non-Linux ports.  This, plus the
+  distribution of our user base, means that the configuration for the
+  default init system is the one that will be tested, and configurations
+  for any other init system will tend to bitrot.
+
+* Related, Debian contributors will normally not be in a position to test
+  patches for daemons for non-Linux ports, and will be entirely reliant on
+  contributed patches from porters or users of those ports, which means
+  the level of quality we can maintain for those configurations will be
+  lower.
+
+* If we're going to support init system switching, we will have to
+  continue to externalize daemon configuration in files that are
+  compatible with the sysvinit system.  Both systemd and upstart have
+  better ways to handle local configuration than /etc/default files, but
+  their methods are incompatible (since they involve overriding the
+  init-system-specific configuration files in their own ways).  If we
+  fully adopt one of those init systems, we can largely drop the somewhat
+  clunky /etc/default machinery in favor of much simpler overrides or
+  direct conffile modifications.
+
+* Upstreams may, over time, drop support for init systems that are rarely
+  used outside of Debian's non-Linux ports.  I don't think this is likely
+  to happen soon, but I can anticipate a world in the future (particularly
+  if upstart adds support for the systemd socket activation protocol)
+  where some upstreams will strip support for fork and exit daemon startup
+  methods from their daemons, or require use of socket activation and
+  remove socket binding support.  In some cases, we already have tools to
+  deal with this; handling daemons that don't support fork and exit is
+  fairly easy, for example.  But in some cases we may not, and I think
+  maintaining full code for socket binding and setup as a patch that
+  upstream does not want is too much to ask from all Debian contributors.
+
+However, there are also some counter-balancing points:
+
+* All packages in Debian are already ported to sysvinit, which means that
+  the init scripts and related machinery already exist.  Furthermore,
+  maintaining Debian's normal support for partial upgrades and loose
+  upgrade ordering between stable releases requires that we continue to
+  support sysvinit scripts at least through the release of jessie.  In the
+  short term, we cannot avoid supporting two init systems if we're going
+  to provide robust upgrade support, which gives us short-term support of
+  the non-Linux ports for "free."
+
+* Shell init scripts are obnoxious to write and often have buggy corner
+  cases, but once written, they mostly keep working in their buggy glory
+  with some minor maintenance.  In other words, they don't do as good of a
+  job, but regressions are relatively uncommon.  This means that it is
+  possibly viable for porters to provide patches and continued maintenance
+  of init scripts for at least the services that are considered most
+  critical even if the primary maintainer cannot easily test.  Packages
+  with extremely complex init scripts will require someone do special
+  testing, but the number of such packages is relatively low.  This will
+  fail if upstreams start dropping required support for sysvinit-style
+  startup, but I don't think this will happen soon.
+
+* Maintaining init scripts is not, in the grand scheme of Debian work, one
+  of the harder things we do.  I think asking Debian contributors to
+  maintain sysvinit scripts when Debian's default init system is something
+  else falls outside the boundary of reasonable accomodation, but that's
+  mostly because of the testing requirement.  I do not think that leaving
+  init scripts in the package where they already exist and applying
+  patches from porters falls outside those boundaries.
+
+
+3. systemd and upstart As Multiple Systems
+
+I said a great deal above about Debian's non-Linux ports.  It's worth
+considering that the same statements potentially apply to multiple
+next-generation init systems.
+
+As we've seen from this debate, both upstart and systemd inspire
+passionate loyalties and preferences.  Having looked at both of them, I
+fully understand the feeling.  I have a strong personal preference for
+systemd, but upstart is a beautiful piece of code that would be a delight
+to work on.  It's clean, well-documented, consistent, and has an excellent
+test suite.  Both projects are working hard at writing something they
+believe in.
+
+Given that, I don't believe a Technical Committee choice of a default init
+system is going to make either the systemd or the upstart maintainers want
+to stop maintaining their packages.  For upstart, there is also the
+ongoing fact that Ubuntu uses upstart, and Ubuntu is one of our major
+downstreams and a collaborative project.
+
+I therefore think that, regardless of which init system we pick, we should
+keep in mind the above principle of Debian's deference and reasonable
+accomodation to other people's projects and apply that to systemd and
+upstart as well as to the non-Linux ports.  Obviously, this also has the
+same issues mentioned above: Debian contributors can only be expected to
+test on the primary init system, other configurations will tend to bitrot
+without active porter attention, and so forth.  But if people want to take
+on the work, that deserves our respect.
+
+
+4. Conclusions
+
+I previously argued that much of the benefit of a new init system comes
+from when we can stop maintaining init scripts.  I still believe that, but
+after thinking more about the cultural and project issues at stake here,
+as well as the immediate needs for a clean upgrade path, I ended up at
+more of a compromise position than I expected.
+
+I believe Debian should take this path forward:
+
+1. We should select a new init system for jessie, either systemd or
+   upstart.  Support for that init system should be release-critical, but
+   only in the sense that the daemon works properly under that init
+   system.  In other words, use of the sysvinit compatibility of either
+   init system is acceptable support for jessie.
+
+2. All packages providing init scripts must continue to support sysvinit
+   scripts through the jessie release.  Such support will continue to be
+   release-critical.  This is going to be painful for packages that want
+   to do an early conversion, since it means testing two different init
+   systems for this release cycle, but I think this is the right thing to
+   do regardless for a clean upgrade path and Debian's normal robust
+   committment to upgrades.  Here it has the additional advantage of
+   giving the non-Linux ports some breathing space to strategize.
+
+3. Related, up through the jessie release, packages must (where possible;
+   it's possible there will be cases where this is simply impossible)
+   support switching back and forth between the new default init system
+   and sysvinit.  This means that configurations should not be moved out
+   of /etc/default and that startup files for the new init system should
+   read the same configuration that the existing sysvinit scripts use (or
+   both should be modified compatibly).
+
+4. Post-jessie, support for sysvinit will no longer be release-critical,
+   and package maintainers will no longer be expected to ensure that it
+   continues working.  However, for as long as Debian has accepted
+   non-Linux ports using a different init system, package maintainers
+   should continue to ship init scripts if they work and should apply
+   patches and other reasonable fixes from porters for those init scripts.
+   In other words, this should be treated the same as merging patches for
+   the Hurd to remove hard-coded constant assumptions: if the change is
+   reasonable and doesn't break Linux ports (and this should be fairly
+   easy to handle for nearly all cases with init scripts), the package
+   maintainer should merge it.
+
+5. Support for the other init system that was not chosen should be handled
+   in the same fashion, should a team choose to pursue it.  If we select
+   systemd, package maintainers should still be willing to merge
+   contributed upstart configuration, with the understanding that they
+   can't test it and any support is on a best-effort basis only.
+   Similarly, if we select upstart, package maintainers should be willing
+   to merge systemd unit files and to enable upstream systemd support
+   where requested and where it doesn't interfere with the operation of
+   the daemon under upstart, with the understanding that the package
+   maintainer is not committing to testing or directly supporting this
+   configuration.
+
+6. Debian's non-Linux ports should either use the same init system as
+   Debian's Linux ports or agree on an init system that they're both going
+   to use.  The porting work is going to be hard enough without the ports
+   going in different directions on which secondary init system they want
+   to use.  I prefer to leave it up to the porters to decide which init
+   system to choose, but I do think OpenRC would be a strong contender.
+
+7. After jessie, functionality between systems running the primary Linux
+   init system and other init systems (including non-Linux ports) should
+   be allowed to drift.  In other words, there will be cases where
+   features will only be available with the primary init system.  Possible
+   examples include security hardening, socket activation, automatic
+   daemon restarts, and so forth.  Packagers are under no obligation to
+   port those features to other init systems, but should welcome and merge
+   patches that do so.  After jessie, packagers will no longer be required
+   to preserve daemon configuration when the init system is switched, so
+   use of such facilities as modification of upstart configuration files
+   or systemd overrides may be used.
+
+We should revisit this decision again after the jessie release in case the
+situation has substantially changed.
+
+This is all rather unsatisfying all around, I realize.  Debian is going to
+miss out on some opportunities to pursue new init system features
+aggressively and consistently across the archive, particularly for the
+jessie release where we're maintaining full sysvinit compatibility, if we
+take this posture to both upgrade compatibility and deference to porting
+efforts.  And this is also going to increase the porting work required for
+non-Linux ports substantially, since the init scripts will have to be
+included in that and porting won't be as easily measured by buildd logs.
+
+However, I think it's the best available approach that balances our ideals
+as a project against the opportunities offered by a new init system.  This
+approach does permit full use of new init system features for jessie
+except for eliminating /etc/default files (which I doubt we'd successfully
+do quickly anyway), and opens up the full spectrum of use cases after
+jessie.  The cost is that packagers should merge contributed patches to
+the init systems that they don't use.  I don't think this is too much to
+ask, nor do I think it will have serious effects on package complexity
+based on my own experience configuring a package to work under all three
+init systems I considered.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 19:00:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 19:00:09 GMT) (full text, mbox, link).

+ +

Message #1839 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Mon, 30 Dec 2013 18:58:37 +0000
+
+
Russ Allbery writes ("Bug#727708: init system other points, and conclusion"):
+> We seem to be at the point of the process where at least those of us who
+> did early investigation are stating conclusions.  I think I have enough
+> information to state mine, so will attempt to do so here.
+
+Thanks.
+
+> First, other choices besides systemd and upstart.
+
+I agree with your comments here; it appears you've investigated OpenRC
+in more detail than I have but I'm happy to take your word for it.
+
+
+> 2. Core Service Management Functionality
+...
+> To my surprise, that's not what happened.  Rather, I concluded that
+> systemd has a substantial technical advantage over upstart, primarily in
+> terms of available useful features, but also in terms of fundamental
+> design.
+
+I think we have fundamentally different ideas about what the
+replacement init ought to be like.  I don't think either of us will
+convince the other.
+
+
+> 3. Ecosystem and Portability
+...
+> 3.1. Ecosystem Reality Check
+...
+> Rather, we're talking about whether or not to swap out a core component of
+> an existing integrated ecosystem with a component that we like better.
+
+Unless you are proposing to make systemd mandatory for all Debian
+installations, this is work that needs to be done anyway.
+
+Also, I get the impression me that the "integration" of much of this
+functionality into the systemd source package has been done for
+political rather than technical reasons.  Indeed to the extent that
+there is a problematically tight technical coupling between these
+components, I find it difficult to avoid doubting the good faith of
+the people making those decisions.  At the very least, I worry that
+the systemd project as a whole is far too willing to impose decisions
+of all kinds on its downstreams.
+
+Under those kind of circumstances I am willing for the Debian project
+as a whole to go to quite some effort (and, indeed, impose some effort
+even on the maintainers of systemd in Debian) to retain the
+flexibility that I think is important.  That flexibility certainly
+includes the ability for a user to drop use of parts of systemd that
+they don't find desirable.
+
+> Now, I am generally on the side that says loose coupling of ecosystems is
+> an inherent good.  However, I don't agree that it's such an inherent good
+> that we should disassemble things just for the sake of having disassembled
+> things.  At feature parity, and absent any compelling reason to swap
+> components, I think we should take the path of least resistance and use
+> the integrations that other people have already developed.  Debian has
+> more than enough hard integration problems to solve without creating new
+> ones for ourselves unnecessarily.  But that's the key word: unnecessarily.
+> If we do have a reason for doing this, we should seriously consider it.
+
+If these problems have been created with reckless disregard for the
+flexibility needs of downstreams and users, then I take the opposite
+view.
+
+
+> 3.2. Portability
+...
+> So, in short, I consider portability to be a possible benefit of upstart,
+> but I'm inclined to discount that advantage for several reasons.  One,
+> it's not yet actually materialized and still may not,
+
+My understanding was that Dimitri had got upstart running on BSD.
+I can't imagine that this problem won't be solved (in Debian) for
+jessie.  We're not talking about some nonexistent hypothetical
+patchset.
+
+
+> 3.3. Project Momentum
+
+I don't see the outlook here the same way as you do.
+
+Furthermore, I am much less worried about Debian going it alone
+(although, of course, it's not alone) than you seem to be.  We have
+historically been entirely unafraid to do our own better things, even
+if it is more work and takes us longer.
+
+I felt that way when Debian was very much a minority interest.  That's
+far from the case nowadays; I've heard it asserted that Debian-based
+distros now account for a majority of traditional distro installs.  I
+guess numbers on that are all speculative but it is certainly true
+that we have a thriving ecosystem of our own.
+
+We have got where we are by doing things the way we think is best, not
+by simply following the herd.
+
+Of course you say that you prefer systemd, which still leads you to
+the opposite conclusion.  But I wanted to explicitly deal with this
+argument.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 19:09:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 19:09:12 GMT) (full text, mbox, link).

+ +

Message #1844 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Mon, 30 Dec 2013 19:06:47 +0000
+
+
Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
+> 1. Role of Non-Linux Ports in Debian
+
+I agree with most of this.
+
+> 2. Impact of Multiple Init Systems
+
+I don't want to do a blow-by-blow quote/rebuttal of this.
+
+> 3. systemd and upstart As Multiple Systems
+..
+> I therefore think that, regardless of which init system we pick, we should
+> keep in mind the above principle of Debian's deference and reasonable
+> accomodation to other people's projects and apply that to systemd and
+> upstart as well as to the non-Linux ports.  Obviously, this also has the
+> same issues mentioned above: Debian contributors can only be expected to
+> test on the primary init system, other configurations will tend to bitrot
+> without active porter attention, and so forth.  But if people want to take
+> on the work, that deserves our respect.
+
+Right.
+
+
+> 4. Conclusions
+...
+> 1. We should select a new init system for jessie, either systemd or
+>    upstart.  Support for that init system should be release-critical, but
+>    only in the sense that the daemon works properly under that init
+>    system.  In other words, use of the sysvinit compatibility of either
+>    init system is acceptable support for jessie.
+
+I agree.
+
+> 2. All packages providing init scripts must continue to support sysvinit
+>    scripts through the jessie release.  Such support will continue to be
+>    release-critical.  This is going to be painful for packages that want
+>    to do an early conversion, since it means testing two different init
+>    systems for this release cycle, but I think this is the right thing to
+>    do regardless for a clean upgrade path and Debian's normal robust
+>    committment to upgrades.  Here it has the additional advantage of
+>    giving the non-Linux ports some breathing space to strategize.
+
+Yes.
+
+> 3. Related, up through the jessie release, packages must (where possible;
+>    it's possible there will be cases where this is simply impossible)
+>    support switching back and forth between the new default init system
+>    and sysvinit.  This means that configurations should not be moved out
+>    of /etc/default and that startup files for the new init system should
+>    read the same configuration that the existing sysvinit scripts use (or
+>    both should be modified compatibly).
+
+Yes.
+
+> 4. Post-jessie, support for sysvinit will no longer be release-critical,
+>    and package maintainers will no longer be expected to ensure that it
+>    continues working.  [...]
+> 
+> 5. Support for the other init system that was not chosen should be handled
+>    in the same fashion, should a team choose to pursue it.  [...]
+
+I think it is probably premature for us to drop support for the other
+system in jessie+1.
+
+But we don't need to make this decision now.
+
+> 6. Debian's non-Linux ports should either use the same init system as
+>    Debian's Linux ports or agree on an init system that they're both going
+>    to use.  The porting work is going to be hard enough without the ports
+>    going in different directions on which secondary init system they want
+>    to use.  I prefer to leave it up to the porters to decide which init
+>    system to choose, but I do think OpenRC would be a strong contender.
+
+Is there some difficulty expected with upstart on hurd ?
+
+> We should revisit this decision again after the jessie release in case the
+> situation has substantially changed.
+
+I would be very reluctant to write now that the support for sysvinit,
+or the non-default new system, may be dropped in jessie+1.  That will
+result in premature rot and removal.
+
+It's also possible that some kind of compatibility mechanism will
+become available.
+
+I would like to leave this decision to the policy maintainers, with
+the expectation that the TC will probably need to decide.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 19:18:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 19:18:05 GMT) (full text, mbox, link).

+ +

Message #1849 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Mon, 30 Dec 2013 11:15:35 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
+
+>> 6. Debian's non-Linux ports should either use the same init system as
+>>    Debian's Linux ports or agree on an init system that they're both going
+>>    to use.  The porting work is going to be hard enough without the ports
+>>    going in different directions on which secondary init system they want
+>>    to use.  I prefer to leave it up to the porters to decide which init
+>>    system to choose, but I do think OpenRC would be a strong contender.
+
+> Is there some difficulty expected with upstart on hurd ?
+
+I don't know if anyone has looked at it, and in the absence of any
+practical experience, I think it's fair to expect some challenges.  The
+blog post on kFreeBSD porting indicated that the porting effort to date
+required eglibc and FreeBSD kernel changes.  It seems like a reasonable
+assumption that at least a similar level of effort will be required on
+Hurd, and I don't know if the Hurd has as mature (if incompatible)
+capabilities such as kqueue on FreeBSD to use to implement such things as
+inotify or epoll.
+
+I know very little about the Hurd, so basically I just don't know.
+
+> I would be very reluctant to write now that the support for sysvinit, or
+> the non-default new system, may be dropped in jessie+1.  That will
+> result in premature rot and removal.
+
+> It's also possible that some kind of compatibility mechanism will become
+> available.
+
+That's a reasonable point.  I have no objections to deferring that
+decision until after the jessie release.
+
+> I would like to leave this decision to the policy maintainers, with the
+> expectation that the TC will probably need to decide.
+
+Yeah, with my Policy hat on, I don't want any piece of that one.  I would
+be inclined to immediately escalate to the TC.  I don't believe that
+Policy's conservative consensus approach is going to work here, and I
+expect trying to be painful.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 20:00:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 20:00:07 GMT) (full text, mbox, link).

+ +

Message #1854 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Mon, 30 Dec 2013 11:56:33 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Russ Allbery writes ("Bug#727708: init system other points, and conclusion"):
+
+>> First, other choices besides systemd and upstart.
+
+> I agree with your comments here; it appears you've investigated OpenRC
+> in more detail than I have but I'm happy to take your word for it.
+
+I should be clear that I've not actually run the system.  I've tried to
+track down documentation and tried to understand what the project goals
+were.  It's quite possible that I've gotten some details wrong, and I
+would welcome any corrections from the OpenRC folks.
+
+>> Rather, we're talking about whether or not to swap out a core component
+>> of an existing integrated ecosystem with a component that we like
+>> better.
+
+> Unless you are proposing to make systemd mandatory for all Debian
+> installations, this is work that needs to be done anyway.
+
+What I'm hearing from both GNOME and KDE maintainers is that assuming
+systemd would save them a great deal of work.  I think having systemd be
+the only supported and tested option for at least some large package sets
+that heavily use the systemd infrastructure upstream is a not-unlikely
+long-term outcome.
+
+In other words, I think the long-term portability future of GNOME (and to
+a much lesser extent KDE, where the issue will be bitrot of unused
+configurations more than an intentional maintenance choice, and where I
+expect the system to at worst degrade functionality rather than stop
+working) to non-systemd platforms is already in some jeopardy, because
+it's not clear that resources will be available upstream to maintain those
+projects outside of the APIs that systemd supports.  That was, after all,
+the forcing moment that brought this whole debate to a head.
+
+One can, of course, have a wide variety of reactions to that.  As someone
+who considers portability to be an inherent good, I find it sad, although
+I don't have a full appreciation for what problems GNOME is trying to
+solve by increasing its reliance on systemd.  But I'm highly dubious that
+Debian will just single-handedly fix that, or that we would drop GNOME
+because we don't like upstream's integration decisions.
+
+> Also, I get the impression me that the "integration" of much of this
+> functionality into the systemd source package has been done for
+> political rather than technical reasons.
+
+I hear that you have this impression, but I completely disagree.  I find
+the amount of bad will and assumption of malice aimed at the systemd
+maintainers to be intensely depressing and unwarranted by any of the
+interactions that I've seen, and I've been doing a fair bit of reading.
+
+Lennart passionately argues his side.  So do you.  So do a lot of us.  We
+all tend to have strong technical opinions and a great deal of confidence
+in our own judgement.
+
+Personally, I'm putting contentions that systemd is doing a power grab or
+is merging things for political reasons into the same bucket as
+contentions that Technical Committee opinions are driven by current or
+past employer relationships.  I would prefer to assume good faith among
+the people involved and understand their projects on their own terms.
+
+> At the very least, I worry that the systemd project as a whole is far
+> too willing to impose decisions of all kinds on its downstreams.
+
+All upstreams do this.  I have yet to meet an upstream for any piece of
+software that doesn't care about that software working uniformly on its
+supported platforms.  systemd is entirely in line with normal upstream
+practice of trying to pick the best solution to a given problem and
+supporting it thoroughly, rather than incurring the maintenance burden of
+supporting multiple ways to do the same thing.
+
+This always involves imposing some decisions on downstreams unless
+downstreams are willing to fork around that decision.  It's already meant
+that some of Debian's decisions are being imposed on Red Hat because they
+were judged to be better solutions.
+
+In places where Debian needs to take a different approach for reasons of
+backward compatibility or existing integrations, obviously we should, and
+we should be sure that we have the flexibility to do so.  For example, I
+think we should disable the current systemd binfmt support in favor of our
+existing working solution.  I have not seen any indication that would be a
+problem.
+
+You made multiple proposals that do not reflect what Debian is doing
+*today*, and which are not *necessary* for Debian.  I don't think those
+are good test cases for upstream's willingness to accomodate Debian's
+needs.
+
+> My understanding was that Dimitri had got upstart running on BSD.
+
+The latest that I have seen on this porting effort is here:
+
+http://blog.surgut.co.uk/2013/11/libnih-upstart-dependency-ported-to.html
+
+I asked previously on this bug if someone had later news.  Do you have
+more information than that?
+
+The above is definitely not "upstart running on BSD."  That's upstart's
+underlying support library mostly working on BSD after disabling two
+features (that are required for upstart).  I haven't not heard whether the
+porting of upstart proper has started.  That will certainly be much easier
+once libnih is ported, but there are, for example, direct uses of epoll in
+upstart proper.  (I don't know if kFreeBSD already has a portability layer
+for epoll in terms of kqueue.)
+
+> Furthermore, I am much less worried about Debian going it alone
+> (although, of course, it's not alone) than you seem to be.  We have
+> historically been entirely unafraid to do our own better things, even if
+> it is more work and takes us longer.
+
+I think "worried" is an incorrect characterization of what I said.  What I
+said, rather, was:
+
+    I think we should make wise decisions about which areas we want to
+    invest project effort.  I dislike investing significant project effort
+    in catch-up efforts that, when complete, merely get us back to where
+    we would have been if we'd chosen a different solution.  I don't think
+    that's wise stewardship of project resources.  I want to see Debian
+    focus its efforts on places where we can make a real difference, where
+    we can be leaders.  That means adopting the best-of-breed existing
+    solutions and building on top of them, not reinventing wheels and
+    thereby starting from a trailing position.
+
+upstart is a great project, of which its maintainers are deservedly proud.
+However, I don't agree that it's better than systemd.  My own research
+convinced me of the opposite.  But putting that aside, my point in that
+section is that, given feature parity (and I mean "feature" expansively,
+including adaptibility to Debian's needs), we should choose systemd
+because it has more project momentum and better existing integration,
+which means that we will have to spend less energy on it and will have
+more energy to spend on other things.
+
+It's absolutely worth doing our own, better things.  What I don't want to
+do is our own *worse* things.  Or, for that matter, our own equivalent
+things, when we could instead use work that already exists.  It's a waste
+of energy.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 20:00:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to cameron <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 20:00:10 GMT) (full text, mbox, link).

+ +

Message #1859 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: cameron <camerontnorman@gmail.com>
+
To: Tollef Fog Heen <tfheen@err.no>, 727708@bugs.debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion [and 1 + more messages]
+
Date: Mon, 30 Dec 2013 19:50:04 -0008
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 30, 2013 at 9:43 AM, Tollef Fog Heen <tfheen@err.no> wrote:
+
+>>  If this is not required by systemd, why is it done by sd_notify ?
+>> 
+> It's not.
+> 
+
+You obviously did not read the code. It is. Here is a G+ convo with 
+Lennart I had:
+
+> As a sender you only have to set SCM_CREDENTIALS manually if you 
+want to 
+> fake it (for which you need privs however).
+
+sd_notify() basically impersonates the process. You only need to set 
+SCM manually if you are writing an external library. If someone is just 
+doing it in the daemon, the kernel will set SCM_CREDENTIALS 
+automatically.
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 20:06:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Pouar <thepouar@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 20:06:07 GMT) (full text, mbox, link).

+ +

Message #1864 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Pouar <thepouar@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Go with Upstart
+
Date: Mon, 30 Dec 2013 14:02:46 -0600
+
+
[Message part 1 (text/plain, inline)]
+
While systemd is my favorite init system. Debian will probably be better 
+off with upstart for the reasons Ian said, especially portability. The 
+reason Fedora and RHEL didn't have a problem is they only use the Linux 
+Kernel, while Debian also uses kFreeBSD and the GNU Hurd.
+-- 
+Pouar
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 20:09:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 20:09:12 GMT) (full text, mbox, link).

+ +

Message #1869 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: systemd and upstart, a view from a daemon Debian + maintainer
+
Date: Mon, 30 Dec 2013 12:07:44 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 30, 2013 at 04:51:55PM +0000, Ian Jackson wrote:
+> Steve Langasek writes ("Bug#727708: systemd and upstart, a view from a daemon Debian maintainer"):
+> > I also think that the extensive maintainer script changes required for any
+> > upstart-using package are quite deplorable (whether or not they're wrapped
+> > in a helper script + debhelper snippet).  [...]
+
+> Did you mean 
+>   the extensive maintainer script changes required for any
+>   systemd-using package are quite deplorable
+>   ^^^^^^^
+> ?
+
+Ahahaha.  Yes, yes I did. ;)
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 20:39:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 20:39:09 GMT) (full text, mbox, link).

+ +

Message #1874 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Cc: James Hunt <james.hunt@ubuntu.com>
+
Subject: Re: Bug#727708: upstart user jobs
+
Date: Mon, 30 Dec 2013 12:35:36 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 30, 2013 at 05:35:49PM +0000, Ian Jackson wrote:
+> Steve Langasek writes ("Re: Bug#727708: upstart user jobs"):
+> > On Sat, Dec 14, 2013 at 12:31:57PM +0000, Ian Jackson wrote:
+> > > I have some questions about these.  Forgive me if I could just have
+> > > looked up the answers:
+
+> > > Are they enabled by default in jessie/sid ?
+> > > (If the answer is "no" then feel free not to answer the rest...)
+
+> > "No" :)
+
+> > Using upstart user jobs in Debian would imply a whole added level of
+> > transition above and beyond adoption of upstart as init, and would require
+> > coordination with maintainers of e.g. desktop environment packages and
+> > display manager packages.  I think it would be a logical next step for
+> > Debian to consider, if it adopted upstart as a default; but so long as
+> > upstart is not the default in Debian I don't think it would be a good idea
+> > to try to support this in Debian.
+
+> I'm not sure I see the connection.  AIUI user jobs are a way to do
+> roughly what cron's @reboot facility does, only better.
+
+The topic of upstart user jobs has evolved since upstart 1.6.  As they're
+used in Ubuntu 13.04 and later, the entire desktop session is run as a set
+of upstart jobs, giving service supervision and better cleanup handling on
+logout.  That is not something that we should try to enable in the upstart
+package in Debian without careful coordination with other maintainers.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 20:54:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 20:54:10 GMT) (full text, mbox, link).

+ +

Message #1879 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Cc: 726763@bugs.debian.org, 729576@bugs.debian.org, systemd@packages.debian.org
+
Subject: Re: Bug#727708: systemd-shim uploaded to NEW
+
Date: Mon, 30 Dec 2013 21:52:37 +0100
+
+
]] Ian Jackson 
+
+> Steve Langasek writes ("Bug#727708: systemd-shim uploaded to NEW"):
+> > So I repeat here my request that the systemd maintainers make a suitable
+> > split of the systemd binary package, so that systemd-shim will be
+> > coinstallable with the systemd-provided implementations of the other dbus
+> > services.
+> 
+> Is there a summary of the systemd maintainers' response to this
+> request ?  I glanced #726763 and #729576 but they were very long and
+> if the answer is in there I probably wouldn't have found it.
+
+I see no point in doing that, in particular not in the middle of when
+the ctte is choosing a new default init system.  If anything, I think
+it's pretty rude of Steve to upload systemd-shim and asking the systemd
+maintainers to solve the problem for him.
+
+> >  The only alternative I see is for systemd-shim to declare a
+> > Replaces: against systemd without a Conflicts,
+> 
+> This would be quite wrong; Replaces is not supposed to be used like
+> that (but you apparently know that).
+> 
+> How do the systemd maintainers think this problem should be solved ?
+
+Initially, by waiting for the ctte to come to a conclusion.  If that is
+that systemd should be the default init system I think we should solve
+the problem by not solving it.  If the decision is that another init
+system should be solved, I'm probably going to solve it by removing the
+init functionality from the systemd package at which point the bug
+solves itself, AIUI.
+
+If the systemd-shim maintainers want to solve it in the meantime, going
+with Raphael's suggestion seems reasonable enough.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 21:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 21:00:04 GMT) (full text, mbox, link).

+ +

Message #1884 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Mon, 30 Dec 2013 12:56:21 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I think we should give package maintainers some guidance on what kinds
+> of upstart or systemd patches should be accepted.  Without this, it's
+> likely we'll find ourselves adjudicating disputes that ought to have
+> been settled in principle much earlier.
+
+> I think that patches for either should:
+>  - use a non-forking startup method
+>  - avoid significant amounts of open-coded AF_UNIX socketry
+>  - avoid embedded copies of daemon library code
+
+These all seem reasonable to me, with the caveat that if *upstream*
+includes open-coded AF_UNIX socketry or embedded copies of daemon library
+code, I don't see any need for Debian package maintainers to remove that
+code.
+
+>  - avoid extra build-dependencies (eg on libsystemd)
+>  - avoid extra runtime dependencies (eg on deb-systemd-helper)
+
+These requirements, on the other hand, I find completely baffling.
+
+This approach seems completely contrary to Debian best practices.  Our
+standard practice with all packages is to fully enable all available
+features that make sense on Debian and don't pose some concrete risk.
+This means that, for example, I have CUPS libraries on this system despite
+the fact that I never print, Avahi libraries depsite the fact that I will
+never use that software, and SELinux libraries deeply embedded in core
+code despite the fact that few Debian systems currently run SELinux.
+
+These requirements seem like would fit with Gentoo, where much emphasis is
+placed on letting people build custom-crafted binaries to their local
+requirements, not Debian's approach of providing a full-featured and
+uniform distribution.
+
+Needless to say, I don't think we should avoid dependencies on
+libsystemd-daemon or init-system-helpers, and I think it would be wholly
+inappropriate for the Technical Committee to say anything of the sort.
+
+> (If the current state of the art in readiness protocols persists that
+> means that upstart patches using raise(SIGSTOP) ought to be accepted,
+> but systemd ones rejected unless they can use socket activation.)
+
+So, as mentioned above, I don't agree with this, although of course I
+think using socket activation is, in general, better than using the
+readiness protocol.
+
+> We should recommend:
+>  - daemon authors and Debian maintainers should prefer command-line
+>    options to environment variables
+
+I disagree with including this in a statement.  I think it's outside the
+scope of what we were asked to resolve, and I don't think it's the place
+of the TC to offer this sort of general advise to upstreams.
+
+>  - whatever environment variables and fds are used, measures should be
+>    taken to avoid them being inherited by daemons' arbitrary children
+
+I agree with this as good practice for daemons, but again, I don't think
+it's the role of the TC to issue this sort of general advice that is not
+directly related to a question put before us.
+
+If we're going to offer specific advice, we should limit it to the
+specific integrations that we're asked to consider.  But I think we should
+be mindful of the restriction on the TC not doing design work and let
+Policy for packaging support of upstart and/or systemd be hashed out
+through the regular Policy process.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 21:06:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 21:06:07 GMT) (full text, mbox, link).

+ +

Message #1889 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, 726763@bugs.debian.org, 729576@bugs.debian.org, + systemd@packages.debian.org
+
Subject: Re: Bug#727708: systemd-shim uploaded to NEW
+
Date: Mon, 30 Dec 2013 13:03:48 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 30, 2013 at 06:29:10PM +0000, Ian Jackson wrote:
+> Steve Langasek writes ("Bug#727708: systemd-shim uploaded to NEW"):
+> > So I repeat here my request that the systemd maintainers make a suitable
+> > split of the systemd binary package, so that systemd-shim will be
+> > coinstallable with the systemd-provided implementations of the other dbus
+> > services.
+
+> Is there a summary of the systemd maintainers' response to this
+> request ?  I glanced #726763 and #729576 but they were very long and
+> if the answer is in there I probably wouldn't have found it.
+
+The relevant discussion on debian-devel is here:
+
+http://lists.debian.org/msgid-search/20131024012751.GA7604@virgil.dodds.net
+http://lists.debian.org/msgid-search/87bo2fyruk.fsf_-_@qurzaw.varnish-software.com
+
+> >  The only alternative I see is for systemd-shim to declare a
+> > Replaces: against systemd without a Conflicts,
+
+> This would be quite wrong; Replaces is not supposed to be used like
+> that (but you apparently know that).
+
+Yes.  Raphaël rightly points out that dpkg-divert can be used for this; if
+necessary, that's what I'll do.
+
+But I still think the right thing here is for the systemd package to be
+split.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 21:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to cameron <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 21:15:04 GMT) (full text, mbox, link).

+ +

Message #1894 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: cameron <camerontnorman@gmail.com>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Mon, 30 Dec 2013 21:04:50 -0008
+
+
[Message part 1 (text/plain, inline)]
+
+
+On Mon, Dec 30, 2013 at 11:56 AM, Russ Allbery <rra@debian.org> wrote:
+> 
+> The latest that I have seen on this porting effort is here:
+> 
+> http://blog.surgut.co.uk/2013/11/libnih-upstart-dependency-ported-to.html
+> 
+> I asked previously on this bug if someone had later news.  Do you have
+> more information than that?
+> 
+> The above is definitely not "upstart running on BSD."  That's 
+> upstart's
+> underlying support library mostly working on BSD after disabling two
+> features (that are required for upstart).
+> 
+I know inotify is working on kFreeBSD with the libinotify-kqueue 
+software (recently packaged in Debian). 
+https://github.com/dmatveev/libinotify-kqueue
+
+That leaves only abstract domain name sockets left, which should not be 
+too complicated.
+
+Upstart still does not run on kFreeBSD, though.
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 21:39:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 21:39:12 GMT) (full text, mbox, link).

+ +

Message #1899 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion [and 1 more messages]
+
Date: Mon, 30 Dec 2013 22:35:15 +0100
+
+
]] cameron 
+
+> On Mon, Dec 30, 2013 at 9:43 AM, Tollef Fog Heen <tfheen@err.no> wrote:
+> 
+> >>  If this is not required by systemd, why is it done by sd_notify ?
+> >>
+> > It's not.
+> 
+> You obviously did not read the code. It is. Here is a G+ convo with
+> Lennart I had:
+>
+> > As a sender you only have to set SCM_CREDENTIALS manually if you
+> > want to fake it (for which you need privs however).
+> 
+> sd_notify() basically impersonates the process. You only need to set
+> SCM manually if you are writing an external library. If someone is
+> just doing it in the daemon, the kernel will set SCM_CREDENTIALS
+> automatically.
+
+You seem to be confusing systemd-notify(1) with sd_notify(3).
+sd_notify(3) is the library call that's called by the daemon itself.
+systemd-notify(1) is a command line tool to «Notify service manager
+about start-up completion and other daemon status changes».
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 21:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to cameron <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 21:45:04 GMT) (full text, mbox, link).

+ +

Message #1904 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: cameron <camerontnorman@gmail.com>
+
To: Tollef Fog Heen <tfheen@err.no>, 727708@bugs.debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion [and 1 + more messages]
+
Date: Mon, 30 Dec 2013 21:34:19 -0008
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 30, 2013 at 1:35 PM, Tollef Fog Heen <tfheen@err.no> wrote:
+> ]] cameron 
+> 
+>>  On Mon, Dec 30, 2013 at 9:43 AM, Tollef Fog Heen <tfheen@err.no> 
+>> wrote:
+>>  
+>>  >>  If this is not required by systemd, why is it done by sd_notify 
+>> ?
+>>  >>
+>>  > It's not.
+>>  
+>>  You obviously did not read the code. It is. Here is a G+ convo with
+>>  Lennart I had:
+>> 
+>>  > As a sender you only have to set SCM_CREDENTIALS manually if you
+>>  > want to fake it (for which you need privs however).
+>>  
+>>  sd_notify() basically impersonates the process. You only need to set
+>>  SCM manually if you are writing an external library. If someone is
+>>  just doing it in the daemon, the kernel will set SCM_CREDENTIALS
+>>  automatically.
+>> 
+> You seem to be confusing systemd-notify(1) with sd_notify(3).
+> sd_notify(3) is the library call that's called by the daemon itself.
+> systemd-notify(1) is a command line tool to «Notify service manager
+> about start-up completion and other daemon status changes».
+> 
+
+I am not confused, but I am wrong. sd_notify() does not use 
+SCM_CREDENTIALS explicitly (only implicitly via the kernel's 
+autosetting of them).
+
+Sorry for the misrepresentation,
+Cameron Norman
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 21:45:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 21:45:07 GMT) (full text, mbox, link).

+ +

Message #1909 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Mon, 30 Dec 2013 13:44:10 -0800
+
+
This message contains some supplemental information to go with my primary
+writeup, and some profound thanks for the people involved in this
+investigation.
+
+I apologize for the huge volume of mail, and I know it's going to take a
+while to digest.  I appreciate people's willingness to read all these
+messages in detail.  This is a very complex decision-making process.  I'm
+pretty mentally exhausted by the effort of trying to synthesize all these
+pieces, so my apologies in advance for the inevitable errors and omissions
+(some of which affected my original writeup).
+
+
+1. Thanks
+
+Throughout this evaluation process, my interactions with upstart and
+systemd upstream developers and Debian packagers have been uniformly
+excellent.  Bug reports filed against both systemd and upstart have
+received excellent and timely response, and all involved have been quite
+willing to explain things I've misunderstood, correct my false starts, and
+discuss technical and practical aspects of their designs.
+
+I was particularly impressed by the clear effort that the systemd and
+upstart maintainers in Debian have put into fully integrating their init
+systems in such a way that makes them easy to test and use with existing
+Debian packages.  This includes but is not limited to update-rc.d support,
+invoke-rc.d support, status synchronization with sysvinit, past Policy
+discussion, and attention to upgrade paths and init-switching use cases.
+
+I also want to particularly thank the OpenRC upstream development team for
+their involvement in this process and their contributions to the
+discussion.  I personally don't think that package is a god match for
+Debian's needs on Linux, but that's through no fault of the people
+involved, and I think they would be an excellent upstream if that package
+looked like a good fit for the needs of any of Debian's non-Linux ports.
+
+I also want to thank Petter Reinholdtsen, Roger Leigh, and everyone else
+who has worked on the sysvinit package over the years, the insserv
+conversion to dependency-based boot, and the inclusion of LSB support.  If
+it weren't for their hard work over the years, we would be in a far worse
+position than we are today.  It's often hard to see people discussing the
+inadequacies of something into which you put years of hard work.  I want
+to call attention to their long-term contributions to the distribution and
+the number of Debian systems that have booted through their efforts
+through the years.
+
+I am carefully keeping this discussion to the Technical Committee bug
+report so that all of my comments stay in context with their rebuttals,
+but this one section I think is unrelated to the rest of the discussion
+and should be more widely posted, so I will also be posting the above to
+my blog and Planet Debian.
+
+
+2. upstart vs. systemd: The Equivalencies
+
+In doing this evaluation, I looked at quite a few different things.  In a
+great number of cases, I found both upstart and systemd to be at an
+equally high level of quality.  There are too many of those to list here,
+but I wanted to mention a few points that had been the topic of wider
+discussion.
+
+* The documentation of both systems was uniformly excellent.  Both systems
+  had complete reference manuals plus guidance to packagers for how to
+  integrate with them.  systemd also had excellent guidance for upstream
+  developers on how to add systemd support relevant to upstream packages.
+
+* Both packages preserve traditional logging behavior, continue to
+  properly utilize syslog, and retain logs in the places where I expected
+  them.  This is obviously not surprising for upstart, but I wanted to
+  mention it explicitly since those unfamiliar with the systemd journal
+  may be afraid that it would migrate logs into a separate, unexpected
+  store.  This is not the case; systemd logs are available in the normal
+  places and can continue to be managed through syslog configuration.  The
+  journal is supplementary and enables some additional features discussed
+  elsewhere.
+
+* Both packages move to configuration, from code, many of the annoyances
+  and fiddly pieces involved in starting daemons.  Both support
+  non-forking daemon models and proper PID tracking in their own ways.
+  Both directly support such routine needs as setting user and group, OOM
+  score adjustment, resource limits, and so forth.
+
+* Both packages provide MAC integration, which is something that I think
+  will become more important for Debian in the future.  (systemd provides
+  some additional features around Smack, but at least given what I know
+  right now, I don't think this is a significant differentiation.)
+
+There was another point that I am calling equivalent since I didn't
+evaluate it either way.  It's possible that this would convert into an
+advantage for one side or the other after further investigation:
+
+* Both systemd and upstart provide a way to run the system as a user
+  process to manage user jobs in a similar fashion to how they manage
+  system jobs.  I believe this is already used extensively in Ubuntu to
+  manage user desktop sessions.  I don't where the systemd equivalent has
+  been used.
+
+Finally, my interaction with both upstreams has been excellent, as I
+mentioned above in the Thanks section.  I believe both maintenance teams
+would make excellent partners and upstreams for Debian going forward.
+
+
+3. upstart: The Minor Advantages
+
+The following points did not make the cut into my main analysis.  I
+consider them minor advantages that don't carry the same weight as the
+things that I commented on.  However, I did want to mention some that had
+been the topic of discussion.
+
+* The upstart and libnih code bases are beautiful pieces of work.  I was
+  quite impressed by the code quality and documentation level, and more
+  impressed by the extensive test suite.  upstart and libnih follow the
+  gold standard, commonly advocated but rarely met, of having around half
+  of the code in the package be test cases.  These are clearly code bases
+  that have seen a great deal of love, care, and consistent development
+  standards.  The systemd code base also struck me as solid and at the
+  standard that we would expect for a critical package, but the testing
+  model is not as comprehensive or as integrated with the code, and it
+  didn't impress me the same way that the upstart code did.
+
+* Both upstart and systemd are used by other major distribution projects,
+  but upstart is used by Ubuntu, with which Debian has a special
+  relationship.  Debian collaborates more extensively with Ubuntu than
+  with any other project, including largely sharing packaging between the
+  projects and benefiting greatly from each other's testing and
+  integrations.  With upstart, Debian would have the immediate use of many
+  upstart configurations that are either already in the archive or already
+  available in Ubuntu, and which already fit Debian packaging standards
+  and tools.  I consider this a minor advantage for upstart.
+
+* upstart provides a more straightforward escape to shell scripting for
+  some difficult initialization situations, whereas the systemd syntax for
+  doing so is rather awkward.  This cuts both ways, so you'll find that
+  this point makes an appearance in the section below as well.  But I
+  think that, in some situations, this is a readability and ease of
+  integration advantage for upstart.
+
+
+4. systemd: The Minor Advantages
+
+Similarly, during this evaluation, I found several things that I preferred
+in systemd, but which didn't make the significance cut in my final
+evaluation.  Here are some of them for the record.
+
+* systemd does not require a CLA, whereas upstart does.  The Canonical
+  Contributor Licensing Agreement has been much-discussed in these
+  threads, and some people find it quite intrusive and unacceptable.  The
+  upstart package maintainers have committed to carrying non-CLA-covered
+  contributions as local patches, which does a lot to ameliorate this
+  concern, but I still consider this a minor advantage for systemd.
+
+* systemd provides really nice command-line tools for understanding the
+  state of the system and the relationships between the unit files.  I
+  don't believe upstart has an equivalent of systemctl list-dependencies,
+  for example.  (systemctl status got special mention in my main
+  evaluation.)
+
+* Both upstart and systemd, due to their more declarative nature, allow
+  for daemon configurations that are more portable between different
+  systems running the same init system.  systemd has taken this farther
+  into comprehensive and useful advice to upstream daemon authors for how
+  to incorporate systemd support into a package, and also provides
+  step-by-step instructions for how to install systemd unit files during
+  package installation.  While I don't believe that full portability of
+  unit files will be achievable, I still think Debian would benefit from
+  this when integrating systemd, as upstream unit files will often be
+  usable as-is or with some minor patching.
+
+* systemd puts a lot of work into providing all the configuration
+  directives required to express a huge variety of use cases without
+  having to write complex startup commands or escape out to shell.  This
+  is the flipside, in some ways, to upstart's easy escape to shell.  I
+  particularly noted the wide variety of Condition* settings to control
+  whether a unit should start.  This is valuable for distribution
+  packaging cases, but I think it's even more valuable for users of
+  systemd-controlled systems in setting up local overrides and conditions
+  for when they want to run a particular service.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 22:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 22:06:04 GMT) (full text, mbox, link).

+ +

Message #1914 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Mon, 30 Dec 2013 23:01:55 +0100
+
+
]] Russ Allbery 
+
+> Given that, I don't believe a Technical Committee choice of a default init
+> system is going to make either the systemd or the upstart maintainers want
+> to stop maintaining their packages.
+
+Given what you're basically deciding between is «upstart + castrated
+systemd» or «systemd» and I think I've pretty clearly expressed my
+thoughts on splitting up systemd, I don't know where that conclusion
+comes from.  Were you to choose upstart, I'd be seriously thinking about
+stopping maintaining systemd.  (This is meant as a data point, not as a
+threat or anything like that.)  My ideas for the package align pretty
+well with upstream (which I'm a sometimes-active part of) where the
+different services are free to assume that they run with systemd as pid
+1. Continously porting new upstream versions to an environment
+unsupported by upstream is not what I consider reasonable or fun.  I'm
+speaking for myself here, not the other systemd maintainers.
+
+In addition, as per my other message, were you to choose upstart as a
+default, I'd be inclined to remove the init functionality from systemd.
+I think trying to support multiple init systems is crazy and a recipe
+for disaster and I don't want to do that.  (Doing it as part of a
+transition is a necessary pain, that much I can agree with, but ongoing?
+No thanks.)
+
+> 6. Debian's non-Linux ports should either use the same init system as
+>    Debian's Linux ports or agree on an init system that they're both going
+>    to use.  The porting work is going to be hard enough without the ports
+>    going in different directions on which secondary init system they want
+>    to use.  I prefer to leave it up to the porters to decide which init
+>    system to choose, but I do think OpenRC would be a strong contender.
+
+I think allowing them to use a compatible init system should be ok too,
+if somebody wants to do that.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 22:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 22:33:04 GMT) (full text, mbox, link).

+ +

Message #1919 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Mon, 30 Dec 2013 17:31:12 -0500
+
+
On Mon, Dec 30, 2013 at 1:47 PM, Russ Allbery wrote:
+>
+> 4. Conclusions
+>
+> I previously argued that much of the benefit of a new init system comes
+> from when we can stop maintaining init scripts.  I still believe that, but
+> after thinking more about the cultural and project issues at stake here,
+> as well as the immediate needs for a clean upgrade path, I ended up at
+> more of a compromise position than I expected.
+>
+> I believe Debian should take this path forward:
+>
+> 1. We should select a new init system for jessie, either systemd or
+>    upstart.  Support for that init system should be release-critical, but
+>    only in the sense that the daemon works properly under that init
+>    system.  In other words, use of the sysvinit compatibility of either
+>    init system is acceptable support for jessie.
+>
+> 2. All packages providing init scripts must continue to support sysvinit
+>    scripts through the jessie release.  Such support will continue to be
+>    release-critical.  This is going to be painful for packages that want
+>    to do an early conversion, since it means testing two different init
+>    systems for this release cycle, but I think this is the right thing to
+>    do regardless for a clean upgrade path and Debian's normal robust
+>    committment to upgrades.  Here it has the additional advantage of
+>    giving the non-Linux ports some breathing space to strategize.
+>
+> 3. Related, up through the jessie release, packages must (where possible;
+>    it's possible there will be cases where this is simply impossible)
+>    support switching back and forth between the new default init system
+>    and sysvinit.  This means that configurations should not be moved out
+>    of /etc/default and that startup files for the new init system should
+>    read the same configuration that the existing sysvinit scripts use (or
+>    both should be modified compatibly).
+>
+> 4. Post-jessie, support for sysvinit will no longer be release-critical,
+>    and package maintainers will no longer be expected to ensure that it
+>    continues working.  However, for as long as Debian has accepted
+>    non-Linux ports using a different init system, package maintainers
+>    should continue to ship init scripts if they work and should apply
+>    patches and other reasonable fixes from porters for those init scripts.
+>    In other words, this should be treated the same as merging patches for
+>    the Hurd to remove hard-coded constant assumptions: if the change is
+>    reasonable and doesn't break Linux ports (and this should be fairly
+>    easy to handle for nearly all cases with init scripts), the package
+>    maintainer should merge it.
+>
+> 5. Support for the other init system that was not chosen should be handled
+>    in the same fashion, should a team choose to pursue it.  If we select
+>    systemd, package maintainers should still be willing to merge
+>    contributed upstart configuration, with the understanding that they
+>    can't test it and any support is on a best-effort basis only.
+>    Similarly, if we select upstart, package maintainers should be willing
+>    to merge systemd unit files and to enable upstream systemd support
+>    where requested and where it doesn't interfere with the operation of
+>    the daemon under upstart, with the understanding that the package
+>    maintainer is not committing to testing or directly supporting this
+>    configuration.
+>
+> 6. Debian's non-Linux ports should either use the same init system as
+>    Debian's Linux ports or agree on an init system that they're both going
+>    to use.  The porting work is going to be hard enough without the ports
+>    going in different directions on which secondary init system they want
+>    to use.  I prefer to leave it up to the porters to decide which init
+>    system to choose, but I do think OpenRC would be a strong contender.
+>
+> 7. After jessie, functionality between systems running the primary Linux
+>    init system and other init systems (including non-Linux ports) should
+>    be allowed to drift.  In other words, there will be cases where
+>    features will only be available with the primary init system.  Possible
+>    examples include security hardening, socket activation, automatic
+>    daemon restarts, and so forth.  Packagers are under no obligation to
+>    port those features to other init systems, but should welcome and merge
+>    patches that do so.  After jessie, packagers will no longer be required
+>    to preserve daemon configuration when the init system is switched, so
+>    use of such facilities as modification of upstart configuration files
+>    or systemd overrides may be used.
+>
+> We should revisit this decision again after the jessie release in case the
+> situation has substantially changed.
+
+Doesn't a TC mandate on the default init system in some sense violate
+Debian's spirit of meritocracy?  May I suggest something like the
+following (this isn't meant to be definitive) as a more meritocratic
+approach:
+
+1. The TC encourages a team (probably debian-boot) to provide a
+package (similar to tasksel), let's call it initsel, that prompts
+users during an expert install (and dpkg-reconfigure) time to make an
+init system selection (with sysvinit as the default to begin with)
+
+2. The TC recommends approving jessie release goals to support all of
+the viable init systems (concurrently maintaining full support for
+sysvinit).
+
+3. The TC recommends that initsel support selection among any of the
+init systems that are sufficiently capable on the user's current
+architecture.
+
+4. When the init systems sufficiently support all of the planned
+release architectures, which would include kfreebsd-* (at least for
+now) and possible hurd if it does become an officially supported arch,
+the TC recommends that the team supporting initsel evaluate changing
+the default to their best choice among all of those init systems that
+do support all of the release architectures.
+
+5. At some future point deprecate sysvinit and any of the other init
+systems that are clearly not worth continuing, and encourage
+maintainers to remove support for those.
+
+Doing something like this, the best init system can win based truly on
+merit (if/when the work gets done), rather than as a fuzzy upfront
+judgement call.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 22:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 22:39:04 GMT) (full text, mbox, link).

+ +

Message #1924 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Mon, 30 Dec 2013 14:36:55 -0800
+
+
Tollef Fog Heen <tfheen@err.no> writes:
+> ]] Russ Allbery 
+
+>> Given that, I don't believe a Technical Committee choice of a default
+>> init system is going to make either the systemd or the upstart
+>> maintainers want to stop maintaining their packages.
+
+> Given what you're basically deciding between is «upstart + castrated
+> systemd» or «systemd» and I think I've pretty clearly expressed my
+> thoughts on splitting up systemd, I don't know where that conclusion
+> comes from.
+
+I have to admit that I didn't give it a whole lot of thought.  It was an
+assumption based on the presence of both in the archive for some time now
+as non-default init systems under sysvinit.  In that sense, things don't
+change that horribly much, at least up to the jessie release, if the
+default changes from one non-systemd thing to another non-systemd thing.
+
+That being said, obviously you should speak for yourself, and I stand
+corrected.  Apologies for misprepresenting your feelings here.
+
+>> 6. Debian's non-Linux ports should either use the same init system as
+>>    Debian's Linux ports or agree on an init system that they're both going
+>>    to use.  The porting work is going to be hard enough without the ports
+>>    going in different directions on which secondary init system they want
+>>    to use.  I prefer to leave it up to the porters to decide which init
+>>    system to choose, but I do think OpenRC would be a strong contender.
+
+> I think allowing them to use a compatible init system should be ok too,
+> if somebody wants to do that.
+
+Oh, yes, good point.  I was thinking more in terms of two different init
+systems with different preferred configuration files.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 22:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 22:54:04 GMT) (full text, mbox, link).

+ +

Message #1929 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Michael Gilbert <mgilbert@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Mon, 30 Dec 2013 14:51:47 -0800
+
+
Michael Gilbert <mgilbert@debian.org> writes:
+
+> Doesn't a TC mandate on the default init system in some sense violate
+> Debian's spirit of meritocracy?
+
+I believe that we have enough information to make an informed choice
+already, and that the sides are fairly well-defined and hardened in their
+opinions.  That means that this dispute falls under section 6.1.2 of the
+constitution:
+
+    Decide any technical matter where Developers' jurisdictions overlap.
+
+    In cases where Developers need to implement compatible technical
+    policies or stances (for example, if they disagree about the
+    priorities of conflicting packages, or about ownership of a command
+    name, or about which package is responsible for a bug that both
+    maintainers agree is a bug, or about who should be the maintainer for
+    a package) the technical committee may decide the matter.
+
+Regardless of how we structure the installer, we need to have a default
+init system (unless we plan on making every user choose, which I would
+dismiss out of hand as a horrible UI experience for the average user, who
+really doesn't care).  We have to mandate support for at least that
+default init system.  Realistically, the ability of the Debian developer
+community to support more than one init system is limited, since any given
+system is generally only going to run one.  That means the level of
+quality of integration is going to drop off significantly relative to the
+default init system, particularly over time.
+
+Init systems are not like desktop environments: they require work by a
+huge swath of the developer community, and the average user does not
+generally switch from one to the other.  The reality is that either
+systemd or upstart is fully capable of everything the typical user is
+going to need (for that matter, sysvinit is capable of most of what the
+typical user needs); there isn't the same driving force of user preference
+that leads users to switch between desktop environments, and quite a bit
+more integration support is required for the init system.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 23:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to intrigeri <intrigeri@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 23:03:04 GMT) (full text, mbox, link).

+ +

Message #1934 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: intrigeri <intrigeri@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 00:00:25 +0100
+
+
Hi,
+
+(Sorry if I am duplicating a point that was already made.
+These threads are huge, and don't fit entirely into my memory.)
+
+Ian Jackson wrote (30 Dec 2013 18:58:37 GMT) :
+> Russ Allbery writes ("Bug#727708: init system other points, and conclusion"):
+>> Rather, we're talking about whether or not to swap out a core component of
+>> an existing integrated ecosystem with a component that we like better.
+
+> Unless you are proposing to make systemd mandatory for all Debian
+> installations, this is work that needs to be done anyway.
+
+"Needs to be done anyway", possibly, but I find it important to make
+it clear that, depending on what decision is made, it affects the
+project as a whole, and many of its members, in very different ways:
+
+* In one case (upstart is chosen as the default init system), we, as
+  a project, are committed to do this work, at the very least because
+  Policy mandates it, and we want to release without too many
+  RC-buggy packages.
+
+  Some maintainers happily do it because they are glad that upstart
+  was picked, some do it reluctantly as they would have preferred
+  systemd and they feel this all is unnecessary work put on our
+  collective shoulders, some would have preferred systemd but console
+  themselves because it feels so good to move away from sysvinit
+  eventually, etc.
+
+  Regardless of what our personal preference is, we have to do this
+  work, because else it's a RC bug and we can't release.
+
+* In the other case (systemd is chosen as the default init system),
+  any individual or self-organized team may tackle this work, if their
+  desires or needs make them feel committed to provide choice and
+  flexibility, for the init component and potentially the kernel too,
+  to Debian users.
+
+  I believe this effort is similar in many ways to porting, and as
+  such I trust it will be treated with "deference and reasonable
+  accommodation" (thanks, Russ) in our community.
+
+The difference lies in who are the people who "need" to do this work
+"anyway", and who else may instead dedicate their time to other tasks,
+lead by their own desires and needs.
+
+[Now moving away from my clarification point, and largely off-topic.
+Feel free to ignore.]
+
+This specific part of the broader init system discussion boils down to
+"what are our collective goals and priorities?", or "what do we find
+important enough to put much energy into?". We are currently not that
+good at finding exciting collective answers to this, and even at
+finding good ways to make such decisions.
+
+I mean: if it were just me, my proposal would be "let's make Debian
+better empower its users to protect their privacy in the post-Snowden
+world", and to me it feels way more exciting and relevant a thing we
+could do for our users and Free Software than "let's allow Debian
+users to replace systemd's init component with something else".
+How far off-topic my answer is shows, I believe, how hard it is to
+focus on the mere technical decision that presently needs to be made
+(and rightfully was sent to the TC), given how broad its non-technical
+implications could be not only on the Debian project, Debian users,
+Debian derivatives and Free Software, but on the world at large.
+
+End of the digression explaining how hard it is not to digress.
+
+Cheers,
+-- 
+  intrigeri
+  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
+  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 23:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cory <opensourcesoftwaredeveloper@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 23:15:05 GMT) (full text, mbox, link).

+ +

Message #1939 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cory <opensourcesoftwaredeveloper@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: loose ends for init system decision
+
Date: Mon, 30 Dec 2013 17:11:25 -0600
+
+
On 12/30/2013 04:31 PM, Michael Gilbert wrote:
+> On Mon, Dec 30, 2013 at 1:47 PM, Russ Allbery wrote:
+>> 4. Conclusions
+>>
+>> I previously argued that much of the benefit of a new init system comes
+>> from when we can stop maintaining init scripts.  I still believe that, but
+>> after thinking more about the cultural and project issues at stake here,
+>> as well as the immediate needs for a clean upgrade path, I ended up at
+>> more of a compromise position than I expected.
+>>
+>> I believe Debian should take this path forward:
+>>
+>> 1. We should select a new init system for jessie, either systemd or
+>>     upstart.  Support for that init system should be release-critical, but
+>>     only in the sense that the daemon works properly under that init
+>>     system.  In other words, use of the sysvinit compatibility of either
+>>     init system is acceptable support for jessie.
+>>
+>> 2. All packages providing init scripts must continue to support sysvinit
+>>     scripts through the jessie release.  Such support will continue to be
+>>     release-critical.  This is going to be painful for packages that want
+>>     to do an early conversion, since it means testing two different init
+>>     systems for this release cycle, but I think this is the right thing to
+>>     do regardless for a clean upgrade path and Debian's normal robust
+>>     committment to upgrades.  Here it has the additional advantage of
+>>     giving the non-Linux ports some breathing space to strategize.
+>>
+>> 3. Related, up through the jessie release, packages must (where possible;
+>>     it's possible there will be cases where this is simply impossible)
+>>     support switching back and forth between the new default init system
+>>     and sysvinit.  This means that configurations should not be moved out
+>>     of /etc/default and that startup files for the new init system should
+>>     read the same configuration that the existing sysvinit scripts use (or
+>>     both should be modified compatibly).
+>>
+>> 4. Post-jessie, support for sysvinit will no longer be release-critical,
+>>     and package maintainers will no longer be expected to ensure that it
+>>     continues working.  However, for as long as Debian has accepted
+>>     non-Linux ports using a different init system, package maintainers
+>>     should continue to ship init scripts if they work and should apply
+>>     patches and other reasonable fixes from porters for those init scripts.
+>>     In other words, this should be treated the same as merging patches for
+>>     the Hurd to remove hard-coded constant assumptions: if the change is
+>>     reasonable and doesn't break Linux ports (and this should be fairly
+>>     easy to handle for nearly all cases with init scripts), the package
+>>     maintainer should merge it.
+>>
+>> 5. Support for the other init system that was not chosen should be handled
+>>     in the same fashion, should a team choose to pursue it.  If we select
+>>     systemd, package maintainers should still be willing to merge
+>>     contributed upstart configuration, with the understanding that they
+>>     can't test it and any support is on a best-effort basis only.
+>>     Similarly, if we select upstart, package maintainers should be willing
+>>     to merge systemd unit files and to enable upstream systemd support
+>>     where requested and where it doesn't interfere with the operation of
+>>     the daemon under upstart, with the understanding that the package
+>>     maintainer is not committing to testing or directly supporting this
+>>     configuration.
+>>
+>> 6. Debian's non-Linux ports should either use the same init system as
+>>     Debian's Linux ports or agree on an init system that they're both going
+>>     to use.  The porting work is going to be hard enough without the ports
+>>     going in different directions on which secondary init system they want
+>>     to use.  I prefer to leave it up to the porters to decide which init
+>>     system to choose, but I do think OpenRC would be a strong contender.
+>>
+>> 7. After jessie, functionality between systems running the primary Linux
+>>     init system and other init systems (including non-Linux ports) should
+>>     be allowed to drift.  In other words, there will be cases where
+>>     features will only be available with the primary init system.  Possible
+>>     examples include security hardening, socket activation, automatic
+>>     daemon restarts, and so forth.  Packagers are under no obligation to
+>>     port those features to other init systems, but should welcome and merge
+>>     patches that do so.  After jessie, packagers will no longer be required
+>>     to preserve daemon configuration when the init system is switched, so
+>>     use of such facilities as modification of upstart configuration files
+>>     or systemd overrides may be used.
+>>
+>> We should revisit this decision again after the jessie release in case the
+>> situation has substantially changed.
+> Doesn't a TC mandate on the default init system in some sense violate
+> Debian's spirit of meritocracy?  May I suggest something like the
+> following (this isn't meant to be definitive) as a more meritocratic
+> approach:
+>
+> 1. The TC encourages a team (probably debian-boot) to provide a
+> package (similar to tasksel), let's call it initsel, that prompts
+> users during an expert install (and dpkg-reconfigure) time to make an
+> init system selection (with sysvinit as the default to begin with)
+>
+> 2. The TC recommends approving jessie release goals to support all of
+> the viable init systems (concurrently maintaining full support for
+> sysvinit).
+>
+> 3. The TC recommends that initsel support selection among any of the
+> init systems that are sufficiently capable on the user's current
+> architecture.
+>
+> 4. When the init systems sufficiently support all of the planned
+> release architectures, which would include kfreebsd-* (at least for
+> now) and possible hurd if it does become an officially supported arch,
+> the TC recommends that the team supporting initsel evaluate changing
+> the default to their best choice among all of those init systems that
+> do support all of the release architectures.
+>
+> 5. At some future point deprecate sysvinit and any of the other init
+> systems that are clearly not worth continuing, and encourage
+> maintainers to remove support for those.
+>
+> Doing something like this, the best init system can win based truly on
+> merit (if/when the work gets done), rather than as a fuzzy upfront
+> judgement call.
+>
+> Best wishes,
+> Mike
+>
+>
+1
+i really don't see any "point" at all of talking about debian BSD init 
+systems they're porting there own it's called open-launchd
+
+https://github.com/rtyler/openlaunchd
+
+2
+having used Upstart OpenRC and systemd and i can tell you systemd works 
+the best out of the 3
+
+3
+if debian does go with Upstart will this let all of debians down streams 
+replace Upstart with systemd as most of debian's down streams who don't 
+use the default inti system use systemd if not all of them
+
+4
+now talking about down streams even SteamOS looks to use systemd
+http://repo.steampowered.com/steamos/pool/main/s/systemd/
+
+5
+3 DE's use logind Gnome, KDE, MATE,
+
+6
+consolekit is dead logind is way better
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 23:33:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 23:33:09 GMT) (full text, mbox, link).

+ +

Message #1944 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Mon, 30 Dec 2013 15:30:51 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 30, 2013 at 11:56:33AM -0800, Russ Allbery wrote:
+> >> Rather, we're talking about whether or not to swap out a core component
+> >> of an existing integrated ecosystem with a component that we like
+> >> better.
+
+> > Unless you are proposing to make systemd mandatory for all Debian
+> > installations, this is work that needs to be done anyway.
+
+> What I'm hearing from both GNOME and KDE maintainers is that assuming
+> systemd would save them a great deal of work.  I think having systemd be
+> the only supported and tested option for at least some large package sets
+> that heavily use the systemd infrastructure upstream is a not-unlikely
+> long-term outcome.
+
+It's clear that being able to assume availability of certain dbus services
+is labor-saving for GNOME and KDE upstreams, and I see no reason for them
+not to standardize on such a requirement assuming the dbus services have
+sane APIs (which they do).
+
+What I object to is referring to this as "assuming systemd".  They are
+systemd APIs, sure, but with one exception the systemd implementations are
+not presently tied to the use of systemd as init, and there is an alternate
+implementation of that one exception (systemd-shim).
+
+From comments made by various GNOME upstream developers on this, I think
+they are being suitably cautious about avoiding scope creep where the
+systemd dependencies are concerned.  So in what sense are the GNOME and KDE
+requirements not already being met on top of upstart?  The only outstanding
+issue I see is with non-Linux ports, because logind is not portable; that's
+definitely a problem for running GNOME on kfreebsd, but it's actually a
+rather narrowly-scoped porting problem and one that the ports need to deal
+with one way or another if they want GNOME to continue working.
+
+I'm sure there are GNOME upstream contributors who would be happy to see
+GNOME become systemd-only.  But I think their motivations in letting the
+lines be blurred in such a way are purely political, not technical; and I
+give GNOME upstream as a whole the benefit of the doubt that they would not
+so weaken their project to suit someone's political agenda.
+
+> One can, of course, have a wide variety of reactions to that.  As someone
+> who considers portability to be an inherent good, I find it sad, although
+> I don't have a full appreciation for what problems GNOME is trying to
+> solve by increasing its reliance on systemd.  But I'm highly dubious that
+> Debian will just single-handedly fix that, or that we would drop GNOME
+> because we don't like upstream's integration decisions.
+
+I find the notion that Debian doing this "single-handedly" is an obstacle to
+be a bizarre one.  Debian has more than one pair of hands, it's a veritable
+multi-tentacled beast.  Have we so atrophied as a community that we'll wail
+and gnash our teeth about a non-portable dependency, but have no porters
+willing to actually provide a native implementation of a (quite small) dbus
+API?
+
+You've said that you think the portability question doesn't weight strongly
+in favor of either upstart or systemd, because neither port is done yet. 
+But the amount of work that would be involved in porting systemd to kfreebsd
+is an order of magnitude greater than the work involved in porting upstart. 
+logind is just one small component of systemd, which someone could provide
+an API-compatible implementation for without having to contend with the
+question of cgroups on non-Linux kernels.  If even that is out of reach for
+the Debian porters, how could we ever expect a full BSD port of systemd to
+materialize?
+
+I think the reality is that adopting systemd as default init for Debian is
+nothing short of a death sentence for the non-Linux ports.  The move to a
+different init will have a snowball effect in the distribution, as packages
+stop being tested with sysvinit and popular support grows for dropping
+compatibility with sysvinit altogether.  This is not a problem if the ports
+are in a position to come along on this transition with a moderate
+investment in porting init.  But the porting required for systemd as a whole
+is far from moderate, and I believe that faced with such a requirement the
+non-Linux ports would wither and die.  I know there are Debian developers
+(including many in the GNOME/systemd "camp") who think this is a desirable
+outcome.  I have no personal attachment to the non-Linux ports, but I do
+think that as an existing part of our Debian community, the TC should at
+least give these ports a fighting chance, because this kind of competition
+is healthy.
+
+> > My understanding was that Dimitri had got upstart running on BSD.
+
+> The latest that I have seen on this porting effort is here:
+
+> http://blog.surgut.co.uk/2013/11/libnih-upstart-dependency-ported-to.html
+
+> I asked previously on this bug if someone had later news.  Do you have
+> more information than that?
+
+> The above is definitely not "upstart running on BSD."  That's upstart's
+> underlying support library mostly working on BSD after disabling two
+> features (that are required for upstart).  I haven't not heard whether the
+> porting of upstart proper has started.  That will certainly be much easier
+> once libnih is ported, but there are, for example, direct uses of epoll in
+> upstart proper.  (I don't know if kFreeBSD already has a portability layer
+> for epoll in terms of kqueue.)
+
+AIUI, upstart itself built out of the box once libnih was available, because
+all the portability issues are encapsulated in libnih.  (The single use of
+epoll in the upstart source is in the upstart-socket-bridge, which is an
+optional component from upstart's perspective and certainly not needed for
+booting a Debian base system - so presumably Dimitri just built with this
+bridge disabled.)
+
+With libinotify-kqueue (that Dimitri maintains), kfreebsd 10 (in
+experimental), eglibc 2.18 (also in experimental), and Dimitri's branch of
+libnih, it seems that all the portability requirements for upstart are met,
+except for abstract socket support.  There are evidently still some porting
+problems that aren't detected at build time, because upstart doesn't yet
+boot on kfreebsd.  But all things considered, the port is rather far along.
+
+> upstart is a great project, of which its maintainers are deservedly proud.
+> However, I don't agree that it's better than systemd.  My own research
+> convinced me of the opposite.  But putting that aside, my point in that
+> section is that, given feature parity (and I mean "feature" expansively,
+> including adaptibility to Debian's needs), we should choose systemd
+> because it has more project momentum and better existing integration,
+> which means that we will have to spend less energy on it and will have
+> more energy to spend on other things.
+
+> It's absolutely worth doing our own, better things.  What I don't want to
+> do is our own *worse* things.  Or, for that matter, our own equivalent
+> things, when we could instead use work that already exists.  It's a waste
+> of energy.
+
+I think this downplays the significance of the integration work that has
+already been done in Ubuntu on top of upstart, that Debian will be able to
+adopt as-is (or with whatever bugfixes the maintainers find along the way). 
+My look at Fedora 20 confirmed my belief that the integration necessary to
+have a robust systemd boot across all the configurations that Debian
+supports has not actually been done yet.  systemd upstream advocates
+shipping systemd units upstream where they can be consumed unmodified by
+distributions, but in practice Debian is going to be on the hook for
+debugging the very long tail of integration problems.  It's hard to gauge
+whether the energy saved by not bringing upstart up to feature parity
+outweighs the energy spent on bringing systemd integration up to snuff, but
+I definitely don't think there's a clear point here in systemd's favor.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 23:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 23:45:04 GMT) (full text, mbox, link).

+ +

Message #1949 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Mon, 30 Dec 2013 15:42:47 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 30, 2013 at 01:44:10PM -0800, Russ Allbery wrote:
+> * systemd provides really nice command-line tools for understanding the
+>   state of the system and the relationships between the unit files.  I
+>   don't believe upstart has an equivalent of systemctl list-dependencies,
+>   for example.
+
+I think the relevant tools on the upstart side are 'initctl show-config -e'
+and 'initctl2dot'.  This doesn't render in a tree format the way 'systemctl
+list-dependencies' does, because job relationships are a DAG, not a tree;
+but I can see there being room for a simplified view of jobs that works from
+a terminal.
+
+Cheers,
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 23:48:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 23:48:10 GMT) (full text, mbox, link).

+ +

Message #1954 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 01:44:49 +0200
+
+
On Mon, 2013-12-30 at 18:58 +0000, Ian Jackson wrote:
+> Also, I get the impression me that the "integration" of much of this
+> functionality into the systemd source package has been done for
+> political rather than technical reasons.  Indeed to the extent that
+> there is a problematically tight technical coupling between these
+> components, I find it difficult to avoid doubting the good faith of
+> the people making those decisions.  At the very least, I worry that
+> the systemd project as a whole is far too willing to impose decisions
+> of all kinds on its downstreams.
+
+Your own expressed preference for upstart appeared to be very much
+driven by political rather than technical considerations. Using the same
+terminology you do, would it not be entirely fair to say that your
+decision to support upstart was made in bad faith?
+
+
+> > 3.3. Project Momentum
+> 
+> I don't see the outlook here the same way as you do.
+> 
+> Furthermore, I am much less worried about Debian going it alone
+> (although, of course, it's not alone) than you seem to be.  We have
+> historically been entirely unafraid to do our own better things, even
+> if it is more work and takes us longer.
+> 
+> I felt that way when Debian was very much a minority interest.  That's
+> far from the case nowadays; I've heard it asserted that Debian-based
+> distros now account for a majority of traditional distro installs.  I
+> guess numbers on that are all speculative but it is certainly true
+> that we have a thriving ecosystem of our own.
+> 
+> We have got where we are by doing things the way we think is best, not
+> by simply following the herd.
+
+Who would actually do the work? Getting the amount of development there
+is for systemd is not easy. Do you really believe that a Debian decision
+in favor of upstart would create that many interested developers working
+on it, when that has not happened while it's been used in Ubuntu?
+
+Working on things that they believe to be better than existing ones does
+motivate people. But how many Debian developers actually share your
+extreme views about portability to the extent that they would be happy
+to work on another system motivated by that, when systemd already works
+better on Linux? I doubt that group is large enough to create
+significant momentum.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 30 Dec 2013 23:48:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 30 Dec 2013 23:48:19 GMT) (full text, mbox, link).

+ +

Message #1959 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, 726763@bugs.debian.org, 729576@bugs.debian.org, + systemd@packages.debian.org, Tollef Fog Heen <tfheen@err.no>
+
Subject: Re: Bug#727708: systemd-shim uploaded to NEW
+
Date: Mon, 30 Dec 2013 15:46:51 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 30, 2013 at 01:03:48PM -0800, Steve Langasek wrote:
+> > This would be quite wrong; Replaces is not supposed to be used like
+> > that (but you apparently know that).
+
+> Yes.  Raphaël rightly points out that dpkg-divert can be used for this; if
+> necessary, that's what I'll do.
+
+> But I still think the right thing here is for the systemd package to be
+> split.
+
+Looking more closely, I find that one of the conflicting files is a conffile
+(/etc/dbus-1/system.d/org.freedesktop.systemd1.conf).  diversions and
+conffiles still don't mix, AFAIK (and according to current policy).  So that
+seems to still leave us without a proper solution that doesn't involve
+splitting the systemd binary package.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 00:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 00:06:04 GMT) (full text, mbox, link).

+ +

Message #1964 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Mon, 30 Dec 2013 16:04:05 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> From comments made by various GNOME upstream developers on this, I think
+> they are being suitably cautious about avoiding scope creep where the
+> systemd dependencies are concerned.  So in what sense are the GNOME and
+> KDE requirements not already being met on top of upstart?  The only
+> outstanding issue I see is with non-Linux ports, because logind is not
+> portable; that's definitely a problem for running GNOME on kfreebsd, but
+> it's actually a rather narrowly-scoped porting problem and one that the
+> ports need to deal with one way or another if they want GNOME to
+> continue working.
+
+I don't see what you're saying here as substantively different than what I
+said in my writeup about the ecosystem.  I feel like we're both presenting
+the same facts through different lenses.
+
+> On Mon, Dec 30, 2013 at 11:56:33AM -0800, Russ Allbery wrote:
+
+>> One can, of course, have a wide variety of reactions to that.  As
+>> someone who considers portability to be an inherent good, I find it
+>> sad, although I don't have a full appreciation for what problems GNOME
+>> is trying to solve by increasing its reliance on systemd.  But I'm
+>> highly dubious that Debian will just single-handedly fix that, or that
+>> we would drop GNOME because we don't like upstream's integration
+>> decisions.
+
+> I find the notion that Debian doing this "single-handedly" is an
+> obstacle to be a bizarre one.  Debian has more than one pair of hands,
+> it's a veritable multi-tentacled beast.  Have we so atrophied as a
+> community that we'll wail and gnash our teeth about a non-portable
+> dependency, but have no porters willing to actually provide a native
+> implementation of a (quite small) dbus API?
+
+Please recall the context here: this whole aside started with an objection
+to my contention that adopting upstart requires disassembly and redoing of
+an integration that we would otherwise not have to disassemble.  Nowhere
+in my message did I say that we would or could not do that disassembly if
+we adopted upstart; I said that it was work that we otherwise wouldn't
+have to do.
+
+That's the intended context of my point above: I don't think we're going
+to port GNOME to a non-systemd infrastructure, in the sense of carrying
+significant patches to GNOME to adopt it to, say, not using logind.  I
+think GNOME will continue to use systemd APIs heavily, which makes GNOME
+less portable.  That means that systems that are not capable of running
+those systemd components will need to either port them or develop
+alternatives.
+
+I don't consider this wailing or gnashing of teeth, but rather a realistic
+look at what efforts the project is talking about committing to, as
+opposed to supporting people working on if they so choose.
+
+> You've said that you think the portability question doesn't weight
+> strongly in favor of either upstart or systemd, because neither port is
+> done yet.  But the amount of work that would be involved in porting
+> systemd to kfreebsd is an order of magnitude greater than the work
+> involved in porting upstart.
+
+I haven't investigated this myself, but that matches the impressions I've
+gotten from discussion both here and in Lennart's blog.  Nothing I'm
+writing here is intended as disagreement with this point.  Porting systemd
+looks harder.
+
+> logind is just one small component of systemd, which someone could
+> provide an API-compatible implementation for without having to contend
+> with the question of cgroups on non-Linux kernels.
+
+Yes, as I said explicitly in my writeup, it may well be the case that
+porting some of the components of systemd will be substantially easier
+than porting the init system.
+
+> If even that is out of reach for the Debian porters, how could we ever
+> expect a full BSD port of systemd to materialize?
+
+I never said that a port of logind was out of reach for Debian porters.
+I'm saying that there's a lot of work here, and we don't yet know whether
+or how any of it is going to happen.  We should not close off possible
+future directions unnecesarily, but we need to make a decision based on
+the current state without assuming that roadmaps will necessarily come to
+fruition.
+
+*If* Debian adopts systemd as an init system, I do think that it's
+possible (how likely, I don't know) we'll end up with GNOME unavailable on
+the kFreeBSD port because people choose not to do the effort of separating
+out and porting the components required.  It's up to the porters, and
+depends on what role they see for the port.  If, for example, they're
+primarily targeting servers, this may not be a significant loss.  The
+point is that it would be their call.
+
+If Debian adopts upstart, obviously we're going to be required to do the
+work of separating the init system from the rest of systemd, which will
+make some of that effort possibly easier for the kFreeBSD porters
+(although that work will not magically port logind to kFreeBSD, or adjust
+for any future requirements for D-Bus that might materialize, etc.).
+
+Either way, real effort will be required to get GNOME working on
+kFreeBSD.  I'm not saying that effort won't happen.  I'm saying that we
+have choices about what effort we're going to *commit* to, as opposed to
+leaving to the discretion of the porters, and that I am dubious of this
+argument that going with upstart as the init system makes that work
+substantially easier.
+
+> I think the reality is that adopting systemd as default init for Debian
+> is nothing short of a death sentence for the non-Linux ports.  The move
+> to a different init will have a snowball effect in the distribution, as
+> packages stop being tested with sysvinit and popular support grows for
+> dropping compatibility with sysvinit altogether.  This is not a problem
+> if the ports are in a position to come along on this transition with a
+> moderate investment in porting init.  But the porting required for
+> systemd as a whole is far from moderate, and I believe that faced with
+> such a requirement the non-Linux ports would wither and die.
+
+This is definitely something that might happen.  It's a risk of the
+approach that I outline.  I'm less pessmistic than you are about it, but
+this is definitely a risk.
+
+My belief, and again I welcome concrete reasons why I'm not correct, is
+that adopting upstart poses a similar risk for the Hurd port as adopting
+systemd, and I care just as much about the Hurd port as kFreeBSD.  And
+while kFreeBSD is in better shape due to the already-begun upstart port,
+there are still significant porting challenges in the way of maintaining
+feature parity in the kFreeBSD port at the level that it has today.  Many
+of those challenges are going to remain regardless of which init system we
+pick.
+
+> I have no personal attachment to the non-Linux ports, but I do think
+> that as an existing part of our Debian community, the TC should at least
+> give these ports a fighting chance, because this kind of competition is
+> healthy.
+
+Well, I won't get into how much I loathe the word competition in this
+context, but as you can see from my other message this morning, I'm in
+wholehearted agreement with giving the ports a fighting chance.
+
+> AIUI, upstart itself built out of the box once libnih was available,
+> because all the portability issues are encapsulated in libnih.  (The
+> single use of epoll in the upstart source is in the
+> upstart-socket-bridge, which is an optional component from upstart's
+> perspective and certainly not needed for booting a Debian base system -
+> so presumably Dimitri just built with this bridge disabled.)
+
+> With libinotify-kqueue (that Dimitri maintains), kfreebsd 10 (in
+> experimental), eglibc 2.18 (also in experimental), and Dimitri's branch
+> of libnih, it seems that all the portability requirements for upstart
+> are met, except for abstract socket support.  There are evidently still
+> some porting problems that aren't detected at build time, because
+> upstart doesn't yet boot on kfreebsd.  But all things considered, the
+> port is rather far along.
+
+Thank you for the update!  It sounds like it's farther along than the
+previous information I had, although not as far along as Ian had thought.
+
+I want to mention again something that you'd dismissed as possibly a joke
+earlier, but which I was actually serious about: I think a world in which
+we use systemd on Linux and upstart on non-Linux ports, should upstart
+prove much more portable, actually makes sense.  As I said in my other
+writeup, I believe the systemd feature advantage is sufficient to choose
+systemd in isolation, without the other issues discussed.  I also believe
+that maintaining a systemd unit plus an upstart configuration is, modulo
+testing (which I realize is a huge issue), much easier than maintaining a
+single sysvinit script.
+
+I do want to reiterate here, though, that my position on transitions,
+multiple init system support, and so forth are exactly the same if upstart
+works on kFreeBSD but not on Hurd as if it works on both of them.  I
+consider them to have equal place here.  (However, demonstrated
+portability to kFreeBSD may -- to what extent I don't know -- indicate
+that the port to Hurd will be relatively easy.)
+
+> I think this downplays the significance of the integration work that has
+> already been done in Ubuntu on top of upstart, that Debian will be able
+> to adopt as-is (or with whatever bugfixes the maintainers find along the
+> way).  My look at Fedora 20 confirmed my belief that the integration
+> necessary to have a robust systemd boot across all the configurations
+> that Debian supports has not actually been done yet.  systemd upstream
+> advocates shipping systemd units upstream where they can be consumed
+> unmodified by distributions, but in practice Debian is going to be on
+> the hook for debugging the very long tail of integration problems.  It's
+> hard to gauge whether the energy saved by not bringing upstart up to
+> feature parity outweighs the energy spent on bringing systemd
+> integration up to snuff, but I definitely don't think there's a clear
+> point here in systemd's favor.
+
+I believe the level of features that systemd brings to the table is
+substantially beyond what's available from upstart at the current time,
+and am confident that, even including the level of effort required to
+integrate systemd without the work that Ubuntu has done for upstart, we
+will end up ahead on the Linux ports.  My defense of that position is
+basically the sum total of my previous two messages, so I won't repeat it,
+just note that you have correctly identified a core disagreement between
+the two of us.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 00:09:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 00:09:10 GMT) (full text, mbox, link).

+ +

Message #1969 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Mon, 30 Dec 2013 19:07:25 -0500
+
+
On Mon, Dec 30, 2013 at 5:51 PM, Russ Allbery wrote:
+> Michael Gilbert writes:
+>
+>> Doesn't a TC mandate on the default init system in some sense violate
+>> Debian's spirit of meritocracy?
+>
+> I believe that we have enough information to make an informed choice
+> already, and that the sides are fairly well-defined and hardened in their
+> opinions.  That means that this dispute falls under section 6.1.2 of the
+> constitution:
+
+I entirely concur that the social problem resides rightly within the
+jurisdiction of the TC.  With that said, however, it is worth
+considering whether the role of the TC may be more effective if
+directed at the root (the social), rather than the branches (the
+technical choice), of the problem.  The key, I think, is for the TC to
+provide a reasonable path for those currently identifying with any of
+the hardened camps to redirect their negative energy away from
+argument and toward something more positive: technical work and actual
+code.
+
+> Regardless of how we structure the installer, we need to have a default
+> init system (unless we plan on making every user choose, which I would
+> dismiss out of hand as a horrible UI experience for the average user, who
+> really doesn't care).
+
+As stated in my suggestion, initsel would of course always have a
+default, and only "expert" users would be empowered to travel the road
+less traveled.  The no default idea that gets thrown about a lot is,
+of course, infeasible as a matter of practicality.
+
+> Init systems are not like desktop environments: they require work by a
+> huge swath of the developer community, and the average user does not
+> generally switch from one to the other.
+
+I think, on the contrary, the nmu procedure is quite effective at
+enabling a small subset of the developer community (those that have a
+strong shared interest) to effect large changes across the entire
+archive (of course when maintainers stay out of the way,).
+
+This process has been demonstrated many times (although slow-going)
+for lots of other sweeping changes (e.g. buildflags, usr/share/doc,
+etc.).
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 00:18:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Vincent Bernat <bernat@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 00:18:05 GMT) (full text, mbox, link).

+ +

Message #1974 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Vincent Bernat <bernat@debian.org>
+
To: Michael Gilbert <mgilbert@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Tue, 31 Dec 2013 01:16:10 +0100
+
+
[Message part 1 (text/plain, inline)]
+
 ❦ 30 décembre 2013 23:31 CET, Michael Gilbert <mgilbert@debian.org> :
+
+> Doing something like this, the best init system can win based truly on
+> merit (if/when the work gets done), rather than as a fuzzy upfront
+> judgement call.
+
+Unfortunately, being the best init is the not only the matter of its
+maintainers. A good integration implies to modify some packages whose
+maintainer may be hostile to some init and may consider that their
+package work well enough to not enable some feature needed by some init.
+
+I am pretty vague, by I believe that the TC has currently a case for
+such an example.
+
+Only once (and if) systemd gets to be the default init, we will be able
+to leverage all its abilities by full integration into Debian.
+-- 
+Don't compare floating point numbers just for equality.
+            - The Elements of Programming Style (Kernighan & Plauger)
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 00:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 00:24:04 GMT) (full text, mbox, link).

+ +

Message #1979 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Mon, 30 Dec 2013 16:20:31 -0800
+
+
Michael Gilbert <mgilbert@debian.org> writes:
+> On Mon, Dec 30, 2013 at 5:51 PM, Russ Allbery wrote:
+
+>> I believe that we have enough information to make an informed choice
+>> already, and that the sides are fairly well-defined and hardened in
+>> their opinions.  That means that this dispute falls under section 6.1.2
+>> of the constitution:
+
+> I entirely concur that the social problem resides rightly within the
+> jurisdiction of the TC.  With that said, however, it is worth
+> considering whether the role of the TC may be more effective if directed
+> at the root (the social), rather than the branches (the technical
+> choice), of the problem.  The key, I think, is for the TC to provide a
+> reasonable path for those currently identifying with any of the hardened
+> camps to redirect their negative energy away from argument and toward
+> something more positive: technical work and actual code.
+
+Well, I think it's worth pointing out that my transition plan looks
+somewhat similar to your plan, as far as the jessie release.  (Then it
+starts diverging.)  Part of my goal in writing up that plan was, as you
+say, to try to provide a means for people who are committed to one system
+or the other to continue to work on what they're passionate about even if
+it's not chosen as the default init system.
+
+Whether they do so or not is up to them, of course, as it should be.
+
+However, I don't want to understate the amount of effort required to
+integrate with the init system across the distribution.  I'm less
+pessimistic than Steve, but he's not wrong that the choice of a default
+init system will have sweeping consequences for what will work and what
+won't.  This will particularly be the case if that init system supports
+capabilities beyond the sysvinit set.
+
+I do think it would be possible to maintain package compatibility with
+both systemd and upstart.  That was something I was curious about and
+therefore explicitly tested as part of my evaluation, and was able to do
+so to my satisfaction.  That said, I tackled a fairly simple daemon, and
+something like NFS support would require people with deep knowledge of
+each supported init system to maintain that support.
+
+I don't think it's a good idea to ask everyone to pursue all paths in
+parallel.  I think Debian does a bit too much of that right now.  We
+should pick a winner that we believe is technically superior and focus the
+mandatory, archive-wide effort on it.  We should then *not get in the way*
+of people who also want to pursue alternative paths, but not assume that
+they will necessarily be successful, and not require that everyone get
+involved in that effort beyond the level of integrating patches that we
+currently expect for, say, the Hurd port.
+
+But, anyway, I don't think our positions are really that different.  The
+main difference is that I think we should pick a default init system for
+jessie now, and you feel like we should do effectively an archive-wide
+bake-off and then go with whatever one achieves the best integration.  I
+have to admit to a deep personal dislike of "contests" like that, since I
+find them stressful and demotivating and think they make the process of
+free software development less fun.  I'd rather decide on our default and
+on the mandatory work now, so that everyone knows where they stand, and
+then let people make their own decisions about what they want to spend
+time on beyond the required minimum.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 00:33:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 00:33:08 GMT) (full text, mbox, link).

+ +

Message #1984 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Mon, 30 Dec 2013 19:28:52 -0500
+
+
On Mon, Dec 30, 2013 at 7:16 PM, Vincent Bernat wrote:
+>  ❦ 30 décembre 2013 23:31 CET, Michael Gilbert :
+>
+>> Doing something like this, the best init system can win based truly on
+>> merit (if/when the work gets done), rather than as a fuzzy upfront
+>> judgement call.
+>
+> Unfortunately, being the best init is the not only the matter of its
+> maintainers. A good integration implies to modify some packages whose
+> maintainer may be hostile to some init and may consider that their
+> package work well enough to not enable some feature needed by some init.
+
+That is a hypothetical, of course, but it is a very real possibility
+for any path that the TC decides here.  However, selectable inits may
+(possibly counter-intuitively) reduce this likely-hood.  Since that
+maintainer in the way also gets his init of choice, he may be less
+likely to oppose an alternative that doesn't in any real sense get in
+his way.
+
+However, if/when this does happen, it will be an interesting test of
+whether the TC has the political will to override an indignant
+maintainer with their 3-to-1 majority power.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 00:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to cameron <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 00:39:04 GMT) (full text, mbox, link).

+ +

Message #1989 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: cameron <camerontnorman@gmail.com>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 00:27:28 -0008
+
+
[Message part 1 (text/plain, inline)]
+
+
+On Mon, Dec 30, 2013 at 3:30 PM, Steve Langasek <vorlon@debian.org> 
+wrote:
+> On Mon, Dec 30, 2013 at 11:56:33AM -0800, Russ Allbery wrote:
+>>  >> Rather, we're talking about whether or not to swap out a core 
+>> component
+>>  >> of an existing integrated ecosystem with a component that we like
+>>  >> better.
+>> 
+>>  > Unless you are proposing to make systemd mandatory for all Debian
+>>  > installations, this is work that needs to be done anyway.
+>> 
+>>  What I'm hearing from both GNOME and KDE maintainers is that 
+>> assuming
+>>  systemd would save them a great deal of work.  I think having 
+>> systemd be
+>>  the only supported and tested option for at least some large 
+>> package sets
+>>  that heavily use the systemd infrastructure upstream is a 
+>> not-unlikely
+>>  long-term outcome.
+>> 
+> It's clear that being able to assume availability of certain dbus 
+> services
+> is labor-saving for GNOME and KDE upstreams, and I see no reason for 
+> them
+> not to standardize on such a requirement assuming the dbus services 
+> have
+> sane APIs (which they do).
+> 
+> What I object to is referring to this as "assuming systemd".  They are
+> systemd APIs, sure, but with one exception the systemd 
+> implementations are
+> not presently tied to the use of systemd as init, and there is an 
+> alternate
+> implementation of that one exception (systemd-shim).
+> 
+> From comments made by various GNOME upstream developers on this, I 
+> think
+> they are being suitably cautious about avoiding scope creep where the
+> systemd dependencies are concerned.  So in what sense are the GNOME 
+> and KDE
+> requirements not already being met on top of upstart?  The only 
+> outstanding
+> issue I see is with non-Linux ports, because logind is not portable; 
+> that's
+> definitely a problem for running GNOME on kfreebsd, but it's actually 
+> a
+> rather narrowly-scoped porting problem and one that the ports need to 
+> deal
+> with one way or another if they want GNOME to continue working.
+> 
+> I'm sure there are GNOME upstream contributors who would be happy to 
+> see
+> GNOME become systemd-only.  But I think their motivations in letting 
+> the
+> lines be blurred in such a way are purely political, not technical; 
+> and I
+> give GNOME upstream as a whole the benefit of the doubt that they 
+> would not
+> so weaken their project to suit someone's political agenda.
+> 
+>>  One can, of course, have a wide variety of reactions to that.  As 
+>> someone
+>>  who considers portability to be an inherent good, I find it sad, 
+>> although
+>>  I don't have a full appreciation for what problems GNOME is trying 
+>> to
+>>  solve by increasing its reliance on systemd.  But I'm highly 
+>> dubious that
+>>  Debian will just single-handedly fix that, or that we would drop 
+>> GNOME
+>>  because we don't like upstream's integration decisions.
+>> 
+> I find the notion that Debian doing this "single-handedly" is an 
+> obstacle to
+> be a bizarre one.  Debian has more than one pair of hands, it's a 
+> veritable
+> multi-tentacled beast.  Have we so atrophied as a community that 
+> we'll wail
+> and gnash our teeth about a non-portable dependency, but have no 
+> porters
+> willing to actually provide a native implementation of a (quite 
+> small) dbus
+> API?
+> 
+
+> 
+> You've said that you think the portability question doesn't weight 
+> strongly
+> in favor of either upstart or systemd, because neither port is done 
+> yet. 
+> But the amount of work that would be involved in porting systemd to 
+> kfreebsd
+> is an order of magnitude greater than the work involved in porting 
+> upstart. 
+> logind is just one small component of systemd, which someone could 
+> provide
+> an API-compatible implementation for without having to contend with 
+> the
+> question of cgroups on non-Linux kernels.  If even that is out of 
+> reach for
+> the Debian porters, how could we ever expect a full BSD port of 
+> systemd to
+> materialize?
+> 
+
+systemd lists logind as non-reimplementable, and that was pretty much 
+proven when Ubuntu tried to reimplement it and ended up reimplementing 
+or pulling in a ton of systemd anyway. Seeing that, both KWin and 
+Mutter have denounced portability to non-Linux when running on Wayland. 
+They will soon be outright non-portable (when ConsoleKit support is 
+dropped, which, AFAIK, is soon in GNOME).
+
+> I think the reality is that adopting systemd as default init for 
+> Debian is
+> nothing short of a death sentence for the non-Linux ports.  The move 
+> to a
+> different init will have a snowball effect in the distribution, as 
+> packages
+> stop being tested with sysvinit and popular support grows for dropping
+> compatibility with sysvinit altogether.  This is not a problem if the 
+> ports
+> are in a position to come along on this transition with a moderate
+> investment in porting init.  But the porting required for systemd as 
+> a whole
+> is far from moderate, and I believe that faced with such a 
+> requirement the
+> non-Linux ports would wither and die.  I know there are Debian 
+> developers
+> (including many in the GNOME/systemd "camp") who think this is a 
+> desirable
+> outcome.  I have no personal attachment to the non-Linux ports, but I 
+> do
+> think that as an existing part of our Debian community, the TC should 
+> at
+> least give these ports a fighting chance, because this kind of 
+> competition
+> is healthy.
+> 
+>>  > My understanding was that Dimitri had got upstart running on BSD.
+>> 
+>>  The latest that I have seen on this porting effort is here:
+>> 
+>>  
+>> http://blog.surgut.co.uk/2013/11/libnih-upstart-dependency-ported-to.html
+>> 
+>>  I asked previously on this bug if someone had later news.  Do you 
+>> have
+>>  more information than that?
+>> 
+>>  The above is definitely not "upstart running on BSD."  That's 
+>> upstart's
+>>  underlying support library mostly working on BSD after disabling two
+>>  features (that are required for upstart).  I haven't not heard 
+>> whether the
+>>  porting of upstart proper has started.  That will certainly be much 
+>> easier
+>>  once libnih is ported, but there are, for example, direct uses of 
+>> epoll in
+>>  upstart proper.  (I don't know if kFreeBSD already has a 
+>> portability layer
+>>  for epoll in terms of kqueue.)
+>> 
+> AIUI, upstart itself built out of the box once libnih was available, 
+> because
+> all the portability issues are encapsulated in libnih.  (The single 
+> use of
+> epoll in the upstart source is in the upstart-socket-bridge, which is 
+> an
+> optional component from upstart's perspective and certainly not 
+> needed for
+> booting a Debian base system - so presumably Dimitri just built with 
+> this
+> bridge disabled.)
+> 
+> With libinotify-kqueue (that Dimitri maintains), kfreebsd 10 (in
+> experimental), eglibc 2.18 (also in experimental), and Dimitri's 
+> branch of
+> libnih, it seems that all the portability requirements for upstart 
+> are met,
+> except for abstract socket support.  There are evidently still some 
+> porting
+> problems that aren't detected at build time, because upstart doesn't 
+> yet
+> boot on kfreebsd.  But all things considered, the port is rather far 
+> along.
+> 
+>>  upstart is a great project, of which its maintainers are deservedly 
+>> proud.
+>>  However, I don't agree that it's better than systemd.  My own 
+>> research
+>>  convinced me of the opposite.  But putting that aside, my point in 
+>> that
+>>  section is that, given feature parity (and I mean "feature" 
+>> expansively,
+>>  including adaptibility to Debian's needs), we should choose systemd
+>>  because it has more project momentum and better existing 
+>> integration,
+>>  which means that we will have to spend less energy on it and will 
+>> have
+>>  more energy to spend on other things.
+>> 
+>>  It's absolutely worth doing our own, better things.  What I don't 
+>> want to
+>>  do is our own *worse* things.  Or, for that matter, our own 
+>> equivalent
+>>  things, when we could instead use work that already exists.  It's a 
+>> waste
+>>  of energy.
+>> 
+> I think this downplays the significance of the integration work that 
+> has
+> already been done in Ubuntu on top of upstart, that Debian will be 
+> able to
+> adopt as-is (or with whatever bugfixes the maintainers find along the 
+> way). 
+> My look at Fedora 20 confirmed my belief that the integration 
+> necessary to
+> have a robust systemd boot across all the configurations that Debian
+> supports has not actually been done yet.  systemd upstream advocates
+> shipping systemd units upstream where they can be consumed unmodified 
+> by
+> distributions, but in practice Debian is going to be on the hook for
+> debugging the very long tail of integration problems.  It's hard to 
+> gauge
+> whether the energy saved by not bringing upstart up to feature parity
+> outweighs the energy spent on bringing systemd integration up to 
+> snuff, but
+> I definitely don't think there's a clear point here in systemd's 
+> favor.
+> 
+> -- 
+> Steve Langasek                   Give me a lever long enough and a 
+> Free OS
+> Debian Developer                   to set it on, and I can move the 
+> world.
+> Ubuntu Developer                                    
+> http://www.debian.org/
+> slangasek@ubuntu.com                                     
+> vorlon@debian.org
+> 
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 01:09:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 01:09:09 GMT) (full text, mbox, link).

+ +

Message #1994 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: cameron <camerontnorman@gmail.com>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Mon, 30 Dec 2013 17:05:54 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Dec 31, 2013 at 12:27:28AM -0008, cameron wrote:
+
+> systemd lists logind as non-reimplementable, and that was pretty
+> much proven when Ubuntu tried to reimplement it and ended up
+> reimplementing or pulling in a ton of systemd anyway.
+
+All this proves is that Ubuntu developers have the good sense to not
+reinvent the wheel unnecessarily.  No one ever tried to reimplement logind
+for Ubuntu, at all.  Why should they, when logind is already a perfectly
+usable implementation of logind?
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 01:15:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 01:15:09 GMT) (full text, mbox, link).

+ +

Message #1999 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Mon, 30 Dec 2013 20:12:19 -0500
+
+
On Mon, Dec 30, 2013 at 7:20 PM, Russ Allbery wrote:
+> Michael Gilbert <mgilbert@debian.org> writes:
+>> On Mon, Dec 30, 2013 at 5:51 PM, Russ Allbery wrote:
+>
+>>> I believe that we have enough information to make an informed choice
+>>> already, and that the sides are fairly well-defined and hardened in
+>>> their opinions.  That means that this dispute falls under section 6.1.2
+>>> of the constitution:
+>
+>> I entirely concur that the social problem resides rightly within the
+>> jurisdiction of the TC.  With that said, however, it is worth
+>> considering whether the role of the TC may be more effective if directed
+>> at the root (the social), rather than the branches (the technical
+>> choice), of the problem.  The key, I think, is for the TC to provide a
+>> reasonable path for those currently identifying with any of the hardened
+>> camps to redirect their negative energy away from argument and toward
+>> something more positive: technical work and actual code.
+>
+> Well, I think it's worth pointing out that my transition plan looks
+> somewhat similar to your plan, as far as the jessie release.  (Then it
+> starts diverging.)
+
+The key differences are that it is more succinct, roles and
+requirements are defined, no init system is outright rejected, and the
+default is selected on demonstrable merit.
+
+> Part of my goal in writing up that plan was, as you
+> say, to try to provide a means for people who are committed to one system
+> or the other to continue to work on what they're passionate about even if
+> it's not chosen as the default init system.
+
+Unfortunately at least two camps will be entirely dejected by any TC
+mandate here.
+
+> Whether they do so or not is up to them, of course, as it should be.
+>
+> However, I don't want to understate the amount of effort required to
+> integrate with the init system across the distribution.  I'm less
+> pessimistic than Steve, but he's not wrong that the choice of a default
+> init system will have sweeping consequences for what will work and what
+> won't.  This will particularly be the case if that init system supports
+> capabilities beyond the sysvinit set.
+>
+> I do think it would be possible to maintain package compatibility with
+> both systemd and upstart.  That was something I was curious about and
+> therefore explicitly tested as part of my evaluation, and was able to do
+> so to my satisfaction.  That said, I tackled a fairly simple daemon, and
+> something like NFS support would require people with deep knowledge of
+> each supported init system to maintain that support.
+>
+> I don't think it's a good idea to ask everyone to pursue all paths in
+> parallel.  I think Debian does a bit too much of that right now.  We
+> should pick a winner that we believe is technically superior and focus the
+> mandatory, archive-wide effort on it.  We should then *not get in the way*
+> of people who also want to pursue alternative paths, but not assume that
+> they will necessarily be successful, and not require that everyone get
+> involved in that effort beyond the level of integrating patches that we
+> currently expect for, say, the Hurd port.
+
+I don
+
+> But, anyway, I don't think our positions are really that different.  The
+> main difference is that I think we should pick a default init system for
+> jessie now, and you feel like we should do effectively an archive-wide
+> bake-off and then go with whatever one achieves the best integration.
+
+And Debian ends up with not only apple pie, but pumpkin and blueberry
+pies, and of in a corner there will be others thinking about
+cinnamon-spiced apple and blueberry-raspberry and other
+never-before-seen flavors.   What a wonderful bake-off that would be
+:)
+
+Think about how it would go over if the directors of that metaphorical
+bake-off forced all the participants to produce the exact same pie.
+No one would really want to participate, and winning would be entirely
+meaningless.  It wouldn't be a bake-off at all.  It would be more like
+a mass-production assembly line.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 02:57:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 02:57:05 GMT) (full text, mbox, link).

+ +

Message #2004 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: init system thoughts
+
Date: Tue, 31 Dec 2013 02:55:45 +0000
+
+
I see that the LWN commentariat already has my decision selected in
+advance, so I might as well write up some more detailed thoughts before
+any other words are put into my mouth!
+
+
+Choice of default
+-----------------
+
+Firstly, I've tried to keep my employer affiliation out of this as much
+as possible, and I have come under no pressure from that quarter.  I'll
+reiterate my previous comments on debian-devel:
+
+  http://lists.debian.org/debian-devel/2013/10/msg00747.html
+  http://lists.debian.org/debian-devel/2013/10/msg00777.html
+  http://lists.debian.org/debian-devel/2013/10/msg00818.html
+
+It's apparently no surprise that my preference for a default lies with
+Upstart.  To the extent that I have a pre-existing bias it has more to
+do with the fact that I have substantially more real-world deployment
+experience with Upstart in an environment structurally very similar to
+Debian (Ubuntu, obviously), which has led me to believe that it would be
+a fine choice for deployment in Debian which could be put in place with
+a minimum of disruption, and which would close as few doors as possible
+to experimentation and innovation.
+
+That said, I will add that I have been impressed with the technical
+aspects of systemd that I have seen while working on adding support for
+it to my packages by way of research for this debate.  Its documentation
+is comprehensive, a great deal of work has clearly gone into the range
+of options available in unit files, and it has admirable facilities
+available for system administrators.  I am quite happy for it to be my
+second choice (which is by no means irrelevant given our voting
+protocol); I think it would be a more than worthwhile step forward from
+sysvinit, just in a somewhat different direction that does not appeal
+quite as much to me.
+
+
+Reservations with systemd
+-------------------------
+
+My main concerns with systemd relate to its broad scope regarding units
+it provides for system initialisation tasks currently performed by other
+packages, and the potential for that to interfere with past and future
+work elsewhere in Debian.  I can understand why the systemd authors felt
+it valuable to expand its scope in this way, to provide a more
+consistent experience across the board.  Nevertheless, it seems to
+significantly complicate the job of integrating it with some excellent
+features that already exist in Debian and which are superior to those
+currently in most other distributions.  I realise that the Debian
+systemd maintainers have generally expressed willingness to deal with
+this kind of integration problem where appropriate, but I find the
+impedance mismatch to be much higher than it is with Upstart which
+leaves these tasks up to the distribution.
+
+The two examples which I've run across so far, both ones I was inclined
+to look at since I'm familiar with the territories, are:
+
+  #716812 (binfmt-support)
+
+    (I'm the author and maintainer of binfmt-support.)
+
+    The discussion on this (archived earlier in #727708) does now seem
+    to have been resolved reasonably amicably so far; I've turned
+    binfmt-support into an independent upstream package hosted on
+    nongnu.org, given it a systemd unit file while I was there, and will
+    work on getting that into more distributions.
+
+    However, I maintain that this is really something that has no
+    particular reason to be integrated with the init system, that it has
+    much more interesting interactions with packaging than it does with
+    other system events, and that it is busywork to convert things away
+    from a system that works measurably better in Debian and derivatives
+    than (TTBOMK) any other GNU/Linux distribution.
+
+  #608457 (console-setup)
+
+    (I've contributed to console-setup in some small ways, although I'm
+    not its primary maintainer by any stretch of the imagination.)
+
+    console-setup is a fantastic piece of innovation in Debian; instead
+    of shipping two entirely independent sets of keymap files for
+    virtual consoles and for X, the former of which is mostly unloved,
+    let's generate virtual console mappings dynamically from XKB!  It's
+    naturally not an easy task since the console is less capable in
+    various important ways, but it's demonstrably possible to do a
+    pretty accurate job.  Like binfmt-support, it probably ought to be
+    turned into an independent upstream package to make it easier for
+    other distributions to adopt, but in the meantime it's tremendously
+    useful for Debian.
+
+    This seems a bit conceptually tricky to integrate with systemd,
+    because localectl(1) exposes the console-data style of keymap naming
+    in its interface, and with console-setup you only use the X style.
+    The Debian systemd maintainers haven't yet offered a suggestion in
+    the bug, but perhaps they'll come up with something appropriate
+    (maybe just disabling set-keymap/list-keymaps, or converting both
+    ways and accepting the inevitable round-trip errors).  But my point
+    is that this is a class of problems that simply doesn't arise with
+    an init system that has a smaller scope.
+
+Basically, systemd would be more compelling to me if it tried to do
+less.  I don't expect to persuade systemd advocates of this, as I think
+it amounts to different basic views of the world, but the basic approach
+here is probably the single biggest factor influencing my position.
+
+
+The criticisms of Upstart's event model in the systemd position
+statement simply do not make sense to me.  Events model how things
+actually happen in reality; dependencies are artificial constructions on
+top of them, and making them work requires the plethora of different
+directives in systemd (e.g. Wants, which is sort of a non-depending
+dependency) to avoid blocking the boot process on a single failing
+service.  Yes, there are some bugs possible in the Upstart design, but I
+don't agree that those are world-ending fundamental issues and I think
+they're generally incrementally fixable.  The systemd design appears to
+me to expose far more complexity to the user writing unit files, and I
+think it's important that their mental model be as straightforward as
+possible.
+
+(Now, I've been working with Upstart's model for years, and it's now a
+pretty fundamental way of how I think of system operation; so if people
+who are new to *both* models rather than partisans of one side or the
+other consistently tell me that the systemd model is easier to grasp,
+then I'll listen.)
+
+
+There is of course also the non-Linux porting issue, which Ian, Russ,
+and Steve have discussed at more length elsewhere, and I won't repeat it
+at length.  I will just add in response to Russ that there is a great
+difference between one project whose lead maintainer has explicitly said
+that he will reject patches for porting to non-Linux architectures
+because they fundamentally do not make sense with its architecture, and
+another project one of whose developers has been working on such a port
+with some degree of success so far.
+
+Like Ian and Steve, I don't have much in the way of personal attachment
+to the non-Linux architectures in Debian, but I feel that it is very
+important not to close off options and to keep the spaces for
+experimentation with different kernels that we've built; you can't
+meaningfully experiment with a different kernel without building an OS
+on top of it, and Debian has provided a useful framework for this for
+many years now.  There is some chance that we might be able to magic up
+a truly compelling scheme whereby we can support different init systems
+on different kernels - I would certainly encourage porters to try - but
+it seems like a risky and difficult plan.
+
+
+Reservations with Upstart
+-------------------------
+
+I am no fan of the CLA; this will not especially surprise readers from
+Canonical although I'm not sure I've said it straight out in a Debian
+context before.  I think that it has proven to have far more downsides
+than upsides for the company and that it is an unnecessary obstacle to
+building a development community, and I've made that argument
+internally.  This is a minus point for me.  That said, from Debian's
+point of view I don't see significant practical differences from a
+BSD-style licence, and especially given the declared willingness to take
+non-CLA patches in the Debian packaging in a reasonable way I don't see
+it as a blocker.  (Also, given that Upstart intentionally has a smaller
+scope, a smaller number of developers is less of a problem.)
+
+
+The ptrace arrangements used for "expect fork" and "expect daemon" have
+been rather flaky in practice, especially when Upstart jobs are written
+by people not experts in doing so, and they are an obstacle to
+portability.  I think we should strongly discourage use of these in
+Debian in favour of some other readiness protocol.  My personal
+aesthetic preference is for the "expect stop" scheme or something close
+to it, but I really don't care that deeply and the sd_notify scheme or
+similar would work too.  Indeed, I might well be inclined to support
+disabling the ptrace-requiring features entirely in Debian, and working
+to disable them in Ubuntu in time as well (although that would require a
+transition plan).
+
+
+I think Russ has sold me on systemd's journal being a win, at least in
+terms of how it enables much better status output for services, and it's
+a shame that something equivalent isn't present in Upstart.  My
+practical experience of late has been that the per-job log files you get
+by default are good enough for most purposes where I need to debug
+service operations, but it certainly isn't all packaged up as neatly.
+
+
+Deployment plans
+----------------
+
+I am strongly in agreement with Russ' position on the matter of multiple
+init systems in the archive.  While the world would be a lot simpler if
+we only had one to support, I don't see that as achievable in the short
+term without (to me) unacceptable losses, and this is mainly a matter of
+refraining from deleting code.  I don't think we have to be doctrinaire
+about mandating lots of effort for every service maintainer, but at
+least asking them not to break things that people are still using (and
+that we'll need for upgrades at least for a while) seems reasonable.
+
+I would love to see the "multiple" position in the debate wiki
+(https://wiki.debian.org/Debate/initsystem/multiple) fleshed out into
+more of a practical deployment proposal; I unfortunately haven't had
+time to dive into it in detail but at present it feels rather handwavy
+to me.  I think that this should be a major part of what we try to
+thrash out over the next few weeks (at least to establish feasibility,
+given our mandate not to do detailed design work within the TC as such),
+and that there should eventually be ballot options related to this
+orthogonal to the choice of default.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 03:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 03:21:04 GMT) (full text, mbox, link).

+ +

Message #2009 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 03:17:39 +0000
+
+
On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
+> My belief, and again I welcome concrete reasons why I'm not correct, is
+> that adopting upstart poses a similar risk for the Hurd port as adopting
+> systemd, and I care just as much about the Hurd port as kFreeBSD.  And
+> while kFreeBSD is in better shape due to the already-begun upstart port,
+> there are still significant porting challenges in the way of maintaining
+> feature parity in the kFreeBSD port at the level that it has today.  Many
+> of those challenges are going to remain regardless of which init system we
+> pick.
+
+I haven't looked at this in much detail, and I suspect Dimitri hasn't
+yet although IIRC he did express some interest in doing so.  But I
+haven't seen anyone else try to outline the scope of a port, so let me
+try to do so for the sake of general understanding.  As far as I know,
+the hardest parts would be inotify, ptrace, and prctl
+(PR_SET_CHILD_SUBREAPER).
+
+inotify is used to notice changes to configuration files.  This is
+certainly helpful for users, but it isn't critical as "initctl
+reload-configuration" works without it.  We could probably do without
+this with the aid of a dpkg trigger.
+
+ptrace is used for "expect fork" and "expect daemon"; as I indicated in
+another post, I think it would be preferable to avoid these in Debian
+and quite possibly to compile them out.  (This would mean we wouldn't be
+able to translate Ubuntu jobs quite as directly, and a number of
+important jobs would definitely need to be changed, but the conversion
+isn't usually particularly difficult.)
+
+prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification work
+properly when Upstart is supervising a user session.  This isn't a
+required feature and could easily be compiled out until suitable kernel
+support is available (this actually seems like the sort of thing that
+could be done in the Hurd without too much difficulty, but I haven't
+looked into it).  If absent, it might well impede the ability to do an
+advanced desktop port, but it wouldn't get in the way of porting the
+bulk of services.
+
+There might also be odds and ends around the details of wait status
+handling.
+
+So, I'll certainly concede that I haven't actually tried this, but from
+what I know of Upstart/libnih's system dependencies, I think that the
+Hurd could be accommodated with at worst possibly some loss of
+non-critical features.
+
+> I want to mention again something that you'd dismissed as possibly a joke
+> earlier, but which I was actually serious about: I think a world in which
+> we use systemd on Linux and upstart on non-Linux ports, should upstart
+> prove much more portable, actually makes sense.  As I said in my other
+> writeup, I believe the systemd feature advantage is sufficient to choose
+> systemd in isolation, without the other issues discussed.  I also believe
+> that maintaining a systemd unit plus an upstart configuration is, modulo
+> testing (which I realize is a huge issue), much easier than maintaining a
+> single sysvinit script.
+
+I wouldn't discard this option out of hand, but I think it would need
+significant tool support to be practical (e.g. heuristic generation of
+Upstart job files from systemd units), unless we expect all service
+maintainers to have kFreeBSD/Hurd VMs lying around.  Keeping the
+sysvinit scripts and using Upstart as the init daemon is another
+possibility, and at least in that case the sysvinit scripts are probably
+still lying around.  We don't even necessarily have to choose between
+those up-front.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 03:27:03 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 03:27:04 GMT) (full text, mbox, link).

+ +

Message #2014 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Michael Gilbert <mgilbert@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Mon, 30 Dec 2013 19:24:19 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 30, 2013 at 08:12:19PM -0500, Michael Gilbert wrote:
+> > Part of my goal in writing up that plan was, as you
+> > say, to try to provide a means for people who are committed to one system
+> > or the other to continue to work on what they're passionate about even if
+> > it's not chosen as the default init system.
+
+> Unfortunately at least two camps will be entirely dejected by any TC
+> mandate here.
+
+I don't agree with that conclusion.
+
+When it comes to technology choices, you win some and you lose some.  If
+upstart wins, I will be happy.  If systemd wins, I will also be happy,
+because it's long overdue that Debian *make a decision*; and for all that
+there are aspects of systemd that make me uncomfortable, it will still be
+far better than the status quo.
+
+Your proposal smells like the status quo.  Namely, instead of the project
+making a decision and being able to all pull together in the same direction
+to provide the best possible OS, we will continue to coast, squandering
+efforts on preserving users' ability to make choices about things that no
+user should ever be asked to care about.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 03:27:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 03:27:07 GMT) (full text, mbox, link).

+ +

Message #2019 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Mon, 30 Dec 2013 19:26:23 -0800
+
+
Thanks for this write-up, Colin.  This was very interesting to me,
+particularly in the concrete examples of where you've felt like systemd
+has stepped into areas that will pose integration problems for us.  This
+is something that I've seen referred to in the abstract frequently, but
+without a lot of specifics that made sense to me.  Both of those examples
+make sense to me.
+
+Just a couple of specific comments....
+
+Colin Watson <cjwatson@debian.org> writes:
+
+> (Now, I've been working with Upstart's model for years, and it's now a
+> pretty fundamental way of how I think of system operation; so if people
+> who are new to *both* models rather than partisans of one side or the
+> other consistently tell me that the systemd model is easier to grasp,
+> then I'll listen.)
+
+I am new to both models.  I'm not very fond of the upstart model.
+
+Lennart had a comment on this point that I thought phrased the problem in
+an interesting way: both systemd and upstart deal with the same data, but
+with systemd, the full dependency tree is precalculated and exists as
+state within the init system.  With upstart, behavior is dynamic and to
+some degree emergent: you know who is listening to what signals, but you
+can arbitrarily introduce signals, and you're dealing with a message bus
+rather than a dependency tree, so you're reacting to things as they happen
+on the bus.  In systemd, you can dump everything that can possibly happen
+and work through the state transitions by hand if needed, with the
+possible exception of unexpected device events (which are horribly
+important in some cases -- don't get me wrong -- but which are
+uninteresting in a lot of common debugging scenarios).  I think it's
+somewhat harder to do that with upstart, where events are generated more
+dynamically.
+
+Basically, the way I'd put it is that I think the upstart event model is
+the sort of elegant, minimal model that someone who has thought really
+hard about the space comes up with, but which is hard to understand for
+people who have *not* thought really hard about the space.  It's elegant
+and clever; for me personally, I find it *too* clever.  I understand what
+it's trying to do, and it has a certain grace, but I find a dependency
+graph more robust and predictable, and even the levels of dependencies
+make sense to me given packaging background and familiarity with the
+Depends vs. Recommends scenarios.  I can build a relatively complete
+mental map more easily than I can with the message bus approach.
+
+I should probably note here that I'm a notorious skeptic about message
+buses in general.  People I work with have probably gotten rather tired of
+me going on about my feeling that message bus integrations are overly
+complex to reason about, hard to guarantee correctness of, and are
+overused in system design.  :)
+
+> There is of course also the non-Linux porting issue, which Ian, Russ,
+> and Steve have discussed at more length elsewhere, and I won't repeat it
+> at length.  I will just add in response to Russ that there is a great
+> difference between one project whose lead maintainer has explicitly said
+> that he will reject patches for porting to non-Linux architectures
+> because they fundamentally do not make sense with its architecture, and
+> another project one of whose developers has been working on such a port
+> with some degree of success so far.
+
+This is a very valid point, and you're right, I probably understated that
+in my writeup.  One of the things that I may turn out to be wrong about
+(and would be happy to be wrong about, for the record) is the likelihood
+of completing a working port of upstart to Hurd and kFreeBSD.  As I
+mentioned but probably not explicitly enough, the existence of those ports
+would, for me, turn the whole second part of my analysis into a dead heat
+between systemd and upstart as opposed to a general advantage for upstart
+in terms of ecosystem integration.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 03:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 03:33:04 GMT) (full text, mbox, link).

+ +

Message #2024 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Mon, 30 Dec 2013 19:28:29 -0800
+
+
Colin Watson wrote:
+> (Now, I've been working with Upstart's model for years, and it's now a
+> pretty fundamental way of how I think of system operation; so if people
+> who are new to *both* models rather than partisans of one side or the
+> other consistently tell me that the systemd model is easier to grasp,
+> then I'll listen.)
+
+I'd like to respond to this point, since I have a clear memory of
+dealing with both upstart's model and systemd's model for the first
+time.  I also work professionally with a system (ChromeOS) that uses
+upstart, and I've dealt with systemd quite a bit as well.  For the sake
+of full disclosure, my position is that I'd prefer systemd over upstart;
+I'd be OK with upstart if and only if systemd remained a viable
+alternative (in other words, packages maintaining both upstart jobs and
+systemd units but not necessarily maintaining init scripts seems pretty
+reasonable).  So, at this point I'm squarely in the systemd camp, but
+not for any particular reasons of partisanship; I simply find the
+technology and model better.
+
+I started out dealing with the sysvinit model, pre-startpar; I dealt
+quite frequently with the magic ordering numbers (S20, K80, etc).  My
+first exposure to dependencies was through startpar and LSB, and they
+made sense, though I was never a fan of the magic 'S' runlevel.  I
+fairly quickly saw that mapping those dependencies to script ordering
+numbers was a hack, albeit a nicely done hack for compatibility; using
+the dependencies natively made a lot more sense, though.
+
+I read about upstart when it was first announced, and I dove into the
+event model quite extensively, thinking that it might help improve
+things.  I never found it particularly intuitive, and in particular the
+whole "start on starting", "start on stopping" etc model never really
+made much sense to me; it didn't seem like a natural mapping of how the
+system worked.  I also, from the beginning, disliked the model of
+starting everything that was possible to start, though I did not at the
+time see what the alternative would be; it simply never really seemed
+like the right model for booting quickly.  (This was reinforced when I
+started paying attention to boot time, inspired by the original "boot in
+5 seconds" presentation; upstart's model seemed entirely unsuited for
+that exercise.)  I also found the requirement to know how many times
+your daemon forked quite obnoxious (even more so the failure mode if you
+get it wrong on even one daemon).  These days, dealing with upstart
+professionally, it still seems entirely too easy to get upstart confused
+and in a difficult to recover state via a single incorrect upstart job,
+and I find it one of the most annoying subsystems to deal with; there's
+a general feeling of "oh, joy, that's probably an upstart issue" every
+time any issue relating to booting comes up.
+
+By contrast, my initial exposure to systemd (via the "systemd for system
+administrators" blog series and the systemd documentation) was actually
+via socket activation, with the dependency mechanism coming later.  The
+socket activation model, as a replacement for dependencies, was one of
+those rare ideas that seemed immediately obvious in hindsight.  My
+introduction to systemd's dependencies was more along the lines of "and
+explicit dependencies exist for when you can't fix your daemon and unit
+file to do things the *right* way".  Similarly, the use of autofs and
+other techniques to allow starting things in parallel even when
+dependencies exist made immediate sense.  And the entire model,
+including its handling of asynchronous events (notably the integration
+with udev), simply felt like a closer fit to how the kernel works and
+how reality works.  Finally, the concept of factoring out common
+elements from daemons seemed quite nice, having dealt with quite a bit
+of ugly boilerplate code.
+
+In both cases, I had no particular reason to like or dislike either
+model; in each case I very much *wanted* them to work out, since my
+exposure to sysvinit versus startpar gave me a very early reason to want
+something better than sysvinit.  I had no other reason to prefer one
+model over the other.  I'm not attached to either init system, nor do I
+have any particular bias or reason to favor one over the other for any
+reason other than superior technology or a model I find clearer and more
+natural.
+
+So, in summary, upon initial introduction, I found systemd's model far
+more intuitive, both innately (in its use of socket activation and
+similar mechanisms to *avoid* dependencies) and as a more natural
+mapping to how the system, kernel, and hardware work.
+
+I hope this writeup of my first impressions of both systems proves
+useful in some way.
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 03:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 03:39:04 GMT) (full text, mbox, link).

+ +

Message #2029 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org, Michael Gilbert <mgilbert@debian.org>
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Mon, 30 Dec 2013 19:35:07 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> When it comes to technology choices, you win some and you lose some.  If
+> upstart wins, I will be happy.  If systemd wins, I will also be happy,
+> because it's long overdue that Debian *make a decision*; and for all
+> that there are aspects of systemd that make me uncomfortable, it will
+> still be far better than the status quo.
+
+I concur with this.
+
+I freely admit that I fell in love with systemd while investigating both
+systems, but if we agree to use upstart, I will happily go add upstart
+configurations to all of my packages and make use of those features.  It's
+still a massive improvement over what we have now.
+
+Furthermore, and more philosophically, Debian has to learn how to respect
+a governance process and make decisions.  We spent way too much time and
+effort not making decisions in this project, which results in big
+flamewars and discomfort and everyone sniping at each other while little
+productive happens.  Frequently, I think this is like tearing off bandages
+over the course of months.  The cumulative pain is much higher than if we
+just made a decision and everyone knew where they stood and what reality
+they needed to adjust to.
+
+Also, I too am happy when we can successfully pursue all courses of action
+at the same time, but at the end of the day, we're trying to create a
+distribution, and that means integrating components, and that means
+deciding on integration protocols.  It's not useful to try to integrate
+everything with everything else in every possible way at the same time.
+You just create an unmanageable combinatoric explosion of possibilities,
+and then someone who just wants to run a Debian system doesn't know which
+paths are supported and tested, and which paths have only been touched by
+one developer if that.
+
+We need to pick a winner.  That doesn't mean we need to pick losers.  It
+does mean that one solution is going to get better support than everything
+else, because that's what integration *means*.  It doesn't mean, or
+shouldn't mean, that other solutions are impossible if someone wants to
+make them work; it just means that we're not going to *require* that they
+work in order to get one's software into Debian.
+
+We probably should have had this discussion for wheezy, to be honest.  But
+regardless, we should pick a default, supported init system for jessie.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 04:36:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 04:36:14 GMT) (full text, mbox, link).

+ +

Message #2034 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Mon, 30 Dec 2013 20:32:46 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
+> Steve Langasek <vorlon@debian.org> writes:
+
+> > From comments made by various GNOME upstream developers on this, I think
+> > they are being suitably cautious about avoiding scope creep where the
+> > systemd dependencies are concerned.  So in what sense are the GNOME and
+> > KDE requirements not already being met on top of upstart?  The only
+> > outstanding issue I see is with non-Linux ports, because logind is not
+> > portable; that's definitely a problem for running GNOME on kfreebsd, but
+> > it's actually a rather narrowly-scoped porting problem and one that the
+> > ports need to deal with one way or another if they want GNOME to
+> > continue working.
+
+> I don't see what you're saying here as substantively different than what I
+> said in my writeup about the ecosystem.  I feel like we're both presenting
+> the same facts through different lenses.
+
+I do see a substantive difference between "GNOME depends on systemd" and
+"GNOME depends on interfaces a, b, and c, which are available as part of
+systemd".
+
+> >> One can, of course, have a wide variety of reactions to that.  As
+> >> someone who considers portability to be an inherent good, I find it
+> >> sad, although I don't have a full appreciation for what problems GNOME
+> >> is trying to solve by increasing its reliance on systemd.  But I'm
+> >> highly dubious that Debian will just single-handedly fix that, or that
+> >> we would drop GNOME because we don't like upstream's integration
+> >> decisions.
+
+> > I find the notion that Debian doing this "single-handedly" is an
+> > obstacle to be a bizarre one.  Debian has more than one pair of hands,
+> > it's a veritable multi-tentacled beast.  Have we so atrophied as a
+> > community that we'll wail and gnash our teeth about a non-portable
+> > dependency, but have no porters willing to actually provide a native
+> > implementation of a (quite small) dbus API?
+
+> Please recall the context here: this whole aside started with an objection
+> to my contention that adopting upstart requires disassembly and redoing of
+> an integration that we would otherwise not have to disassemble.  Nowhere
+> in my message did I say that we would or could not do that disassembly if
+> we adopted upstart; I said that it was work that we otherwise wouldn't
+> have to do.
+
+> That's the intended context of my point above: I don't think we're going
+> to port GNOME to a non-systemd infrastructure, in the sense of carrying
+> significant patches to GNOME to adopt it to, say, not using logind.  I
+> think GNOME will continue to use systemd APIs heavily, which makes GNOME
+> less portable.  That means that systems that are not capable of running
+> those systemd components will need to either port them or develop
+> alternatives.
+
+> I don't consider this wailing or gnashing of teeth, but rather a realistic
+> look at what efforts the project is talking about committing to, as
+> opposed to supporting people working on if they so choose.
+
+Ok.  I think our core point of disagreement here, then, is in our assessment
+of how much work we think this actually is (for the Linux case, not for the
+non-Linux case).  I think the actual package maintenance to make this happen
+is not even a weekend's worth of free time, and therefore represents a
+negligible committment of resources on Debian's part, given that this
+dissassembly/integration has already been done in Ubuntu.
+
+> *If* Debian adopts systemd as an init system, I do think that it's
+> possible (how likely, I don't know) we'll end up with GNOME unavailable on
+> the kFreeBSD port because people choose not to do the effort of separating
+> out and porting the components required.  It's up to the porters, and
+> depends on what role they see for the port.  If, for example, they're
+> primarily targeting servers, this may not be a significant loss.  The
+> point is that it would be their call.
+
+Right.  I think that if we adopt systemd, GNOME will be the least of the
+kfreebsd porters' problems, because of the overarching init integration
+questions.
+
+> My belief, and again I welcome concrete reasons why I'm not correct, is
+> that adopting upstart poses a similar risk for the Hurd port as adopting
+> systemd, and I care just as much about the Hurd port as kFreeBSD.
+
+Well, certainly there is risk that no one will be interested in doing the
+work to port libnih+upstart to the Hurd.  Picking either upstart or systemd
+will not guarantee that we have porters willing to do the work to keep up.
+But I think the success of the in-progress kfreebsd port shows that upstart
+poses a much lower portability barrier than systemd; if we want non-Linux
+ports to exist on the same terms as the Linux ones (i.e., without needing
+backwards-compatibility solution for sysvinit), I think upstart does give
+them a much better fighting chance.
+
+> I want to mention again something that you'd dismissed as possibly a joke
+> earlier, but which I was actually serious about: I think a world in which
+> we use systemd on Linux and upstart on non-Linux ports, should upstart
+> prove much more portable, actually makes sense.  As I said in my other
+> writeup, I believe the systemd feature advantage is sufficient to choose
+> systemd in isolation, without the other issues discussed.  I also believe
+> that maintaining a systemd unit plus an upstart configuration is, modulo
+> testing (which I realize is a huge issue), much easier than maintaining a
+> single sysvinit script.
+
+I agree that maintaining a systemd unit plus an upstart job is better than
+maintaining an init script.  I just can't see any way through to a world
+where these will both actually be maintained (the testing problem),
+particularly if upstart use is relegated to the non-Linux ports.  It's hard
+for me to view "Ubuntu, Debian GNU, and Debian GNU/kFreeBSD use upstart; Red
+Hat, Fedora, SuSE, and Debian GNU/Linux use systemd" as anything but a loss
+for upstart.  With only non-Linux ports of Debian on upstart's side and all
+the other potential collaborators among the traditional distros opting for
+systemd, I think that would leave Canonical confronting some hard questions
+about whether to continue investing in upstart development.
+
+Earlier in the discussion, you posited that the same argument for Canonical
+deinvesting in bzr could be applied to upstart:
+
+>> bzr lost the DVCS war not because Canonical was unwilling to invest in
+>> bzr, but because git had an early lead in performance and flexibility
+>> that made it the runaway choice for developers, and by the time bzr was
+>> catching up in functionality, network effects meant it was too late.
+>> Once it became clear that bzr would not deliver on its promise of being
+>> a universal DVCS because the world had already adopted git as a de facto
+>> standard, it was reasonable for Canonical to stop investing in bzr
+>> development.
+
+> True.  However, I'll point out that a similar argument can be made for
+> systemd.
+
+My answer to this is that, as things stand today, this argument does *not*
+apply, because Debian hasn't made a choice for either systemd or upstart
+yet.  Whichever option Debian chooses, that is the option that is going to
+carry the day, because Debian does integration better, and across a wider
+range of software, than any other distro out there.  If Debian chooses
+systemd, then these integration efforts become focused on systemd, and
+systemd wins.  If Debian chooses upstart, then upstart wins.  And if Debian
+chooses upstart only for the non-Linux ports (which attract the attention of
+only a small minority of Debian developers), then systemd wins - and any
+spare cycles Ubuntu might win back by having Debian and Ubuntu in alignment
+on init systems go out the window, leaving less time to invest in upstart
+development.
+
+So I don't think I would vote "systemd on linux, upstart on non-linux" above
+"systemd, non-linux ports to figure out how to be compatible", because I
+fear that would be leading the non-Linux ports on.  I don't think it's fair
+to them to recommend upstart as a path forward when upstart's own future
+would be uncertain under such circumstances, on top of them already having
+to shoulder the burden of doing all the testing of upstart jobs that are
+used nowhere else in Debian.
+
+(As a personal aside, whichever of upstart and systemd is chosen by the TC
+as the default, I intend to wholeheartedly adopt it for my own use in
+Debian.  I love the upstart codebase, for all the same reasons that you
+found when you looked at it, but I'm not on a quixotic quest here.  If
+Debian chooses systemd, then any time I spend on debugging init system bugs
+in Debian is best spent debugging them on systemd, where it will bring the
+most benefit to our users.)
+
+Cheers,
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 04:36:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 04:36:17 GMT) (full text, mbox, link).

+ +

Message #2039 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: init system thoughts
+
Date: Tue, 31 Dec 2013 06:34:24 +0200
+
+
On Tue, 2013-12-31 at 02:55 +0000, Colin Watson wrote:
+> My main concerns with systemd relate to its broad scope regarding units
+> it provides for system initialisation tasks currently performed by other
+> packages, and the potential for that to interfere with past and future
+> work elsewhere in Debian.  I can understand why the systemd authors felt
+
+> The two examples which I've run across so far, both ones I was inclined
+> to look at since I'm familiar with the territories, are:
+> 
+>   #716812 (binfmt-support)
+
+>   #608457 (console-setup)
+
+> Basically, systemd would be more compelling to me if it tried to do
+> less.  I don't expect to persuade systemd advocates of this, as I think
+> it amounts to different basic views of the world, but the basic approach
+> here is probably the single biggest factor influencing my position.
+
+I think this is absolutely ridiculous as a "rationale" for choosing
+upstart. If you have done any investigation, you should know that it's
+trivial to disable any of those components if Debian decides it's better
+off without them. Yet you really seriously present their existence as
+the "biggest factor influencing your position"? In what kind of scenario
+could their existence possibly cause noticeable problems for Debian
+systemd use?
+
+I can imagine some kind of extrapolated arguments about "project scope
+issues" that would not be completely laughable, but you haven't really
+presented any of those. As is, what you're saying just does not form an
+argument that could be taken seriously at all.
+
+
+> The criticisms of Upstart's event model in the systemd position
+> statement simply do not make sense to me.  Events model how things
+> actually happen in reality; dependencies are artificial constructions on
+> top of them, and making them work requires the plethora of different
+> directives in systemd (e.g. Wants, which is sort of a non-depending
+> dependency) to avoid blocking the boot process on a single failing
+> service.
+
+Dependencies are the natural way to express what people know about the
+system and what they need. Events are the internal implementation
+details of what the machine does to make it happen.
+
+"I want task X started, and it needs task Y" is what people express.
+"Start Y, and when Y is ready, start X" are the "compiled"
+implementation instructions to achieve the higher-level goal.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 04:36:33 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to cameron <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 04:36:33 GMT) (full text, mbox, link).

+ +

Message #2044 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: cameron <camerontnorman@gmail.com>
+
To: Colin Watson <cjwatson@debian.org>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 04:27:16 -0008
+
+
[Message part 1 (text/plain, inline)]
+
+
+On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson <cjwatson@debian.org> 
+wrote:
+> On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
+>>  My belief, and again I welcome concrete reasons why I'm not 
+>> correct, is
+>>  that adopting upstart poses a similar risk for the Hurd port as 
+>> adopting
+>>  systemd, and I care just as much about the Hurd port as kFreeBSD.  
+>> And
+>>  while kFreeBSD is in better shape due to the already-begun upstart 
+>> port,
+>>  there are still significant porting challenges in the way of 
+>> maintaining
+>>  feature parity in the kFreeBSD port at the level that it has today. 
+>>  Many
+>>  of those challenges are going to remain regardless of which init 
+>> system we
+>>  pick.
+>> 
+> I haven't looked at this in much detail, and I suspect Dimitri hasn't
+> yet although IIRC he did express some interest in doing so.  But I
+> haven't seen anyone else try to outline the scope of a port, so let me
+> try to do so for the sake of general understanding.  As far as I know,
+> the hardest parts would be inotify, ptrace, and prctl
+> (PR_SET_CHILD_SUBREAPER).
+> 
+> inotify is used to notice changes to configuration files.  This is
+> certainly helpful for users, but it isn't critical as "initctl
+> reload-configuration" works without it.  We could probably do without
+> this with the aid of a dpkg trigger.
+> 
+
+inotify use can easily be ported to kqueue within Upstart, or 
+libinotify-kqueue can be used.
+
+> 
+> ptrace is used for "expect fork" and "expect daemon"; as I indicated 
+> in
+> another post, I think it would be preferable to avoid these in Debian
+> and quite possibly to compile them out.  (This would mean we wouldn't 
+> be
+> able to translate Ubuntu jobs quite as directly, and a number of
+> important jobs would definitely need to be changed, but the conversion
+> isn't usually particularly difficult.)
+> 
+
+If we are able to settle on a readiness protocol and fully (or almost 
+fully) implement it, then ptrace will become irrelevant. I am sure that 
+if upstream is in agreement on the proto, then Ubuntu and Debian can 
+collaborate to update the jobs (and daemons) for their next releases.
+
+> 
+> prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification 
+> work
+> properly when Upstart is supervising a user session.  This isn't a
+> required feature and could easily be compiled out until suitable 
+> kernel
+> support is available (this actually seems like the sort of thing that
+> could be done in the Hurd without too much difficulty, but I haven't
+> looked into it).  If absent, it might well impede the ability to do an
+> advanced desktop port, but it wouldn't get in the way of porting the
+> bulk of services.
+> 
+
+Unity, likely the only desktop environment using Upstart as a session 
+init, is not in Debian. The sacrifice of this functionality on 
+non-linux systems is perfectly acceptable.
+
+> 
+> There might also be odds and ends around the details of wait status
+> handling.
+> 
+
+Two things come to mind: use of epoll in upstart-socket-bridge, and no 
+abstract namespace sockets.
+
+> 
+> So, I'll certainly concede that I haven't actually tried this, but 
+> from
+> what I know of Upstart/libnih's system dependencies, I think that the
+> Hurd could be accommodated with at worst possibly some loss of
+> non-critical features.
+> 
+>>  I want to mention again something that you'd dismissed as possibly 
+>> a joke
+>>  earlier, but which I was actually serious about: I think a world in 
+>> which
+>>  we use systemd on Linux and upstart on non-Linux ports, should 
+>> upstart
+>>  prove much more portable, actually makes sense.  As I said in my 
+>> other
+>>  writeup, I believe the systemd feature advantage is sufficient to 
+>> choose
+>>  systemd in isolation, without the other issues discussed.  I also 
+>> believe
+>>  that maintaining a systemd unit plus an upstart configuration is, 
+>> modulo
+>>  testing (which I realize is a huge issue), much easier than 
+>> maintaining a
+>>  single sysvinit script.
+>> 
+> I wouldn't discard this option out of hand, but I think it would need
+> significant tool support to be practical (e.g. heuristic generation of
+> Upstart job files from systemd units), unless we expect all service
+> maintainers to have kFreeBSD/Hurd VMs lying around.  Keeping the
+> sysvinit scripts and using Upstart as the init daemon is another
+> possibility, and at least in that case the sysvinit scripts are 
+> probably
+> still lying around.  We don't even necessarily have to choose between
+> those up-front.
+> 
+Cheers,
+Cameron Norman
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 04:57:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to cameron <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 04:57:05 GMT) (full text, mbox, link).

+ +

Message #2049 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: cameron <camerontnorman@gmail.com>
+
To: Colin Watson <cjwatson@debian.org>, 727708@bugs.debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Tue, 31 Dec 2013 04:47:34 -0008
+
+
[Message part 1 (text/plain, inline)]
+
+
+On Mon, Dec 30, 2013 at 6:55 PM, Colin Watson <cjwatson@debian.org> 
+wrote:
+
+> The ptrace arrangements used for "expect fork" and "expect daemon" 
+> have
+> been rather flaky in practice, especially when Upstart jobs are 
+> written
+> by people not experts in doing so, and they are an obstacle to
+> portability.  I think we should strongly discourage use of these in
+> Debian in favour of some other readiness protocol.  My personal
+> aesthetic preference is for the "expect stop" scheme or something 
+> close
+> to it, but I really don't care that deeply and the sd_notify scheme or
+> similar would work too.  Indeed, I might well be inclined to support
+> disabling the ptrace-requiring features entirely in Debian, and 
+> working
+> to disable them in Ubuntu in time as well (although that would 
+> require a
+> transition plan).
+> 
+> 
+
+For reasons mentioned by Lennart Poettering in his G+ post, I disagree 
+that expect stop is a good scheme for a readiness protocol. Sure, it is 
+easy for the daemon and init system, but it is not extensible and can 
+be harmful when debugging a process (send it a SIGSTOP, init thinks it 
+is successful and gives it a SIGCONT). NOTIFY_SOCKET is a good scheme 
+because it is very explicit and can not be misinterpreted by the init 
+system. In addition, one init system already has implemented it :)
+
+> 
+> I think Russ has sold me on systemd's journal being a win, at least in
+> terms of how it enables much better status output for services, and 
+> it's
+> a shame that something equivalent isn't present in Upstart.  My
+> practical experience of late has been that the per-job log files you 
+> get
+> by default are good enough for most purposes where I need to debug
+> service operations, but it certainly isn't all packaged up as neatly.
+> 
+
+Now, since two people agree on this, why do we not file a bug in 
+launchpad asking for the per-job logs to be able to be shown by initctl 
+(possibly via a --show-logs option)? In fact, I just did it: 
+https://bugs.launchpad.net/upstart/+bug/1265123.
+
+(P.S. sorry for the sass, it is just so fun :)
+
+Nighty night,
+Cameron Norman
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 05:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 05:12:05 GMT) (full text, mbox, link).

+ +

Message #2054 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Mon, 30 Dec 2013 21:10:53 -0800
+
+
Steve Langasek wrote:
+> On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
+>> Please recall the context here: this whole aside started with an objection
+>> to my contention that adopting upstart requires disassembly and redoing of
+>> an integration that we would otherwise not have to disassemble.  Nowhere
+>> in my message did I say that we would or could not do that disassembly if
+>> we adopted upstart; I said that it was work that we otherwise wouldn't
+>> have to do.
+>
+>> That's the intended context of my point above: I don't think we're going
+>> to port GNOME to a non-systemd infrastructure, in the sense of carrying
+>> significant patches to GNOME to adopt it to, say, not using logind.  I
+>> think GNOME will continue to use systemd APIs heavily, which makes GNOME
+>> less portable.  That means that systems that are not capable of running
+>> those systemd components will need to either port them or develop
+>> alternatives.
+>
+>> I don't consider this wailing or gnashing of teeth, but rather a realistic
+>> look at what efforts the project is talking about committing to, as
+>> opposed to supporting people working on if they so choose.
+>
+> Ok.  I think our core point of disagreement here, then, is in our assessment
+> of how much work we think this actually is (for the Linux case, not for the
+> non-Linux case).  I think the actual package maintenance to make this happen
+> is not even a weekend's worth of free time, and therefore represents a
+> negligible committment of resources on Debian's part, given that this
+> dissassembly/integration has already been done in Ubuntu.
+
+I'm making the assumption, here, that the work you're talking about is
+making logind and other such services run without systemd, rather than
+attempting to make GNOME and other desktop environments run without
+those services.
+
+I think you're underestimating the amount of *ongoing* effort required
+here.  I'd point out that systemd in Debian is still stuck at version
+204, despite the very nice features available in 205 and newer,
+specifically because logind dared to make use of those features.  I
+fully expect systemd to continue producing new and interesting features
+and *using* them, requiring alternative implementations to either
+reimplement more of systemd or create an increasingly invasive fork of
+it.  And while I think it's *possible* to continue doing so on an
+ongoing basis, that's work that could be spent on other productive tasks
+that don't involve reimplementation.
+
+In any case, I sincerely hope that the cost of doing that work is borne
+entirely by people who find it a worthwhile activity rather than a
+monumental waste of time.  And I furthermore hope that an unmangled and
+unforked version of systemd continues to be available in Debian for
+folks who want to run the init system that continues to create
+functionality so useful that the proponents of upstart are willing to do
+a huge amount of work in order to adopt most of it other than the init
+system itself.
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 05:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 05:33:04 GMT) (full text, mbox, link).

+ +

Message #2059 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Mon, 30 Dec 2013 21:30:56 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 30, 2013 at 07:26:23PM -0800, Russ Allbery wrote:
+> > (Now, I've been working with Upstart's model for years, and it's now a
+> > pretty fundamental way of how I think of system operation; so if people
+> > who are new to *both* models rather than partisans of one side or the
+> > other consistently tell me that the systemd model is easier to grasp,
+> > then I'll listen.)
+
+> I am new to both models.  I'm not very fond of the upstart model.
+
+> Lennart had a comment on this point that I thought phrased the problem in
+> an interesting way: both systemd and upstart deal with the same data, but
+> with systemd, the full dependency tree is precalculated and exists as
+> state within the init system.  With upstart, behavior is dynamic and to
+> some degree emergent: you know who is listening to what signals, but you
+> can arbitrarily introduce signals, and you're dealing with a message bus
+> rather than a dependency tree, so you're reacting to things as they happen
+> on the bus.  In systemd, you can dump everything that can possibly happen
+> and work through the state transitions by hand if needed, with the
+> possible exception of unexpected device events (which are horribly
+> important in some cases -- don't get me wrong -- but which are
+> uninteresting in a lot of common debugging scenarios).  I think it's
+> somewhat harder to do that with upstart, where events are generated more
+> dynamically.
+
+So for a concrete example of where I think upstart's model lets us get
+things right at boot that systemd's dependency model does not (or at least,
+this hasn't been done yet in Debian), I'd like to direct your attention to
+/etc/network/if-up.d/upstart .  Conceptually, there are certain kinds of
+services in a distro context that we don't want to start by default until
+"the network" is up - because they aren't set up for socket-based
+activation, or might need to bind to particular addresses/interfaces and not
+fall back gracefully, etc.  Of course if we were writing all our services
+according to best practices, we wouldn't have to worry about this, as the
+service would just handle this gracefully (or maybe hand the complexity off
+to the init system for socket-based activation - but then what does init do
+with a request for a socket address that's not available? cycles within
+cycles, etc).
+
+But in the real world, we have a lot of services that we just want to start
+in runlevel 2 and be able to trust that the network and disk are sorted.
+This is the classic guarantee that sysvinit gave us pre-udev, but it's
+fallen apart since then because a fast system can get all the way through
+rcS before the kernel has even managed to enumerate all the network devices.
+
+Upstart (as implemented in Ubuntu) restores this guarantee (with provisions
+for failsafe booting in the case of a wrong network config), and it takes
+advantage of upstart's capability of sending arbitrary signals to do so.  I
+can see how one could implement the equivalent of upstart's
+static-network-up event on systemd, using generators.  But what would the
+equivalent to /etc/init/failsafe.conf look like?  I think this would be
+very difficult to express in systemd language, yet it's altogether vital for
+providing a boot that is both reliably ordered, and recoverable in the event
+of problems.
+
+Cheers,
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 05:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 05:57:04 GMT) (full text, mbox, link).

+ +

Message #2064 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Mon, 30 Dec 2013 21:52:04 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> Upstart (as implemented in Ubuntu) restores this guarantee (with
+> provisions for failsafe booting in the case of a wrong network config),
+> and it takes advantage of upstart's capability of sending arbitrary
+> signals to do so.  I can see how one could implement the equivalent of
+> upstart's static-network-up event on systemd, using generators.  But
+> what would the equivalent to /etc/init/failsafe.conf look like?  I think
+> this would be very difficult to express in systemd language, yet it's
+> altogether vital for providing a boot that is both reliably ordered, and
+> recoverable in the event of problems.
+
+I'm not sure I completely understand what failsafe.conf actually does, but
+I think the systemd answer to this is partly discussed here:
+
+    http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
+
+A systemd integration in Debian may want to implement something akin to
+upstart's if-up.d hook as a service that waits for ifup notification with
+a timeout and then signals network.service to duplicate that upstart
+functionality.  (I'm not sure I completely understand all of the issues
+involved and whether that would always make sense.)
+
+When using NetworkManager, as mentioned in that discussion, you may want
+to enable NetworkManager-wait-online.service instead or in addition.  That
+has a failsafe to not wait too long for network before continuing the
+boot, including network-dependent services, anyway.
+
+So, in other words, assuming that I understand this correctly, the way
+that you implement this in systemd is that you add a Before= dependency to
+the network.target (hm, which implies that my assumption about things
+meddling with dependencies of core services being less likely is not as
+correct as I thought it was, although I still think it's less likely to be
+done by accident) that waits for the network to be configured, but
+implements a timeout to ensure that you don't stall forever.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 06:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 06:06:04 GMT) (full text, mbox, link).

+ +

Message #2069 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Mon, 30 Dec 2013 22:04:09 -0800
+
+
Oh, sorry, I forgot to respond to this part.
+
+Steve Langasek <vorlon@debian.org> writes:
+
+> Of course if we were writing all our services according to best
+> practices, we wouldn't have to worry about this, as the service would
+> just handle this gracefully (or maybe hand the complexity off to the
+> init system for socket-based activation - but then what does init do
+> with a request for a socket address that's not available?
+
+This is what IP_FREEBIND is for, which is why it needs to be supported by
+the socket activation configuration.  It's been considered best practice
+for some time for IPv6 services binding to particular configured IP
+addresses to use IP_FREEBIND because IPv6 network setup can take an
+unpredictable amount of time.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 06:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 06:30:05 GMT) (full text, mbox, link).

+ +

Message #2074 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Mon, 30 Dec 2013 22:26:59 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 30, 2013 at 10:04:09PM -0800, Russ Allbery wrote:
+> Oh, sorry, I forgot to respond to this part.
+
+> Steve Langasek <vorlon@debian.org> writes:
+
+> > Of course if we were writing all our services according to best
+> > practices, we wouldn't have to worry about this, as the service would
+> > just handle this gracefully (or maybe hand the complexity off to the
+> > init system for socket-based activation - but then what does init do
+> > with a request for a socket address that's not available?
+
+> This is what IP_FREEBIND is for, which is why it needs to be supported by
+> the socket activation configuration.  It's been considered best practice
+> for some time for IPv6 services binding to particular configured IP
+> addresses to use IP_FREEBIND because IPv6 network setup can take an
+> unpredictable amount of time.
+
+Ah, thanks for the pointer.  I saw your previous mention of IP_FREEBIND but
+hadn't looked it up yet - that certainly does sound like an important
+feature to take advantage of in socket activation.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 07:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 07:15:04 GMT) (full text, mbox, link).

+ +

Message #2079 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Mon, 30 Dec 2013 23:12:04 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+> On Sun, Dec 29, 2013 at 01:43:59PM -0800, Nikolaus Rath wrote:
+>> I'm a bit surprised that you mention this only now, after Russ'
+>> extensive mail. Could you tell us if there are there other components in
+>> systemd that you think are similarly flawed,
+>
+> Why should it have been mentioned before now?
+
+Socket activation seems to be considered one of the major new features
+that systemd brings to the table. You seem to think it's fundamentally
+flawed, and you're the maintainer of the upstart position statement, so
+I would have expected it to be mentioned there as an important point to
+be taken into account when making the decision.
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 08:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 08:39:04 GMT) (full text, mbox, link).

+ +

Message #2084 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Tue, 31 Dec 2013 09:36:54 +0100
+
+
]] Steve Langasek 
+
+> > In any case, systemd does indeed "support" this case; simply make your
+> > service depend on network-online.target, which will block for a
+> > reasonable amount of time to see if a network interface comes online,
+> > and eventually time out if that doesn't occur.  This will actually work
+> > even if your primary network is a wireless network managed by
+> > NetworkManager, and even if that network doesn't actually work until the
+> > user has logged in, assuming your service is not actually in the
+> > dependency path of the user logging in.
+> 
+> And what makes this work in the case where you *aren't* using
+> NetworkManager?  I see no integration with ifupdown in the systemd package.
+
+There is none, and it would not be ifupdown-specific.  We could easily
+enough add a «wait for a default ipv4 and ipv6 default route to appear»
+unit if somebody desired that, which would be pulled in by
+network-online.target.  It's a pretty trivial piece of code.
+
+Alternatively, just put systemctl start network-online.target into a
+fragment in if-up.d if you consider ifup considering a network interface
+up to be enough.  (I don't, but as pointed out on the systemd wiki page
+referenced, people have different ideas about what «network online»
+means.)
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 08:42:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 08:42:08 GMT) (full text, mbox, link).

+ +

Message #2089 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: 727708@bugs.debian.org
+
Cc: 726763@bugs.debian.org, 729576@bugs.debian.org, + systemd@packages.debian.org
+
Subject: Re: Bug#727708: systemd-shim uploaded to NEW
+
Date: Tue, 31 Dec 2013 00:38:49 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 30, 2013 at 09:52:37PM +0100, Tollef Fog Heen wrote:
+> ]] Ian Jackson 
+
+> > Steve Langasek writes ("Bug#727708: systemd-shim uploaded to NEW"):
+> > > So I repeat here my request that the systemd maintainers make a suitable
+> > > split of the systemd binary package, so that systemd-shim will be
+> > > coinstallable with the systemd-provided implementations of the other dbus
+> > > services.
+
+> > Is there a summary of the systemd maintainers' response to this
+> > request ?  I glanced #726763 and #729576 but they were very long and
+> > if the answer is in there I probably wouldn't have found it.
+
+> I see no point in doing that, in particular not in the middle of when
+> the ctte is choosing a new default init system.  If anything, I think
+> it's pretty rude of Steve to upload systemd-shim and asking the systemd
+> maintainers to solve the problem for him.
+
+Conversely, I think it's rude of everyone involved in having created this
+bug to be pointing fingers at each other and disclaiming all responsibility
+for fixing it, while in the meantime users of unstable are being left with
+silently broken desktops on upgrades.  Even if Debian ultimately decides for
+systemd, that doesn't do the least bit of good for users who suddenly find
+suspend not working on their systems right now.
+
+> > >  The only alternative I see is for systemd-shim to declare a
+> > > Replaces: against systemd without a Conflicts,
+
+> > This would be quite wrong; Replaces is not supposed to be used like
+> > that (but you apparently know that).
+
+> > How do the systemd maintainers think this problem should be solved ?
+
+> Initially, by waiting for the ctte to come to a conclusion.  If that is
+> that systemd should be the default init system I think we should solve
+> the problem by not solving it.  If the decision is that another init
+> system should be solved, I'm probably going to solve it by removing the
+> init functionality from the systemd package at which point the bug
+> solves itself, AIUI.
+
+> If the systemd-shim maintainers want to solve it in the meantime, going
+> with Raphael's suggestion seems reasonable enough.
+
+So given that dpkg-divert can't be used for the conffile, is this still your
+position?  This means that divert+Replaces is the only other option, which
+will result in the conffile being removed if systemd-shim is installed and
+then purged.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 08:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to cameron <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 08:45:04 GMT) (full text, mbox, link).

+ +

Message #2094 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: cameron <camerontnorman@gmail.com>
+
To: Colin Watson <cjwatson@debian.org>, 727708@bugs.debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Tue, 31 Dec 2013 08:34:39 -0008
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 30, 2013 at 6:55 PM, Colin Watson <cjwatson@debian.org> 
+wrote:
+
+> The criticisms of Upstart's event model in the systemd position
+> statement simply do not make sense to me.  Events model how things
+> actually happen in reality; dependencies are artificial constructions 
+> on
+> top of them, and making them work requires the plethora of different
+> directives in systemd (e.g. Wants, which is sort of a non-depending
+> dependency) to avoid blocking the boot process on a single failing
+> service.  Yes, there are some bugs possible in the Upstart design, 
+> but I
+> don't agree that those are world-ending fundamental issues and I think
+> they're generally incrementally fixable.  The systemd design appears 
+> to
+> me to expose far more complexity to the user writing unit files, and I
+> think it's important that their mental model be as straightforward as
+> possible.
+> 
+> (Now, I've been working with Upstart's model for years, and it's now a
+> pretty fundamental way of how I think of system operation; so if 
+> people
+> who are new to *both* models rather than partisans of one side or the
+> other consistently tell me that the systemd model is easier to grasp,
+> then I'll listen.)
+> 
+
+I would like to give my view of the event vs. dependency model. I will 
+declare my conclusion up front: Upstart's event model is, in my 
+opinion, more flexible, and much more compatible with socket activation 
+than systemd's dependency model (which is ironic, since Upstart does 
+not stress socket activation, and systemd does).
+
+I will start with an example including syslog, dbus, and 
+NetworkManager. One way a distribution developer would write these job 
+files is by saying "start on syslog-started" and "stop on 
+syslog-stopped" for dbus. Although this may seem like the obvious way 
+to write the job, it is not the most efficient. This is what I will 
+call an "always on" job. Whenever it is possible for this job to be on 
+(its dependencies have started, and the job is enabled) it will be on. 
+This can cause slow boot, because a ton of jobs are being started that 
+do not need to be. This is the fault of //the distribution developer//, 
+not Upstart itself. Now, lets imagine this developer stopped for a 
+second to think before denouncing Upstart as inefficient crap. He knows 
+that his dbus job was probably not efficient, and he wants to try to 
+make a more efficient NetworkManager job. So, the developer crafts a
+
+start on dbus-started and /* dbus signal received */
+stop on dbus-stopped or /* dbus signal not received */
+
+So this is cool. NetworkManager is started not simply when it is able 
+to start, but also when it needs to start. It stops when dbus stops 
+(its dependencies are unavailable) or when it is not needed by anyone. 
+What is great about Upstart's model is its flexibility. Example:
+
+start on dbus-started and /* dbus address accessed */
+stop on dbus-stopped
+
+This starts NetworkManager when its services are required, but then 
+keeps it running even after they are not, until it can no longer 
+provide its services. This may be desirable in some situations (maybe 
+starting and stopping nm a lot is unwanted), and shows how this event 
+model puts more control in the job, rather than a config file. Now lets 
+say that developer realizes how powerful the event model is, and goes 
+back to reimplement his dbus job. He/she wants dbus to be running only 
+when its services are needed.
+
+start on syslog-started and /* socket event aimed at dbus */
+stop on syslog-started or /* no socket events toward dbus */
+
+Now, this changes things around, and the NetworkManager job needs to 
+modified to not wait for dbus to start, but just access the socket and 
+let Upstart automatically start dbus following that event.
+
+start on dbus SIGNAL=....
+stop on dbus-stopped
+
+I think this usage of Upstart's event model is incredibly superb, and 
+much more understandable and usable than systemd's socket and bus 
+activation model. Although systemd's declarative syntax is simple, I 
+think it offers too little flexibility and does not reflect the 
+realities of the system to the unit, which makes the declarative syntax 
+an abstraction that needs to be understood by the admin, or it will be 
+misused. Furthermore, with a little work put into Upstart's socket 
+event bridge and socket handling (which should not be a problem since 
+the infrastructure is already there), the boot time speed ups and 
+socket based activation model of systemd can be achieved with only a 
+little effort, and considerably more flexibility.
+
+Good night,
+Cameron Norman
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 09:21:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 09:21:12 GMT) (full text, mbox, link).

+ +

Message #2099 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: debian-ctte@lists.debian.org, 727708@bugs.debian.org, + 726763@bugs.debian.org, 729576@bugs.debian.org
+
Subject: Re: Bug#727708: systemd-shim uploaded to NEW
+
Date: Tue, 31 Dec 2013 01:16:32 -0800
+
+
Steve Langasek wrote:
+> Looking more closely, I find that one of the conflicting files is a conffile
+> (/etc/dbus-1/system.d/org.freedesktop.systemd1.conf).  diversions and
+> conffiles still don't mix, AFAIK (and according to current policy).  So that
+> seems to still leave us without a proper solution that doesn't involve
+> splitting the systemd binary package.
+
+Files in /etc/dbus-1/system.d/ need not have names that match the
+interface they control; see, for instance, gdm.conf or
+nm-dhcp-client.conf.  Why not simply install a systemd-shim.conf with
+the contents you need?  To the best of my knowledge, I see nothing in
+org.freedesktop.systemd1.conf that should interfere with you.
+
+(That said, personally I'd prefer to see systemd-shim continue to
+conflict with systemd, and work with a hypothetical
+forked-systemd-logind package instead, which would also conflict with
+systemd.  That would then, for instance, unblock systemd's ability to
+upgrade past version 204.)
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 12:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Simon McVittie <smcv@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 12:00:05 GMT) (full text, mbox, link).

+ +

Message #2104 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Simon McVittie <smcv@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Tue, 31 Dec 2013 11:57:15 +0000
+
+
On Sat, 28 Dec 2013 at 16:45:38 -0800, Russ Allbery wrote:
+> The second supported option is DAEMON_OPTS, which sets additional flags to
+> add to the process.  For as long as we need to support multiple init
+> systems, this option needs to stay in /etc/default/lbcd and be read from
+> there by all supported init systems so that configuration is preserved as
+> the user moves between init systems.
+
+I'd like to suggest that this should only be done for daemons where there
+is anything that a sysadmin can sensibly configure in this way. The patch
+proposed for #712167 (native Upstart init support in dbus) did this, but
+after checking the available command-line options in dbus-daemon, I couldn't
+actually find any command-line options that can be changed by a sysadmin
+without breaking system integration; so I think it's OK that the systemd
+unit doesn't read /etc/default/dbus, and I don't think the (potential future)
+Upstart job should either.
+
+If dbus-daemon had command-line options that made sense as local configuration,
+then reading /etc/default/dbus would be fine, but I've tried to avoid that
+in favour of having anything locally-configurable only be available in the
+(XML) configuration files, and not on the command-line: see
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712167#20 for more on
+command-line options vs. configuration.
+
+(Perhaps this means /etc/init.d/dbus should stop reading /etc/default/dbus...)
+
+    S
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 12:06:08 GMT) (full text, mbox, link).

+ +

Message #2107 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Jakub Wilk <jwilk@debian.org>
+
To: 727708@bugs.debian.org
+
Cc: 726763@bugs.debian.org, 729576@bugs.debian.org, + systemd@packages.debian.org
+
Subject: Re: Bug#727708: systemd-shim uploaded to NEW
+
Date: Tue, 31 Dec 2013 13:02:49 +0100
+
+
* Raphael Hertzog <hertzog@debian.org>, 2013-12-30, 19:42:
+>dpkg-divert is the usual answer when you need/want to replace something 
+>without the consent of the other side.
+
+FWIW, Policy §3.9 reads: 
+“You should not use ‘dpkg-divert’ on a file belonging to another package 
+without consulting the maintainer of that package first.”
+
+-- 
+Jakub Wilk
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 14:30:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Dmitry Yu Okunev <dyokunev@ut.mephi.ru>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 14:30:09 GMT) (full text, mbox, link).

+ +

Message #2112 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Dmitry Yu Okunev <dyokunev@ut.mephi.ru>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 18:19:36 +0400
+
+
[Message part 1 (text/plain, inline)]
+
Hello.
+
+I'm writing to you to request to do not use no systemd, nor upstart.
+
+I can guess that you have very important reasons to discuss this
+possibilities, but…
+
+IMHO, "systemd" doesn't even fit to UNIX philosophy [1].
+
+ [1] http://en.wikipedia.org/wiki/Unix_philosophy
+
+Sorry if I'm wrong.
+
+"upstart" is more satisfactorily. I have a lot of problems with it in
+LXC and other tasks*. So, I can work with "upstart", but would prefer
+not to do that. I didn't try "systemd" in LXC, but I can guess that I'll
+catch much more problems with it.
+
+ * I don't rule out the likelihood of that my hands were too curves.
+
+Also, I can also guess, that my opinion doesn't worth anything here. But
+at the moment the best Linux (meta-)distributions for me (and under my
+tasks) is Debian and Gentoo. With moving to "systemd" you will force me
+to choose another distribution as replacement for Debian.
+
+Please, don't do that.
+
+
+P.S.: It would be great to see "OpenRC" as default init-system for Debian :)
+
+-- 
+Best regards, Dmitry,
+head of UNIX-tech department NRNU MEPhI,
+tel. 8 (495) 788-56-99, add. 8255
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 16:45:20 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 16:45:20 GMT) (full text, mbox, link).

+ +

Message #2117 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Simon McVittie <smcv@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Tue, 31 Dec 2013 08:44:15 -0800
+
+
Simon McVittie <smcv@debian.org> writes:
+> On Sat, 28 Dec 2013 at 16:45:38 -0800, Russ Allbery wrote:
+
+>> The second supported option is DAEMON_OPTS, which sets additional flags
+>> to add to the process.  For as long as we need to support multiple init
+>> systems, this option needs to stay in /etc/default/lbcd and be read
+>> from there by all supported init systems so that configuration is
+>> preserved as the user moves between init systems.
+
+> I'd like to suggest that this should only be done for daemons where
+> there is anything that a sysadmin can sensibly configure in this
+> way. The patch proposed for #712167 (native Upstart init support in
+> dbus) did this, but after checking the available command-line options in
+> dbus-daemon, I couldn't actually find any command-line options that can
+> be changed by a sysadmin without breaking system integration; so I think
+> it's OK that the systemd unit doesn't read /etc/default/dbus, and I
+> don't think the (potential future) Upstart job should either.
+
+I would argue....
+
+> (Perhaps this means /etc/init.d/dbus should stop reading /etc/default/dbus...)
+
+...this.  If /etc/default is not useful, then it's not useful for the
+sysvinit support either, and it seems better to just drop it in all
+supported init systems rather than have it be inconsistent.  Either way,
+you'd need a NEWS entry, etc., so that seems cleaner to me.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 16:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 16:51:04 GMT) (full text, mbox, link).

+ +

Message #2122 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Tue, 31 Dec 2013 16:47:49 +0000
+
+
Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> >  - avoid extra build-dependencies (eg on libsystemd)
+> >  - avoid extra runtime dependencies (eg on deb-systemd-helper)
+> 
+> These requirements, on the other hand, I find completely baffling.
+>
+> This approach seems completely contrary to Debian best practices.  Our
+> standard practice with all packages is to fully enable all available
+> features that make sense on Debian and don't pose some concrete risk.
+
+The case in point is a little different.  It's one thing to say that
+mail daemons should come with ldap support enabled, or whatever (and
+even then we sometimes have two versions e.g. "heavy" and "light").
+
+For me it's a different proposition to suppose that _every_ daemon
+should bring in these kind of dependencies.  This is particularly the
+case for build-dependencies on an avowedly and intentionally
+non-portable program.  Of course this can be made conditional, but
+this is IMO too fiddly.
+
+> > We should recommend:
+> >  - daemon authors and Debian maintainers should prefer command-line
+> >    options to environment variables
+> 
+> I disagree with including this in a statement.  I think it's outside the
+> scope of what we were asked to resolve, and I don't think it's the place
+> of the TC to offer this sort of general advise to upstreams.
+
+It is very likely that Debian contributors will be implementing native
+support for whatever readiness protocol, in the upstream parts of the
+codebase.  It is IMO appropriate for those contributors to get advice
+on how to do this.  Policy already gives advice on this kind of
+thing.  Given the context, and the fact that this advice is going to
+be read by a lot of people as part of a big enhancement project, I
+think it's appropriate for the TC to answer this question.
+
+> If we're going to offer specific advice, we should limit it to the
+> specific integrations that we're asked to consider.  But I think we should
+> be mindful of the restriction on the TC not doing design work and let
+> Policy for packaging support of upstart and/or systemd be hashed out
+> through the regular Policy process.
+
+Are you proposing then that the TC should decide the default init
+system, but asmk people NOT to start converting packages until the
+policy questions are settled ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 16:54:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 16:54:12 GMT) (full text, mbox, link).

+ +

Message #2127 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve Langasek <vorlon@debian.org>, + 727708@bugs.debian.org
+
Cc: 726763@bugs.debian.org, + 729576@bugs.debian.org, + systemd@packages.debian.org
+
Subject: Re: Bug#727708: systemd-shim uploaded to NEW
+
Date: Tue, 31 Dec 2013 16:50:43 +0000
+
+
Steve Langasek writes ("Bug#727708: systemd-shim uploaded to NEW"):
+> On Mon, Dec 30, 2013 at 06:29:10PM +0000, Ian Jackson wrote:
+> > This would be quite wrong; Replaces is not supposed to be used like
+> > that (but you apparently know that).
+> 
+> Yes.  Raphaël rightly points out that dpkg-divert can be used for this; if
+> necessary, that's what I'll do.
+
+Right.  I think it would be best if you did that for now.  I'm right
+in thinking that that would get you (and non-systemd-users) unblocked ?
+
+> But I still think the right thing here is for the systemd package to be
+> split.
+
+I agree, but I think it would be best to postpone the resolution of
+this dispute until after the main conclusions in this TC thread.
+
+(One argument for delaying is that if the TC decides that systemd is
+not only default, but mandatory, for jessie, this becomes irrelevant.)
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 17:03:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 17:03:09 GMT) (full text, mbox, link).

+ +

Message #2132 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: intrigeri <intrigeri@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 16:58:17 +0000
+
+
intrigeri writes ("Bug#727708: init system other points, and conclusion"):
+> (Sorry if I am duplicating a point that was already made.
+> These threads are huge, and don't fit entirely into my memory.)
+
+That's fine, of course.
+
+> Ian Jackson wrote (30 Dec 2013 18:58:37 GMT) :
+> > Unless you are proposing to make systemd mandatory for all Debian
+> > installations, this is work that needs to be done anyway.
+> 
+> "Needs to be done anyway", possibly, but I find it important to make
+> it clear that, depending on what decision is made, it affects the
+> project as a whole, and many of its members, in very different ways:
+> 
+> * In one case (upstart is chosen as the default init system), we, as
+>   a project, are committed to do this work, at the very least because
+>   Policy mandates it, and we want to release without too many
+>   RC-buggy packages.
+
+I think you have misunderstood.  Or perhaps I hae misunderstood you.
+The "work" that I'm saying needs to be done anyway is the work to
+disentange the parts of systemd which are required by (say) GNOME from
+the parts which are only relevant for systemd as init.
+
+This is work that would have to be done by the systemd maintainers in
+Debian.
+
+> The difference lies in who are the people who "need" to do this work
+> "anyway", and who else may instead dedicate their time to other tasks,
+> lead by their own desires and needs.
+
+I think that it is right that the costs of undoing systemd's bundling,
+be borne by the systemd community (including systemd's advocates and
+maintainers in Debian) rather than by Debian (or the rest of the Free
+Software world) at large.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 17:24:18 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 17:24:18 GMT) (full text, mbox, link).

+ +

Message #2137 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Tue, 31 Dec 2013 09:20:11 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
+
+>> These requirements, on the other hand, I find completely baffling.
+
+>> This approach seems completely contrary to Debian best practices.  Our
+>> standard practice with all packages is to fully enable all available
+>> features that make sense on Debian and don't pose some concrete risk.
+
+> The case in point is a little different.  It's one thing to say that
+> mail daemons should come with ldap support enabled, or whatever (and
+> even then we sometimes have two versions e.g. "heavy" and "light").
+
+I'm aware of only one case of that in the archive.  It's certainly not
+what we normally do.
+
+> For me it's a different proposition to suppose that _every_ daemon
+> should bring in these kind of dependencies.
+
+It's only going to be *every* daemon if we select systemd as the default
+init system, in which case we should be doing this in many daemons for
+either socket activation or for readiness notification as part of a proper
+systemd integration.  If we do not select systemd as the default init
+system, the only maintainers doing this will be those who want their
+packages to work well with systemd or whose daemons are of particular
+interest to people who want to run systemd as a non-default init system.
+In which case, what's the harm?  It's going to be very difficult to even
+notice this dependency is there.
+
+I think the position you're taking here is directly contrary to Debian's
+position of deference and reasonable accomodation to things that people
+want to work on.
+
+> This is particularly the case for build-dependencies on an avowedly and
+> intentionally non-portable program.  Of course this can be made
+> conditional, but this is IMO too fiddly.
+
+Adding [linux-any] to the Build-Depends line is not too fiddly, and if the
+goal is to enable optional upstream support for systemd, that will be
+sufficient.  Besides, in general, it's up to the packager to decide what
+is or is not too fiddly in how they want to package software.
+
+Obviously, we should not add an unconditional build dependency for a
+library that isn't available on some of our ports to software that can
+work on those ports.  But I think that's obvious.  I'm happy to have us
+say that explicitly if if helps.
+
+>>> We should recommend:
+>>>  - daemon authors and Debian maintainers should prefer command-line
+>>>    options to environment variables
+
+>> I disagree with including this in a statement.  I think it's outside
+>> the scope of what we were asked to resolve, and I don't think it's the
+>> place of the TC to offer this sort of general advise to upstreams.
+
+> It is very likely that Debian contributors will be implementing native
+> support for whatever readiness protocol, in the upstream parts of the
+> codebase.  It is IMO appropriate for those contributors to get advice on
+> how to do this.  Policy already gives advice on this kind of thing.
+> Given the context, and the fact that this advice is going to be read by
+> a lot of people as part of a big enhancement project, I think it's
+> appropriate for the TC to answer this question.
+
+If you feel like Policy should give advice on this, you can bring it up in
+the context of Policy.  I don't think the exact mechanism of integration
+is important enough for the TC to explicitly favor a particular mechanism,
+and different upstreams may have different approaches.  I'm not seeing the
+important gain to Debian here in trying to standardize exactly how one
+tells a daemon to use socket activation or readiness notification.
+
+I also, for what it's worth, directly disagree with this advice with
+respect to systemd because I think compatibility with how systemd is used
+elsewhere is more important than any marginal gain from using a
+configuration method that's not inherited by subprocesses by default,
+particularly given that the standard systemd APIs include environment
+sanitizing.  But I also don't see any point in arguing about it here,
+since I don't think this dispute is ripe (in the legal sense).
+
+If you do bring it up in the context of Policy and we can't resolve the
+debate there, it can get appealed to the TC and we can decide it here
+separately, but I think this is all premature, given that the whole point
+becomes basically moot if we don't pick systemd anyway.
+
+If you're worried about programs configured with environment variables in
+the archive, you've got quite a lot of work to do, starting with nearly
+every Perl program in existence.
+
+>> If we're going to offer specific advice, we should limit it to the
+>> specific integrations that we're asked to consider.  But I think we
+>> should be mindful of the restriction on the TC not doing design work
+>> and let Policy for packaging support of upstart and/or systemd be
+>> hashed out through the regular Policy process.
+
+> Are you proposing then that the TC should decide the default init
+> system, but asmk people NOT to start converting packages until the
+> policy questions are settled ?
+
+Sure.  I think that's what's going to happen anyway.  Again, it's not the
+place of the TC (explicitly, per the constitution) to do design.  Once we
+decide on a direction, we should let the rest of the project work out the
+details using our normal procedures.  We have a fair bit of time left
+before the jessie release, and I expect integration policy to be fairly
+well-resolved by the end of February using our normal process.  And even
+if it's not, given that we need to support sysvinit for jessie anyway, I
+expect most packages will not be in a rush to convert.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 17:24:21 GMT) (full text, mbox, link).

+ +

Message #2140 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 18:21:15 +0100
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> intrigeri writes ("Bug#727708: init system other points, and conclusion"):
+>> The difference lies in who are the people who "need" to do this work
+>> "anyway", and who else may instead dedicate their time to other tasks,
+>> lead by their own desires and needs.
+>
+> I think that it is right that the costs of undoing systemd's bundling,
+> be borne by the systemd community (including systemd's advocates and
+> maintainers in Debian) rather than by Debian (or the rest of the Free
+> Software world) at large.
+
+What about the cgroup management functionality that newer versions of
+logind require? Should the systemd maintainers also reimplement it in
+upstart?
+
+And if upstart wants to use parts of systemd, why shouldn't the upstart
+maintainer do the work for this? Or they could fork logind which they
+suggested before... This would also allow having a newer systemd in
+Debian.
+
+Ansgar
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 17:24:31 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 17:24:31 GMT) (full text, mbox, link).

+ +

Message #2145 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Michael Gilbert <mgilbert@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Tue, 31 Dec 2013 17:23:18 +0000
+
+
Michael Gilbert writes ("Bug#727708: loose ends for init system decision"):
+> On Mon, Dec 30, 2013 at 7:16 PM, Vincent Bernat wrote:
+> > Unfortunately, being the best init is the not only the matter of its
+> > maintainers. A good integration implies to modify some packages whose
+> > maintainer may be hostile to some init and may consider that their
+> > package work well enough to not enable some feature needed by some init.
+> 
+> That is a hypothetical, of course, but it is a very real possibility
+> for any path that the TC decides here.  However, selectable inits may
+> (possibly counter-intuitively) reduce this likely-hood.  Since that
+> maintainer in the way also gets his init of choice, he may be less
+> likely to oppose an alternative that doesn't in any real sense get in
+> his way.
+> 
+> However, if/when this does happen, it will be an interesting test of
+> whether the TC has the political will to override an indignant
+> maintainer with their 3-to-1 majority power.
+
+This is why I think the TC resolution should explain what kinds of
+integration package maintainers shuuld accept.  Maintainers who flout
+that advice will indeed get overruled.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 18:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 18:33:04 GMT) (full text, mbox, link).

+ +

Message #2150 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Tue, 31 Dec 2013 18:30:33 +0000
+
+
Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > For me it's a different proposition to suppose that _every_ daemon
+> > should bring in these kind of dependencies.
+> 
+> It's only going to be *every* daemon if we select systemd as the default
+> init system, in which case we should be doing this in many daemons for
+> either socket activation or for readiness notification as part of a proper
+> systemd integration.  [...]
+
+Well, no.  I think that even if we select upstart as the default, we
+should enable the systemd community to provide as complete a set of
+integration in Debian as they care to put the work in for.
+
+That translates directly to an expectation that the maintainer of any
+daemon package must be willing to accept reasonable systemd
+integration patches.
+
+If the systemd community is very dynamic (and certainly we can't fault
+their dynamism so far) this may well translate to all or almost all
+daemons.  Certainly it could be expected to include most of the core
+daemons where the extra dependencies are most troublesome.
+
+So I think we need to say what we regard as "reasonable" patches, in
+advance.  As the Debian maintainer for uservd (for example), am I
+entitled to decline to incorporate systemd integration into my package
+on the grounds that the patch involves additional build- and runtime
+dependencies which I consider undesirable ?
+
+I don't consider it desirable to answer this question differently for
+different daemons.  We need to set out a clear rule for maintainers to
+follow or we'll end up adjudicating a gazillion individual disputes.
+
+And if the answer to this question is, in general, "the maintainer
+must include the patch" then the logical conclusion is that it is OK
+for every daemon in Debian to acquire these additional build- and
+runtime dependencies.  We would be telling non-Linux ports that they
+need to arrange for these dependencies to be somehow provided despite
+the lack of systemd on their architecture, or to have conditional
+compilation of the systemd support in every daemon package.
+
+If the TC's answer is "the maintainer may reject the patch", we would
+be telling the systemd community that they need to improve and
+simplify their integration.
+
+I think the latter is the right approach, for two reasons.  Firstly,
+it is less work overall.  Secondly, it is proper that the maintainers
+of an init system should be encouraged to provide as simple and
+nonintrusive an integration interface as possible.
+
+> > This is particularly the case for build-dependencies on an avowedly and
+> > intentionally non-portable program.  Of course this can be made
+> > conditional, but this is IMO too fiddly.
+> 
+> Adding [linux-any] to the Build-Depends line is not too fiddly, and if the
+> goal is to enable optional upstream support for systemd, that will be
+> sufficient.  Besides, in general, it's up to the packager to decide what
+> is or is not too fiddly in how they want to package software.
+
+Adding [linux-any] to the Build-Depends is not sufficient.
+
+It is also necessary to make the actual source code conditionally use
+sd_notify, using #ifdefs or other similar techniques.  The conditional
+compilation will have to be automated (perhaps with autoconf if the
+package has it - an then we need new --with[out]-systemd configuration
+options to avoid miscompilation; or perhaps in an ad hoc way if the
+daemon doesn't use autoconf).  The fact that the systemd-specific
+command line option may or may not be compiled in needs to be
+mentioned in the documentation, along with text which allows the user
+to know whether it's included in the version they actually have.
+
+This turns what could be a simple change into a multi-part epic
+involving all of the components of the package: primary source code,
+upstream build system and portability layer, Debian build system,
+documentation, and so on.
+
+And it might come about later that someone provides a portable
+sd_notify so half (but just the right half) of the above would have to
+be undone.
+
+> Obviously, we should not add an unconditional build dependency for a
+> library that isn't available on some of our ports to software that can
+> work on those ports.  But I think that's obvious.  I'm happy to have us
+> say that explicitly if if helps.
+
+I think maintainers should not be required to introduce the additional
+build- and runtime dependencies, if they do not wish to.  Obviously if
+they want to then that's fine by me.
+
+> > It is very likely that Debian contributors will be implementing native
+> > support for whatever readiness protocol, in the upstream parts of the
+> > codebase.  It is IMO appropriate for those contributors to get advice on
+> > how to do this.  Policy already gives advice on this kind of thing.
+> > Given the context, and the fact that this advice is going to be read by
+> > a lot of people as part of a big enhancement project, I think it's
+> > appropriate for the TC to answer this question.
+> 
+> If you feel like Policy should give advice on this, you can bring it up in
+> the context of Policy.
+
+The TC's mandate includes deciding on policy questions.
+
+>  I don't think the exact mechanism of integration is important
+> enough for the TC to explicitly favor a particular mechanism, and
+> different upstreams may have different approaches.  I'm not seeing
+> the important gain to Debian here in trying to standardize exactly
+> how one tells a daemon to use socket activation or readiness
+> notification.
+
+I'm not saying it should be standardised.
+
+I'm trying to give guidance to Debian contributors who will be doing
+this work on many existing daemons.  We would like them to do the best
+thing and giving them non-binding guidance is correct.
+
+> I also, for what it's worth, directly disagree with this advice with
+> respect to systemd because I think compatibility with how systemd is used
+> elsewhere is more important than any marginal gain from using a
+> configuration method that's not inherited by subprocesses by default,
+> particularly given that the standard systemd APIs include environment
+> sanitizing.  But I also don't see any point in arguing about it here,
+> since I don't think this dispute is ripe (in the legal sense).
+
+I'm afraid to say that this is quite a frustrating approach.
+
+If it will help I can go through the motions of filing a policy bug,
+having everyone point out that this is entangled with the whole init
+system debate, and having you reject my proposal.
+
+But perhaps we could just pretend I had done that ?
+
+> If you do bring it up in the context of Policy and we can't resolve the
+> debate there, it can get appealed to the TC and we can decide it here
+> separately, but I think this is all premature, given that the whole point
+> becomes basically moot if we don't pick systemd anyway.
+
+No, it doesn't become moot.  If we pick upstart then we still need to
+tell maintainers what kind of systemd patches to accept.
+
+If anything, it becomes moot if we pick systemd.  It seems unlikely
+that there would be a majority in the TC for picking systemd, and
+separately a majority in the TC for overruling the systemd maintainers'
+refusal to implement a simpler readiness protocol.
+
+So a decision to pick systemd automatically comes with the expectation
+that all daemons will get the new build- and runtime dependencies, and
+maintainers will be expected to accept those patches.
+
+> > Are you proposing then that the TC should decide the default init
+> > system, but asmk people NOT to start converting packages until the
+> > policy questions are settled ?
+> 
+> Sure.  I think that's what's going to happen anyway.
+
+I don't think that's likely, unless we state it explicitly.
+
+And I want the conversion work to be able to start as soon as
+possible.
+
+These questions are all entangled with the init system choice.  Having
+dealt with the primary issue the TC members will be in a good position
+to dispose of these ancillary issues.
+
+I think remanding contentious consequential issues back to the policy
+process is a very unattractive option.  It will just incur delay.
+
+I'm happy with leaving uncontentious details to the policy process.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 18:33:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 18:33:07 GMT) (full text, mbox, link).

+ +

Message #2155 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Ansgar Burchardt <ansgar@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 18:31:48 +0000
+
+
Ansgar Burchardt writes ("Bug#727708: init system other points, and conclusion"):
+> What about the cgroup management functionality that newer versions of
+> logind require? Should the systemd maintainers also reimplement it in
+> upstart?
+
+This is a somewhat separate issue, but: I think bundling the single
+cgroup writer into systemd is a very poor design choice.  I think the
+bad consequences of that choice should be borne by the people who made
+it.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 18:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Stapelberg <stapelberg@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 18:51:05 GMT) (full text, mbox, link).

+ +

Message #2160 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Stapelberg <stapelberg@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, Russ Allbery <rra@debian.org>, <727708@bugs.debian.org>
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Tue, 31 Dec 2013 19:49:44 +0100
+
+
Hi Ian,
+
+Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+>> > This is particularly the case for build-dependencies on an avowedly and
+>> > intentionally non-portable program.  Of course this can be made
+>> > conditional, but this is IMO too fiddly.
+>> 
+>> Adding [linux-any] to the Build-Depends line is not too fiddly, and if the
+>> goal is to enable optional upstream support for systemd, that will be
+>> sufficient.  Besides, in general, it's up to the packager to decide what
+>> is or is not too fiddly in how they want to package software.
+>
+> Adding [linux-any] to the Build-Depends is not sufficient.
+>
+> It is also necessary to make the actual source code conditionally use
+> sd_notify, using #ifdefs or other similar techniques.  The conditional
+> compilation will have to be automated (perhaps with autoconf if the
+> package has it - an then we need new --with[out]-systemd configuration
+> options to avoid miscompilation; or perhaps in an ad hoc way if the
+> daemon doesn't use autoconf).  The fact that the systemd-specific
+> command line option may or may not be compiled in needs to be
+> mentioned in the documentation, along with text which allows the user
+> to know whether it's included in the version they actually have.
+>
+> This turns what could be a simple change into a multi-part epic
+> involving all of the components of the package: primary source code,
+> upstream build system and portability layer, Debian build system,
+> documentation, and so on.
+No, this is all not true :).
+libsystemd-daemon already contains the conditionals necessary to be a
+noop on non-linux:
+http://sources.debian.net/src/systemd/204-5/src/libsystemd-daemon/sd-daemon.c
+
+Therefore, you can just use it, and don’t need to use any conditionals
+on your end, neither in the compilation process, nor in the code itself.
+
+That being said, I just checked and realized the package is not
+available on non-linux. I’ll look into that now, since intuitively there
+is no reason for this.
+
+-- 
+Best regards,
+Michael
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 18:54:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Christoph Anton Mitterer <calestyo@scientia.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 18:54:05 GMT) (full text, mbox, link).

+ +

Message #2165 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Christoph Anton Mitterer <calestyo@scientia.net>
+
To: 727708@bugs.debian.org
+
Subject: systemd status when using multiple block device layers + (MD/LVM/dm-crypt) below the root-fs
+
Date: Tue, 31 Dec 2013 19:45:57 +0100
+
+
Hi.
+
+Now that systemd could become default in Debian (well at least I favour
+it over upstream)... I started wondering how well it supports booting
+from a root fs on top of multiple block device layers?
+
+
+Some time ago I wrote [0] (with some contributions from others
+AFAICS)...
+So is there any information from the side of the systemd (Debian)
+maintainers, how far these scenarios are supported already?
+
+Right now there is a rather fixed order in which things work (i.e.
+phys->MD->LVM->dm-crypt->rootfs) out of the box (well in some cases at
+least) and IIRC, due to some "obscure" code in the cryptsetup initramfs
+scripts it works also with (dm-crypt->LVM)... but ideally all this
+should be handled more generally...
+
+
+Looking over the bugs from the systemd package in Debian give quite some
+concern here,... many things seem to not work yet (e.g. support for
+cryptsetup key scripts)... and many other bugs seem to be quite old and
+not having been worked on for very long.
+
+There's also the issue that apparently there are subtle issues when it
+comes to udev rules deployed with systemd or that systemd needs in a
+specific way (e.g. #712439) ... where we have problems since Debian
+maintainers from other packages divert from the upstrem udev rules for
+whichever reason.
+
+
+Cheers,
+Chris.
+
+
+
+[0] https://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 19:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 19:03:04 GMT) (full text, mbox, link).

+ +

Message #2170 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Michael Stapelberg <stapelberg@debian.org>
+
Cc: <727708@bugs.debian.org>
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Tue, 31 Dec 2013 11:00:28 -0800
+
+
Michael Stapelberg <stapelberg@debian.org> writes:
+
+> That being said, I just checked and realized the package is not
+> available on non-linux. I’ll look into that now, since intuitively there
+> is no reason for this.
+
+Thank you, Michael.  That would indeed make things much easier.  I think
+Ian is being excessively dramatic about very simple conditional
+integrations, but still, avoiding the conditional entirely is useful.
+
+One approach that would, I hope, minimize Ian's concerns is to provide a
+libsystemd-daemon-dev on non-Linux ports that just stubs out the calls,
+and that, on those architectures, provides some sort of dummy empty
+library that does nothing and adds no dependency.  (There may be an
+elegant way to do this with a linker script.)  That way, the exact same
+build process can be used everywhere, and everything just quietly
+disappears on non-Linux ports where systemd isn't available, without even
+adding a dependency on an (on that platform) useless shared library.
+
+What I used for lbcd is:
+
+#ifdef HAVE_SD_NOTIFY
+# include <systemd/sd-daemon.h>
+#else
+# define SD_LISTEN_FDS_START 3
+# define sd_listen_fds(u) 0
+# define sd_notify(u, s)  0
+#endif
+
+which of course only stubs out the two major calls and doesn't address the
+rest of the API.  That would need to be expanded to at least account for
+sd_notifyf (which will require a variadic macro, but that shouldn't be a
+problem in Debian) and sd_booted.
+
+I'm not sure what the best thing to do about the sd_is_* calls would be.
+One possible approach would be to just define them all to -ENOSYS, since
+they generally wouldn't be called when sd_listen_fds isn't available,
+although that would be a problem if any package ever used those APIs
+outside of a systemd context.  (But I'm not sure why one would do that.)
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 19:06:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 19:06:17 GMT) (full text, mbox, link).

+ +

Message #2175 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ansgar Burchardt <ansgar@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 11:05:12 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Dec 31, 2013 at 06:21:15PM +0100, Ansgar Burchardt wrote:
+> And if upstart wants to use parts of systemd, why shouldn't the upstart
+> maintainer do the work for this? Or they could fork logind which they
+> suggested before... This would also allow having a newer systemd in
+> Debian.
+
+upstart requires no part of systemd (unless you count udev as "systemd"
+now).  It's only the desktop environments which have dependencies on these
+dbus interfaces.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 19:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 19:15:04 GMT) (full text, mbox, link).

+ +

Message #2180 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: Simon McVittie <smcv@debian.org>
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Tue, 31 Dec 2013 11:10:14 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Dec 31, 2013 at 08:44:15AM -0800, Russ Allbery wrote:
+
+> > I'd like to suggest that this should only be done for daemons where
+> > there is anything that a sysadmin can sensibly configure in this
+> > way. The patch proposed for #712167 (native Upstart init support in
+> > dbus) did this, but after checking the available command-line options in
+> > dbus-daemon, I couldn't actually find any command-line options that can
+> > be changed by a sysadmin without breaking system integration; so I think
+> > it's OK that the systemd unit doesn't read /etc/default/dbus, and I
+> > don't think the (potential future) Upstart job should either.
+
+> I would argue....
+
+> > (Perhaps this means /etc/init.d/dbus should stop reading /etc/default/dbus...)
+
+> ...this.  If /etc/default is not useful, then it's not useful for the
+> sysvinit support either, and it seems better to just drop it in all
+> supported init systems rather than have it be inconsistent.  Either way,
+> you'd need a NEWS entry, etc., so that seems cleaner to me.
+
+Agreed.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 19:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 19:18:04 GMT) (full text, mbox, link).

+ +

Message #2185 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Christoph Anton Mitterer <calestyo@scientia.net>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd status when using multiple block device layers (MD/LVM/dm-crypt) below the root-fs
+
Date: Tue, 31 Dec 2013 11:15:33 -0800
+
+
Christoph Anton Mitterer <calestyo@scientia.net> writes:
+
+> Right now there is a rather fixed order in which things work (i.e.
+> phys->MD->LVM->dm-crypt->rootfs) out of the box (well in some cases at
+> least) and IIRC, due to some "obscure" code in the cryptsetup initramfs
+> scripts it works also with (dm-crypt->LVM)... but ideally all this
+> should be handled more generally...
+
+> Looking over the bugs from the systemd package in Debian give quite some
+> concern here,... many things seem to not work yet (e.g. support for
+> cryptsetup key scripts)... and many other bugs seem to be quite old and
+> not having been worked on for very long.
+
+For whatever it's worth, I've been using systemd on a system with LVM and
+dm-crypt (with LUKS) for about a month now, in the dm-crypt -> LVM ->
+filesystem mode, and haven't had any trouble.
+
+The page you linked to makes several assertions that I find curious.  That
+doesn't mean that they're wrong, but they seem somewhat contrary to my
+experience.  For example, I'm not sure where "however, for we really
+should should try to avoid forcing users to use initramfs images, for
+setups where they're not strictly needed" comes from; I've been using
+initramfs images for every Debian system I run, and every Debian system
+Stanford runs, for so long that I can't remember when we originally
+changed.  I don't understand why this would be something one would want to
+avoid.
+
+Similarly, I'm not sure why the focus on only adding necessary tools to
+the initramfs image.  Surely this doesn't matter much if the tools are
+harmless when unneeded?
+
+Hm.  I'm also not sure that this whole digression really belongs on this
+thread; maybe we should move it to debian-devel.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 20:06:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 20:06:05 GMT) (full text, mbox, link).

+ +

Message #2190 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Tue, 31 Dec 2013 21:03:59 +0100
+
+
]] Ian Jackson 
+
+> So I think we need to say what we regard as "reasonable" patches, in
+> advance.  As the Debian maintainer for uservd (for example), am I
+> entitled to decline to incorporate systemd integration into my package
+> on the grounds that the patch involves additional build- and runtime
+> dependencies which I consider undesirable ?
+
+If find it incredible that you consider adding 18 lines of
+unconditional code to your daemon unreasonable, while forcing the
+systemd maintainers to split the package, add explicitly rejected
+upstream-incompatible features reasonable.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 20:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 20:09:04 GMT) (full text, mbox, link).

+ +

Message #2195 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd status when using multiple block device layers (MD/LVM/dm-crypt) below the root-fs
+
Date: Tue, 31 Dec 2013 21:07:18 +0100
+
+
]] Christoph Anton Mitterer 
+
+> Now that systemd could become default in Debian (well at least I favour
+> it over upstream)... I started wondering how well it supports booting
+> from a root fs on top of multiple block device layers?
+
+That's handled by the initramfs where we currently don't use systemd.
+(It's supported upstream to do so and we might eventually investigate
+that, but I don't believe anybody has done any work on it for Debian.)
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 20:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 20:15:04 GMT) (full text, mbox, link).

+ +

Message #2200 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 21:09:52 +0100
+
+
]] Ian Jackson 
+
+> I think you have misunderstood.  Or perhaps I hae misunderstood you.
+> The "work" that I'm saying needs to be done anyway is the work to
+> disentange the parts of systemd which are required by (say) GNOME from
+> the parts which are only relevant for systemd as init.
+> 
+> This is work that would have to be done by the systemd maintainers in
+> Debian.
+
+I find it quite clear that this should be done and maintained by the
+people who want to run such an configuration.  I am not running any
+non-systemd desktop systems and would be in a very poor positition to be
+able to do this work.  I also have no interest in it, which I think
+should be pretty clear given my previous mails on the subject.
+
+We've also said quite clearly that we'd gladly accept a co-maintainer
+who wants to maintain this configuration, but nobody has shown up yet.
+(Martin Pitt has worked a bit with us on getting the patches from Ubuntu
+integrated, but AIUI, he's not been able to offer a long-term commitment
+to maintaining the patches, and I think it's a very bad idea to merge a
+patchset that nobody in the team wants to maintain long-term.)
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 20:15:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to cameron <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 20:15:07 GMT) (full text, mbox, link).

+ +

Message #2205 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: cameron <camerontnorman@gmail.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Cc: Ansgar Burchardt <ansgar@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 20:05:20 -0008
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Dec 31, 2013 at 10:31 AM, Ian Jackson 
+<ijackson@chiark.greenend.org.uk> wrote:
+> Ansgar Burchardt writes ("Bug#727708: init system other points, and 
+> conclusion"):
+>>  What about the cgroup management functionality that newer versions 
+>> of
+>>  logind require? Should the systemd maintainers also reimplement it 
+>> in
+>>  upstart?
+>> 
+> This is a somewhat separate issue, but: I think bundling the single
+> cgroup writer into systemd is a very poor design choice.  I think the
+> bad consequences of that choice should be borne by the people who made
+> it.
+> 
+
+Nitpick: cgroups had multiple arbitrators when systemd was written to 
+use it, and only recently did that change. I agree it was a poor design 
+choice, and the systemd devs did not outright oppose it (as they should 
+have IMO), but it was not technically systemd's fault.
+
+Best regards,
+Cameron Norman
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 20:15:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 20:15:11 GMT) (full text, mbox, link).

+ +

Message #2210 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 21:13:52 +0100
+
+
Le mardi 31 décembre 2013 à 18:31 +0000, Ian Jackson a écrit :
+> Ansgar Burchardt writes ("Bug#727708: init system other points, and conclusion"):
+> > What about the cgroup management functionality that newer versions of
+> > logind require? Should the systemd maintainers also reimplement it in
+> > upstart?
+> 
+> This is a somewhat separate issue, but: I think bundling the single
+> cgroup writer into systemd is a very poor design choice.  I think the
+> bad consequences of that choice should be borne by the people who made
+> it.
+
+By writing this, it strikes me that you must have seriously
+misunderstood some fundamental concepts of systemd. The new logind
+behavior is unrelated to the “single cgroup writer” matter, because
+there is no single cgroup writer as of today. I spent quite some time to
+summarize facts on cgroup management at Andreas’ request, and it seems
+you haven’t even read them. I find this very rude from a member of the
+technical committee to not try to understand the technical issues before
+deciding what other people are supposed to do.
+
+Which brings me to the other point: you are not going to decide what
+people want to spend their time on. If systemd is selected as the
+default, the systemd maintainers are not going to ask Steve to fix their
+upgrades problem for them. And if upstart is selected, you will
+certainly not ask members of the systemd community - from which Debian
+would have just excluded itself - to fix Debian’s problems with not
+having systemd.
+
+For an example I know, if having a working GNOME on Linux means a
+dependency on systemd, then it will have a dependency on systemd. If the
+TC overrules that, like it did the last time one of its members felt
+offended by a dependency in a package he doesn’t use, the alternative
+will have to be developed and made available by someone. From my
+discussions so far with other members of the GNOME team, that someone
+will not be a member of that group.
+
+Let’s say that GNOME migrates to systemd user sessions, like what is
+planned for GNOME 2.12 (yes, the version we intend to ship in jessie,
+ain’t that sweet). You can decide to cripple GNOME with Ubunbu patches
+instead, but that won’t be GNOME anymore; just an unbranded Ubuntu
+desktop. And you will not ask the people who spend their time providing
+a serious, upstream-friendly alternative to that desktop to spend it on
+dumping Ubuntu packages in Debian instead.
+
+So unless the TC wants to remove a great number of packages from the
+archive, you need to take into account the fact that some voluntary
+manpower is required to implement your decision.
+
+Cheers,
+-- 
+.''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 20:27:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Christoph Anton Mitterer <calestyo@scientia.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 20:27:05 GMT) (full text, mbox, link).

+ +

Message #2215 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Christoph Anton Mitterer <calestyo@scientia.net>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd status when using multiple block device + layers (MD/LVM/dm-crypt) below the root-fs
+
Date: Tue, 31 Dec 2013 21:25:39 +0100
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, 2013-12-31 at 11:15 -0800, Russ Allbery wrote:
+> For whatever it's worth, I've been using systemd on a system with LVM and
+> dm-crypt (with LUKS) for about a month now, in the dm-crypt -> LVM ->
+> filesystem mode, and haven't had any trouble.
+Do you use it on your root-fs? With keyscripts?
+
+> The page you linked to makes several assertions that I find curious.  That
+> doesn't mean that they're wrong, but they seem somewhat contrary to my
+> experience.  For example, I'm not sure where "however, for we really
+> should should try to avoid forcing users to use initramfs images, for
+> setups where they're not strictly needed" comes from; I've been using
+> initramfs images for every Debian system I run, and every Debian system
+> Stanford runs, for so long that I can't remember when we originally
+> changed.  I don't understand why this would be something one would want to
+> avoid.
+Well so do I,.. haven't a single system which doesn't use initramfs...
+OTOH I'm always sceptical about "forcing" people to do so (when e.g. the
+kernel itself can just happily life without an initrd)... because there
+might be scenarios I/we can't even think of where it may make sense to
+run without one.
+
+After all, Debian should be the universal OS ;)
+
+
+> Similarly, I'm not sure why the focus on only adding necessary tools to
+> the initramfs image.  Surely this doesn't matter much if the tools are
+> harmless when unneeded?
+Well it costs time when creating the initramfs, makes the initramfs
+image bigger (possibly not an advantage with embedded systems) and the
+useless stuff has to be decompressed every boot.
+Sure,... most people won't bother.. but why adding stuff that's not
+needed... I mean in many cases the initramfs-scripts actually run and do
+something, even if the respective thing (a filesystem or what ever) is
+not even present.... and that makes it more likely for problems to occur
+or performance to be wasted... as if such stuff isn't in place.
+
+Neither do we add libreoffice to initramfs ;-)
+
+
+Cheers,
+Chris.
+
+
[smime.p7s (application/x-pkcs7-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 20:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Christoph Anton Mitterer <calestyo@scientia.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 20:33:04 GMT) (full text, mbox, link).

+ +

Message #2220 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Christoph Anton Mitterer <calestyo@scientia.net>
+
To: Tollef Fog Heen <tfheen@err.no>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd status when using multiple block device + layers (MD/LVM/dm-crypt) below the root-fs
+
Date: Tue, 31 Dec 2013 21:28:12 +0100
+
+
On Tue, 2013-12-31 at 21:07 +0100, Tollef Fog Heen wrote:
+> That's handled by the initramfs where we currently don't use systemd.
+> (It's supported upstream to do so and we might eventually investigate
+> that, but I don't believe anybody has done any work on it for Debian.)
+Sure... but
+- using systemd inside the initramfs _may_ come at a later point
+- even though the root-fs (and the resume-fs) is mounted in the
+initramfs image... it may still interfere with the boot process by
+systemd, e.g. when the later might accidentally try to re-setup such
+dm-crypt mappings or else... which were already set up in the initramfs.
+- all the questions, about whether systemd supports stacking of multiple
+block layers is also interesting for non-root-filesystems.
+
+
+Cheers,
+Chris.
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 20:33:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to cameron <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 20:33:07 GMT) (full text, mbox, link).

+ +

Message #2225 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: cameron <camerontnorman@gmail.com>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 20:22:22 -0008
+
+
[Message part 1 (text/plain, inline)]
+
+
+On Tue, Dec 31, 2013 at 12:13 PM, Josselin Mouette <joss@debian.org> 
+wrote:
+> Le mardi 31 décembre 2013 à 18:31 +0000, Ian Jackson a écrit :
+>>  Ansgar Burchardt writes ("Bug#727708: init system other points, and 
+>> conclusion"):
+>>  > What about the cgroup management functionality that newer 
+>> versions of
+>>  > logind require? Should the systemd maintainers also reimplement 
+>> it in
+>>  > upstart?
+>>  
+>>  This is a somewhat separate issue, but: I think bundling the single
+>>  cgroup writer into systemd is a very poor design choice.  I think 
+>> the
+>>  bad consequences of that choice should be borne by the people who 
+>> made
+>>  it.
+>> 
+> By writing this, it strikes me that you must have seriously
+> misunderstood some fundamental concepts of systemd. The new logind
+> behavior is unrelated to the “single cgroup writer” matter, 
+> because
+> there is no single cgroup writer as of today. I spent quite some time 
+> to
+> summarize facts on cgroup management at Andreas’ request, and it 
+> seems
+> you haven’t even read them. I find this very rude from a member of 
+> the
+> technical committee to not try to understand the technical issues 
+> before
+> deciding what other people are supposed to do.
+> 
+> Which brings me to the other point: you are not going to decide what
+> people want to spend their time on. If systemd is selected as the
+> default, the systemd maintainers are not going to ask Steve to fix 
+> their
+> upgrades problem for them. And if upstart is selected, you will
+> certainly not ask members of the systemd community - from which Debian
+> would have just excluded itself - to fix Debian’s problems with not
+> having systemd.
+> 
+
+Nobody is preventing anybody from spending time on re-integrating 
+systemd and its services.
+
+> 
+> For an example I know, if having a working GNOME on Linux means a
+> dependency on systemd, then it will have a dependency on systemd. If 
+> the
+> TC overrules that, like it did the last time one of its members felt
+> offended by a dependency in a package he doesn’t use, the 
+> alternative
+> will have to be developed and made available by someone. From my
+> discussions so far with other members of the GNOME team, that someone
+> will not be a member of that group.
+> 
+
+Do not assume that people who dislike GNOME's systemd dependency do not 
+use GNOME. I do not use GNOME, but my sanity depends on gsettingsd (my 
+touchpad is broken and only gsettingsd can fix it), as well as my 
+aesthetic happiness (I like Pantheon shell, which uses gsettingsd and 
+gnomecc).
+
+> 
+> Let’s say that GNOME migrates to systemd user sessions, like what is
+> planned for GNOME 2.12 (yes, the version we intend to ship in jessie,
+> ain’t that sweet). You can decide to cripple GNOME with Ubunbu 
+> patches
+> instead, but that won’t be GNOME anymore; just an unbranded Ubuntu
+> desktop. And you will not ask the people who spend their time 
+> providing
+> a serious, upstream-friendly alternative to that desktop to spend it 
+> on
+> dumping Ubuntu packages in Debian instead.
+> 
+
+If GNOME depends on systemd, that is fine, but GNOME does not get to 
+dictate Debian's choice. The GNOME maintainers need to do whatever is 
+necessary for GNOME to run on Debian, including maintaining systemd and 
+systemd units, patching to work with Upstart, or removing functionality 
+that depends on systemd (which should not at all be basic 
+functionality, but only small stuff).
+
+Even if that non-basic functionality is removed, **it will still be 
+GNOME**. At least, it should be based on GNOME's own technical 
+conclusion.
+
+It seems like you are saying that because GNOME has decided to depend 
+on systemd, that Debian needs to cater to that decision. Debian does 
+not. In fact, Debian //should not//, because GNOME consciously decided 
+(or will decide) to break non-systemd compatibility, and knew that 
+doing so would break GNOME on Debian (in its current state).
+
+Cheers,
+Cameron Norman
+
+> 
+> So unless the TC wants to remove a great number of packages from the
+> archive, you need to take into account the fact that some voluntary
+> manpower is required to implement your decision.
+> 
+> Cheers,
+> -- 
+> .''`.      Josselin Mouette
+> : :' :
+> `. `'
+>   `-
+> 
+> 
+> -- 
+> To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
+> with a subject of "unsubscribe". Trouble? Contact 
+> listmaster@lists.debian.org
+> Archive: http://lists.debian.org/1388520832.5187.31.camel@tomoe
+> 
+> 
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 21:00:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 21:00:09 GMT) (full text, mbox, link).

+ +

Message #2230 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Josselin Mouette <joss@debian.org>
+
Cc: 727708@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 12:57:50 -0800
+
+
Josselin Mouette <joss@debian.org> writes:
+
+> Which brings me to the other point: you are not going to decide what
+> people want to spend their time on. If systemd is selected as the
+> default, the systemd maintainers are not going to ask Steve to fix their
+> upgrades problem for them. And if upstart is selected, you will
+> certainly not ask members of the systemd community - from which Debian
+> would have just excluded itself - to fix Debian’s problems with not
+> having systemd.
+
+I want to second this, because I agree with it completely.  It is a core
+principle of Debian, featuring prominantly in the constitution:
+
+    Nothing in this constitution imposes an obligation on anyone to do
+    work for the Project. A person who does not want to do a task which
+    has been delegated or assigned to them does not need to do
+    it. However, they must not actively work against these rules and
+    decisions properly made under them.
+
+I'm pretty sure that there are project resources available to integrate
+with systemd and that there are resources available to integrate with
+upstart (and there may be resources to integrate with both, although I
+really don't know).  But those resources are probably going to be
+different in at least some cases.  People are not, generally speaking,
+going to spend significant amount of time and effort working on source
+bases they don't like or in pursuit of goals that they don't agree with.
+
+This is one of the points I made in my writeup about the ecosystem.  These
+are exactly the sort of resources that we will have to muster and maintain
+going forward in order to adopt usptart.  Those resources may or may not
+be available in Debian today.  I think that depends on how much surgery
+this will require to systemd and GNOME, and possibly later to KDE and to
+other packages, and what the ongoing maintenance burden will look like.
+Obviously, we can share work with Ubuntu in some of these areas, which
+reduces the demand for Debian-specific resources.  But we certainly should
+not assume that either the current GNOME maintainers or the current
+systemd maintainers will be those resources.  They may be, or they may
+decide to go work on something else; either way, it's entirely up to them,
+as it should be.
+
+We currently have multiple dedicated groups already in place in Debian who
+have clearly said they will do the work to integrate their components with
+systemd, and who have either not expressed an opinion or who have
+indicated they're not interested in integrating with upstart.  And, I will
+also point out, we have other dedicated groups in Debian who are very
+concerned about the impact the adoption of systemd would have on *their*
+work and *their* projects.
+
+The degree to which this all should affect our decision-making process is
+limited.  That's particularly true in this case, which is one of those
+decisions where, whatever we choose, some group of people in Debian who
+have put a ton of work into something they care about are going to be at
+least somewhat unhappy.  That may be the systemd maintainers, the GNOME
+team, the Hurd porters, the kFreeBSD porters, the upstart maintainers,
+those who care deeply about tight Debian and Ubuntu integration, or any
+number of other groups.  It will probably be several of those.
+
+Occasionally, there are decisions with sweeping consequences, and we have
+to have a method for making them.  The TC is that method, which can then
+be overridden by General Resolution if warranted.
+
+However, it does affect how we should talk about these decisions, and it
+does affect the reality check on which approach has the most cost and on
+what resources are available.
+
+The TC doesn't get to order people to do work.  We are not managers, and
+Debian is not a corporation.  At most we can authorize NMUs or otherwise
+work around people who are preventing *other* people from doing work.
+And, as such, I really dislike seeing people make statements about what
+other specific people should be required to do in Debian.  Making
+statements about what work one believes needs to be done is a different
+matter, but one should not assume that this work is going to be done by
+the people currently maintaining the relevant packages if they don't agree
+with it.  Or if, for that matter, they get busy, they get sick, they have
+children, they retire, or they decide not to do that work for any other
+reason.
+
+For example, one possible outcome here is that whatever group cares about
+doing the upstart integration introduces a new systemd source package
+that's split and modified in such a way so as to work with upstart as the
+init system, and which conflicts with systemd as it is currently packaged.
+
+Furthermore, the TC is also not a code review body for Debian, nor is it
+our role to impose our personal asthetic or design views on the project.
+If any of us in the Debian project wanted to work on something with a
+dictated, top-down design, there are numerous other projects we could be
+working on, including several that offer wages for such effort.  One of
+the core qualities of Debian is that we only dictate standards to people
+when they're necessary for integration, security, or to reduce impact on
+other core teams such as ftp-master, release, or security.  Otherwise, we
+try to let people go about their work in the way that suits them best.
+This has various significant drawbacks, but the huge advantage that it
+makes working on Debian fun rather than a job.
+
+We have to make a decision here because Debian can only have one *default*
+init system, and all of our packages need to work with it.  Maybe that
+decision necessarily involves some amount of central control over how
+integrations are done, including switching maintainers or introducing new
+packages in order to implement those integrations.  But that's an
+unfortunate consequence of necessity, not an exciting opportunity to make
+everyone do everything the Right Way in an area where there are profound
+disagreements.
+
+I'm quite sure I'm not the only one who is regularly dictated design
+decisions in my regular job and has no interest in being subjected to the
+same thing in my hobby.
+
+Some amount of it is necessary in order to accomplish our shared goals of
+producing an integrated distribution.  And some of it falls under
+reasonable accomodation; for example, I believe the solution that we
+arrived at with Network Manager was reasonable accomodation to the desires
+of other people in Debian, and continue to defend it.  But on *exactly the
+same grounds*, I will defend introduction of shared library dependencies
+to daemons for integration with systemd.
+
+And we need to be very careful about what the boundaries of reasonable
+accomodation are.  Major surgery to one's packages contrary to fundamental
+design goals that one has pursued in creating those packages is not
+reasonable accomodation, and it's something we should only pursue if the
+greater goal truly both warrants it and requires it, and with the full
+understanding that this will often mean that the current maintainers will
+step down and someone else will need to do the actual work.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 21:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 21:03:05 GMT) (full text, mbox, link).

+ +

Message #2235 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Christoph Anton Mitterer <calestyo@scientia.net>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd status when using multiple block device layers (MD/LVM/dm-crypt) below the root-fs
+
Date: Tue, 31 Dec 2013 13:00:26 -0800
+
+
Christoph Anton Mitterer <calestyo@scientia.net> writes:
+> On Tue, 2013-12-31 at 11:15 -0800, Russ Allbery wrote:
+
+>> For whatever it's worth, I've been using systemd on a system with LVM and
+>> dm-crypt (with LUKS) for about a month now, in the dm-crypt -> LVM ->
+>> filesystem mode, and haven't had any trouble.
+
+> Do you use it on your root-fs? With keyscripts?
+
+I'm probably not using keyscripts since I don't know what that is.  The
+crypt setup is whatever the wheezy installer does.  I have an unencrypted
+boot partition, and then everything else is in LVM and encrypted,
+including swap.
+
+It's probably a fairly simple setup as these things go, hence the "for
+whatever it's worth."  Basically, all I can establish is that systemd
+doesn't seem to have any trouble with the standard encrypted disk setup
+created by the wheezy installer.  Given that, per Tollef, it's handled by
+initramfs before systemd is started, that's not surprising.  :)
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 21:09:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 21:09:08 GMT) (full text, mbox, link).

+ +

Message #2240 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Josh Triplett <josh@joshtriplett.org>, 727708@bugs.debian.org
+
Cc: debian-ctte@lists.debian.org, 726763@bugs.debian.org, + 729576@bugs.debian.org
+
Subject: Re: Bug#727708: systemd-shim uploaded to NEW
+
Date: Tue, 31 Dec 2013 13:07:22 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Dec 31, 2013 at 01:16:32AM -0800, Josh Triplett wrote:
+> Steve Langasek wrote:
+> > Looking more closely, I find that one of the conflicting files is a conffile
+> > (/etc/dbus-1/system.d/org.freedesktop.systemd1.conf).  diversions and
+> > conffiles still don't mix, AFAIK (and according to current policy).  So that
+> > seems to still leave us without a proper solution that doesn't involve
+> > splitting the systemd binary package.
+
+> Files in /etc/dbus-1/system.d/ need not have names that match the
+> interface they control; see, for instance, gdm.conf or
+> nm-dhcp-client.conf.  Why not simply install a systemd-shim.conf with
+> the contents you need?  To the best of my knowledge, I see nothing in
+> org.freedesktop.systemd1.conf that should interfere with you.
+
+I hadn't considered that, but yes, I see that it's true that we could
+install the conffile under a different name.
+
+Given that the two config files apply policy to the same dbus name, this
+means that a removed-but-not-purged systemd-shim package may impact
+systemd's own dbus security policy.  It's already the case that the
+systemd-shim and systemd policies are different.
+
+So, which is the lesser evil here - that a removed-but-not-purged
+systemd-shim package will interfere with the dbus policy of systemd itself,
+or that an installed-then-purged systemd-shim package will remove the
+systemd dbus policy altogether?
+
+> (That said, personally I'd prefer to see systemd-shim continue to
+> conflict with systemd, and work with a hypothetical
+> forked-systemd-logind package instead, which would also conflict with
+> systemd.  That would then, for instance, unblock systemd's ability to
+> upgrade past version 204.)
+
+For the record, logind is not the only issue here.  It's logind, timedated,
+hostnamed, localed which are needed by GNOME.  This doesn't actually change
+the work involved in forking the package; but I think it would be ridiculous
+to have two systemd source packages in the archive, with all the resulting
+coordination costs to both maintainers, instead of working out a correct
+binary split of the one package that meets the needs of all Debian's users.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 21:33:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andrew Shadura <andrew@shadura.me>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 21:33:13 GMT) (full text, mbox, link).

+ +

Message #2245 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andrew Shadura <andrew@shadura.me>
+
To: 727708@bugs.debian.org
+
Cc: debian-ctte@lists.debian.org, 726763@bugs.debian.org, + 729576@bugs.debian.org
+
Subject: Re: Bug#727708: systemd-shim uploaded to NEW
+
Date: Tue, 31 Dec 2013 22:30:56 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Hello,
+
+On Tue, 31 Dec 2013 13:07:22 -0800
+Steve Langasek <vorlon@debian.org> wrote:
+
+> For the record, logind is not the only issue here.  It's logind,
+> timedated, hostnamed, localed which are needed by GNOME.  This
+> doesn't actually change the work involved in forking the package; but
+> I think it would be ridiculous to have two systemd source packages in
+> the archive, with all the resulting coordination costs to both
+> maintainers, instead of working out a correct binary split of the one
+> package that meets the needs of all Debian's users.
+
+Speaking of hostnamed... I wonder what's wrong with xdg-hostnamed[1],
+why did systemd have chosen to reimplement it from scratch?
+
+[1] http://cgit.freedesktop.org/~david/xdg-hostname/
+
+-- 
+Cheers,
+  Andrew
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 21:54:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 21:54:07 GMT) (full text, mbox, link).

+ +

Message #2250 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org, debian-ctte@lists.debian.org, + 726763@bugs.debian.org, 729576@bugs.debian.org
+
Subject: Re: Bug#727708: systemd-shim uploaded to NEW
+
Date: Tue, 31 Dec 2013 13:50:15 -0800
+
+
On Tue, Dec 31, 2013 at 01:07:22PM -0800, Steve Langasek wrote:
+> On Tue, Dec 31, 2013 at 01:16:32AM -0800, Josh Triplett wrote:
+> > Steve Langasek wrote:
+> > > Looking more closely, I find that one of the conflicting files is a conffile
+> > > (/etc/dbus-1/system.d/org.freedesktop.systemd1.conf).  diversions and
+> > > conffiles still don't mix, AFAIK (and according to current policy).  So that
+> > > seems to still leave us without a proper solution that doesn't involve
+> > > splitting the systemd binary package.
+> 
+> > Files in /etc/dbus-1/system.d/ need not have names that match the
+> > interface they control; see, for instance, gdm.conf or
+> > nm-dhcp-client.conf.  Why not simply install a systemd-shim.conf with
+> > the contents you need?  To the best of my knowledge, I see nothing in
+> > org.freedesktop.systemd1.conf that should interfere with you.
+> 
+> I hadn't considered that, but yes, I see that it's true that we could
+> install the conffile under a different name.
+> 
+> Given that the two config files apply policy to the same dbus name, this
+> means that a removed-but-not-purged systemd-shim package may impact
+> systemd's own dbus security policy.  It's already the case that the
+> systemd-shim and systemd policies are different.
+
+Interesting; why are those policies different?  systemd's policy is, as
+far as I can tell, "root can do as it likes, root can receive activation
+requests, anyone else can send specific requests".  Is systemd-shim's
+policy more lax or more strict?
+
+> So, which is the lesser evil here - that a removed-but-not-purged
+> systemd-shim package will interfere with the dbus policy of systemd itself,
+> or that an installed-then-purged systemd-shim package will remove the
+> systemd dbus policy altogether?
+
+The latter, quite clearly.  Both would be bugs in systemd-shim, but
+removing the configuration entirely would break systemd with the
+systemd-shim package *not* installed, while interfering with the
+configuration would break systemd with the systemd-shim package
+*installed*, which seems less egregious and less surprising.
+
+> > (That said, personally I'd prefer to see systemd-shim continue to
+> > conflict with systemd, and work with a hypothetical
+> > forked-systemd-logind package instead, which would also conflict with
+> > systemd.  That would then, for instance, unblock systemd's ability to
+> > upgrade past version 204.)
+> 
+> For the record, logind is not the only issue here.  It's logind, timedated,
+> hostnamed, localed which are needed by GNOME.  This doesn't actually change
+> the work involved in forking the package; but I think it would be ridiculous
+> to have two systemd source packages in the archive, with all the resulting
+> coordination costs to both maintainers, instead of working out a correct
+> binary split of the one package that meets the needs of all Debian's users.
+
+The key phrase is "both maintainers".  Having two packages that
+permanently conflict with each other hardly seems like a major
+coordination effort.  (The only annoyance I can think of is that I don't
+know of any way to conflict with a package such that even having it
+removed-but-not-purged would prevent installation of the conflicting
+package.)
+
+The problem is not the binary split, it's the ongoing maintenance burden
+of making components of systemd run without systemd.  I would like to
+see the forked-systemd source package maintained by folks willing to do
+that work, and in the meantime, I'd like to see an *un*-forked systemd
+package usable by people who want and use systemd.  (I'd be quite
+willing to help with the latter, especially if the systemd maintainers
+find themselves shorthanded due to demotivation caused by an upcoming
+tech-ctte decision.)  In particular, I'd like to see new versions of
+systemd available in Debian as soon as they're available upstream, and
+that seems highly unlikely to happen with a forked systemd.  I'd also
+like to avoid a situation in which the only package of systemd in the
+archive is maintained as a permanent fork by people who don't actually
+use it as their init systemd; that would not bode well for people trying
+to run it and have their systems depend on it.
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 22:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 22:15:04 GMT) (full text, mbox, link).

+ +

Message #2255 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Tue, 31 Dec 2013 17:11:26 -0500
+
+
On Mon, Dec 30, 2013 at 10:24 PM, Steve Langasek wrote:
+> On Mon, Dec 30, 2013 at 08:12:19PM -0500, Michael Gilbert wrote:
+>> > Part of my goal in writing up that plan was, as you
+>> > say, to try to provide a means for people who are committed to one system
+>> > or the other to continue to work on what they're passionate about even if
+>> > it's not chosen as the default init system.
+>
+>> Unfortunately at least two camps will be entirely dejected by any TC
+>> mandate here.
+>
+> I don't agree with that conclusion.
+
+That no unhappiness will arise out of this decision is, I think, a
+quite unlikely outcome, so this statement is quite surprising.  As
+Russ eloquently states today [1]
+
+    The degree to which this all should affect our decision-making
+    process is limited.  That's particularly true in this case, which
+    is one of those decisions where, whatever we choose, some
+    group of people in Debian who have put a ton of work into
+    something they care about are going to be at least somewhat
+    unhappy.  That may be the systemd maintainers, the GNOME
+    team, the Hurd porters, the kFreeBSD porters, the upstart
+    maintainers, those who care deeply about tight Debian and
+    Ubuntu integration, or any number of other groups.  It will
+    probably be several of those.
+
+The TC needs to find a path that minimizes unintended social
+consequences.  I have been trying to make the case in this thread that
+the only reasonable solution that does so is one which empowers all
+camps to do work to further their cause without feeling excluded.
+Eventually, and this may take sometime but everything worth doing
+does, a clearly superior solution will emerge that can, when ready,
+become the default.
+
+> When it comes to technology choices, you win some and you lose some.
+
+The fact that there may be winners and losers is not the issue at
+hand.  It is the specter of being disqualified before the game even
+starts.
+
+> Your proposal smells like the status quo.
+
+That is only true if none of the systemd, openrc, and upstart teams
+get to the point where their init is usable, then we're stuck with
+sysvinit.  This is probably an unlikely circumstance, but sysvinit
+does work.
+
+> Namely, instead of the project
+> making a decision and being able to all pull together in the same direction
+> to provide the best possible OS, we will continue to coast, squandering
+> efforts on preserving users' ability to make choices about things that no
+> user should ever be asked to care about
+
+The project never goes in the same direction.  1,000 people go in
+their own direction, creative solutions eventually emerge, one often
+gains the most traction, but others remain as alternatives (think
+debhelper/cdbs/etc), and choice and freedom remain.  It will be a
+major change in project governance to select any resolution prior to
+emergence.
+
+In my opinion, the only reasonable TC decision is one that requests
+project members feel empowered to work toward the solutions that they
+are interested in, while being open-minded and non-obstructive to all
+of the other competing solutions.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 31 Dec 2013 23:15:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Christian McHugh <mchugh19@yahoo.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 31 Dec 2013 23:15:08 GMT) (full text, mbox, link).

+ +

Message #2260 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Christian McHugh <mchugh19@yahoo.com>
+
To: 727708@bugs.debian.org
+
Subject: Systemd: not just gnome
+
Date: Tue, 31 Dec 2013 17:13:07 -0600
+
+
Hello all,
+
+I did not see it linked yet, and thought it pertinent to the
+discussion: some kde plasma desktop developers described their
+possible intentions to utilize systemd functionality (while keeping
+their existing shell script based startup for non systemd systems) in
+a future release here
+https://plus.google.com/115606635748721265446/posts/GMtZrNCeaLD
+
+While not a surprise, it is worth noting that it is not only Gnome
+that is looking into systemd, and that this init selection continues
+to have ramifications outside of system initialization. I'd suggest
+looking over Martin Gräßlin's comments as well as the in-depth reply
+by Aaron Seigo explaining their reasoning.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 01:06:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 01:06:05 GMT) (full text, mbox, link).

+ +

Message #2265 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd status when using multiple block device layers (MD/LVM/dm-crypt) below the root-fs
+
Date: Wed, 01 Jan 2014 02:03:47 +0100
+
+
]] Christoph Anton Mitterer 
+
+> On Tue, 2013-12-31 at 21:07 +0100, Tollef Fog Heen wrote:
+> > That's handled by the initramfs where we currently don't use systemd.
+> > (It's supported upstream to do so and we might eventually investigate
+> > that, but I don't believe anybody has done any work on it for Debian.)
+> Sure... but
+> - using systemd inside the initramfs _may_ come at a later point
+
+We'll tackle any bugs if we decide to do that.  I don't see any point in
+trying to figure out any bugs we might run into if we go down a route
+nobody (in Debian, AFAIK) has even tried as an experiment.
+
+> - even though the root-fs (and the resume-fs) is mounted in the
+> initramfs image... it may still interfere with the boot process by
+> systemd, e.g. when the later might accidentally try to re-setup such
+> dm-crypt mappings or else... which were already set up in the initramfs.
+
+Why would it do that?  Any such re-setup would be a bug, and I'm not
+aware of any bugs in that respect.  Do you have any bugs where this
+actully happens today?
+
+> - all the questions, about whether systemd supports stacking of multiple
+> block layers is also interesting for non-root-filesystems.
+
+systemd mounts a block device.  How that block device is up to multiple
+components such as lvm, cryptsetup, etc.  It's correct that systemd
+currently does not support keyscripts, a deficency I was looking into
+just last week.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 01:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 01:27:04 GMT) (full text, mbox, link).

+ +

Message #2270 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Wed, 01 Jan 2014 02:23:50 +0100
+
+
+First of all, thanks a lot for writing this mail.  It expresses a lot of
+my thoughts and feelings on the subject a lot more eloquently than I am
+able to do myself.  You're a wordsmith and a master of words.  I am
+not.
+
+]] Russ Allbery 
+
+> Occasionally, there are decisions with sweeping consequences, and we have
+> to have a method for making them.  The TC is that method, which can then
+> be overridden by General Resolution if warranted.
+
+Given how the voting ratio so far looks, I've been giving the whole GR
+process a bit of thought lately and at least I am unlikely to pursue it,
+simply because I don't think it's a good way to spend my and the
+project's energy.  If you decide that you want to go with upstart,
+that's obviously not what I want, but I'll rather take the consequences
+of that than go one more round and appeal to the developer body at
+large.  As our common astronomy geek friend puts it, I don't have the
+people beans to spend on that.  Somebody else might.
+
+Personally, I wish the TC was a bit more careful with the «people» angle
+of their rulings.  You spent a lot of goodwill in the GNOME camp when
+pushing through the latest NM Depends->Recommends change, and I think
+it'd be a shame if we ended up losing or demotivating a good bunch of
+good developers again.
+
+> The TC doesn't get to order people to do work.  We are not managers, and
+> Debian is not a corporation.  At most we can authorize NMUs or otherwise
+> work around people who are preventing *other* people from doing work.
+
+I think what you're saying here is really important.  What Ian is asking
+about is for the systemd maintainers to do a lot of work we don't want
+to do, and if we end up with a resolution that basically tells the
+systemd maintainers to support a chopped-up package, it'd be massively
+demotivating for me personally.  From the message from Joss, it seems
+like the GNOME people feel the same way.
+
+[...]
+
+> For example, one possible outcome here is that whatever group cares about
+> doing the upstart integration introduces a new systemd source package
+> that's split and modified in such a way so as to work with upstart as the
+> init system, and which conflicts with systemd as it is currently packaged.
+
+The way things are going, I don't think that'd be a terrible situation,
+tbh.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 01:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 01:54:05 GMT) (full text, mbox, link).

+ +

Message #2275 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 17:50:29 -0800
+
+
Tollef Fog Heen <tfheen@err.no> writes:
+
+> Given how the voting ratio so far looks, I've been giving the whole GR
+> process a bit of thought lately and at least I am unlikely to pursue it,
+> simply because I don't think it's a good way to spend my and the
+> project's energy.
+
+There's one point that I think is worth noting there, although I'm not
+advocating for a GR and it would be much better if the TC arrived at a
+conclusion that the project could get behind.  That's that it's common,
+for decision-making bodies and for appeal processes, to have a small group
+of people go off and do discovery of the facts so that there's a basis of
+researched information on which to judge an appeal.
+
+Obviously, one of the reasons why I'm trying to synthesize my
+understanding and write up summaries is because I think it's useful for
+the TC decision itself.  But it's also a useful artifact for the developer
+body as a whole, should it want to review the TC decision.  I think this
+process has already brought a lot more light to the exact issues,
+concerns, and tradeoffs involved, and subsequent decisions can be made
+with reference to the artifacts of the TC deliberation, without expecting
+each developer to need to go off and do research on their own.
+
+We've already worked through a variety of misconceptions and false starts
+that were not obvious from the debian-devel discussion.  If it does come
+to a project-wide vote, I think we will have more of a consensus on the
+facts as we know them today, and people can then vote on how they want to
+weigh those facts against each other.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 02:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 02:00:05 GMT) (full text, mbox, link).

+ +

Message #2280 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Wed, 01 Jan 2014 02:56:27 +0100
+
+
Le dimanche 29 décembre 2013 à 22:50 -0800, Steve Langasek a écrit :
+> Socket-based activation has never been a feature that upstart upstream has
+> promoted the use of.
+
+I am a bit confused here. You wrote in the upstart position statement,
+almost at the top:
+        “Upstart supports both bus activation and socket activation.”
+
+Why advertise it if it is “a red herring that will never deliver the
+promised benefits”?
+
+-- 
+.''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 02:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to cameron <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 02:06:04 GMT) (full text, mbox, link).

+ +

Message #2285 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: cameron <camerontnorman@gmail.com>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Wed, 01 Jan 2014 01:54:17 -0008
+
+
[Message part 1 (text/plain, inline)]
+
Josselin,
+
+I actually added that to the statement. I did so because it has 
+legitimate uses, and because it is something that a number of people 
+have expressed interest in using.
+
+Best regards,
+Cameron Norman
+
+On Tue, Dec 31, 2013 at 5:56 PM, Josselin Mouette <joss@debian.org> 
+wrote:
+> Le dimanche 29 décembre 2013 à 22:50 -0800, Steve Langasek a écrit 
+> :
+>>  Socket-based activation has never been a feature that upstart 
+>> upstream has
+>>  promoted the use of.
+>> 
+> I am a bit confused here. You wrote in the upstart position statement,
+> almost at the top:
+>         “Upstart supports both bus activation and socket 
+> activation.”
+> 
+> Why advertise it if it is “a red herring that will never deliver the
+> promised benefits”?
+> 
+> -- 
+> .''`.      Josselin Mouette
+> : :' :
+> `. `'
+>   `-
+> 
+> 
+> -- 
+> To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
+> with a subject of "unsubscribe". Trouble? Contact 
+> listmaster@lists.debian.org
+> Archive: http://lists.debian.org/1388541387.6302.16.camel@tomoe
+> 
+> 
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 02:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 02:24:04 GMT) (full text, mbox, link).

+ +

Message #2290 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Wed, 01 Jan 2014 03:21:18 +0100
+
+
Le mercredi 01 janvier 2014 à 01:54 -0008, cameron a écrit :
+> On Tue, Dec 31, 2013 at 5:56 PM, Josselin Mouette <joss@debian.org>
+> wrote:
+> > I am a bit confused here. You wrote in the upstart position
+> > statement, almost at the top: “Upstart supports both bus activation
+> > and socket activation.”
+> 
+> I actually added that to the statement. I did so because it has
+> legitimate uses, and because it is something that a number of people
+> have expressed interest in using.
+
+Thanks for the explanation. That makes the upstart position much more
+consistent. Apologies to Steve for putting words in his mouth without
+looking at the wiki history.
+
+Now it would be even better if random strangers didn’t modify the
+position statements to add items that knowingly misrepresent the
+statement maintainer’s point of view, before barging in the discussion
+and telling developers what they need to do.
+
+-- 
+.''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 02:24:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 02:24:07 GMT) (full text, mbox, link).

+ +

Message #2295 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: cameron <camerontnorman@gmail.com>, 727708@bugs.debian.org
+
Cc: Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Tue, 31 Dec 2013 18:21:27 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Jan 01, 2014 at 01:54:17AM -0008, cameron wrote:
+> I actually added that to the statement. I did so because it has
+> legitimate uses, and because it is something that a number of people
+> have expressed interest in using.
+
+Right, I never wrote that.  I've reverted these changes to the position
+statement.
+
+Cameron, as per the first paragraph, please do not change the page directly,
+but discuss any proposed changes with me first.
+
+Thanks,
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+> On Tue, Dec 31, 2013 at 5:56 PM, Josselin Mouette <joss@debian.org>
+> wrote:
+> >Le dimanche 29 décembre 2013 à 22:50 -0800, Steve Langasek a écrit
+> >:
+> >> Socket-based activation has never been a feature that upstart
+> >>upstream has
+> >> promoted the use of.
+> >>
+> >I am a bit confused here. You wrote in the upstart position statement,
+> >almost at the top:
+> >        “Upstart supports both bus activation and socket
+> >activation.”
+> >
+> >Why advertise it if it is “a red herring that will never deliver the
+> >promised benefits”?
+> >
+> >-- 
+> >.''`.      Josselin Mouette
+> >: :' :
+> >`. `'
+> >  `-
+> >
+> >
+> >-- 
+> >To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
+> >with a subject of "unsubscribe". Trouble? Contact
+> >listmaster@lists.debian.org
+> >Archive: http://lists.debian.org/1388541387.6302.16.camel@tomoe
+> >
+> >
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 02:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to cameron <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 02:27:04 GMT) (full text, mbox, link).

+ +

Message #2300 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: cameron <camerontnorman@gmail.com>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Wed, 01 Jan 2014 02:15:58 -0008
+
+
[Message part 1 (text/plain, inline)]
+
Steve,
+
+I am very sorry, I did not see the paragraph. I will familiarize myself 
+with the debate system before contributing to it again.
+
+Happy New Years,
+Cameron Norman
+
+On Tue, Dec 31, 2013 at 6:21 PM, Steve Langasek <vorlon@debian.org> 
+wrote:
+> On Wed, Jan 01, 2014 at 01:54:17AM -0008, cameron wrote:
+>>  I actually added that to the statement. I did so because it has
+>>  legitimate uses, and because it is something that a number of people
+>>  have expressed interest in using.
+>> 
+> Right, I never wrote that.  I've reverted these changes to the 
+> position
+> statement.
+> 
+> Cameron, as per the first paragraph, please do not change the page 
+> directly,
+> but discuss any proposed changes with me first.
+> 
+> Thanks,
+> -- 
+> Steve Langasek                   Give me a lever long enough and a 
+> Free OS
+> Debian Developer                   to set it on, and I can move the 
+> world.
+> Ubuntu Developer                                    
+> http://www.debian.org/
+> slangasek@ubuntu.com                                     
+> vorlon@debian.org
+> 
+>>  On Tue, Dec 31, 2013 at 5:56 PM, Josselin Mouette <joss@debian.org>
+>>  wrote:
+>>  >Le dimanche 29 décembre 2013 à 22:50 -0800, Steve Langasek a 
+>> écrit
+>>  >:
+>>  >> Socket-based activation has never been a feature that upstart
+>>  >>upstream has
+>>  >> promoted the use of.
+>>  >>
+>>  >I am a bit confused here. You wrote in the upstart position 
+>> statement,
+>>  >almost at the top:
+>>  >        “Upstart supports both bus activation and socket
+>>  >activation.”
+>>  >
+>>  >Why advertise it if it is “a red herring that will never deliver 
+>> the
+>>  >promised benefits”?
+>>  >
+>>  >-- 
+>>  >.''`.      Josselin Mouette
+>>  >: :' :
+>>  >`. `'
+>>  >  `-
+>>  >
+>>  >
+>>  >-- 
+>>  >To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
+>>  >with a subject of "unsubscribe". Trouble? Contact
+>>  >listmaster@lists.debian.org
+>>  >Archive: http://lists.debian.org/1388541387.6302.16.camel@tomoe
+>>  >
+>>  >
+>> 
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 03:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 03:03:05 GMT) (full text, mbox, link).

+ +

Message #2305 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Tue, 31 Dec 2013 19:01:51 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Dec 31, 2013 at 09:13:52PM +0100, Josselin Mouette wrote:
+> Le mardi 31 décembre 2013 à 18:31 +0000, Ian Jackson a écrit :
+> > Ansgar Burchardt writes ("Bug#727708: init system other points, and conclusion"):
+> > > What about the cgroup management functionality that newer versions of
+> > > logind require? Should the systemd maintainers also reimplement it in
+> > > upstart?
+
+> > This is a somewhat separate issue, but: I think bundling the single
+> > cgroup writer into systemd is a very poor design choice.  I think the
+> > bad consequences of that choice should be borne by the people who made
+> > it.
+
+> By writing this, it strikes me that you must have seriously
+> misunderstood some fundamental concepts of systemd. The new logind
+> behavior is unrelated to the “single cgroup writer” matter, because
+> there is no single cgroup writer as of today.
+
+It's not true that it's unrelated.  In v205, logind hands off the cgroup
+heirarchy creation to PID 1, precisely because it's preparing for the
+anticipated future kernel requirement of a single cgroup writer.  If we're
+expecting this "single cgroup writer" requirement to manifest, then it makes
+sense to move cgroup writing out of logind.  The problem is with moving it
+to PID1, causing increasingly tight coupling between the components of
+systemd.
+
+> Let’s say that GNOME migrates to systemd user sessions, like what is
+> planned for GNOME 2.12 (yes, the version we intend to ship in jessie,
+> ain’t that sweet).
+
+  "It's important to note that with these patches, we still support
+  non-systemd systems (as well as older systemd). How far into the future we
+  do so is an open question, but it should not be too difficult to leave
+  non-systemd systems with the previous model over the next few cycles."
+
+  https://wiki.gnome.org/ThreePointEleven/Features/SystemdUserSession
+
+I suppose it's possible that GNOME upstream are actually insane enough to
+decide that in future versions they will dictate an init system to the
+distributions, but that is not actually an issue for 3.12.  There are
+advantages to using systemd for user session management, particularly when
+coupled with Wayland... but these can just as well be delivered on top of
+upstart rather than systemd.  It does not follow that GNOME upstream should
+dictate to Debian that they adopt systemd rather than upstart.
+
+> So unless the TC wants to remove a great number of packages from the
+> archive, you need to take into account the fact that some voluntary
+> manpower is required to implement your decision.
+
+I think the current Debian GNOME team has a not-undeserved reputation for
+being obstructionist with respect to bugfixes that require divergence from
+upstream's stated direction.  If the team demonstrated they were open to
+contributions of the kind you described, volunteers to do the work would not
+be hard to come by.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 03:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 03:12:05 GMT) (full text, mbox, link).

+ +

Message #2310 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: Christoph Anton Mitterer <calestyo@scientia.net>
+
Subject: Re: Bug#727708: systemd status when using multiple block device + layers (MD/LVM/dm-crypt) below the root-fs
+
Date: Tue, 31 Dec 2013 19:08:34 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Dec 31, 2013 at 11:15:33AM -0800, Russ Allbery wrote:
+> Similarly, I'm not sure why the focus on only adding necessary tools to
+> the initramfs image.  Surely this doesn't matter much if the tools are
+> harmless when unneeded?
+
+In this context I'm not sure how applicable it is; but there are many x86
+platforms where the bootloader doesn't have particularly impressive I/O
+performance, and having to load a large initramfs before booting the kernel
+has a major impact on boot speed.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 04:12:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 04:12:04 GMT) (full text, mbox, link).

+ +

Message #2315 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Wed, 1 Jan 2014 14:09:08 +1000
+
+
[Message part 1 (text/plain, inline)]
+
Okay, let's see how replying to a mail on my phone while in flight mode
+goes. Apologies in advance for formatting, quoting and vocabulary issues.
+
+On Dec 31, 2013 4:48 AM, "Russ Allbery" <rra@debian.org> wrote:
+
+> 2. Impact of Multiple Init Systems
+> Obviously, the ideal situation for project-wide integration and support,
+> and for Debian's ability to make full use of the capabilities of new init
+> systems, is for all of Debian's ports to be running the same init system.
+
+So, reading this (and trimming loss of stuff that makes sense) I wonder if
+it's worth stepping back and considering what happens when a package
+doesn't support /any/ init system. The answer I think is that the sysadmin
+sighs, adds their own configuration, and maybe thinks "well at least I
+didn't have to compile it, I guess."
+
+That still sucks compared to the alternative of typing "apt-get install"
+and having it just start working, of course.
+
+> Attempting to support multiple init systems has several obvious drawbacks:
+>
+> * Packages will either be limited by the functionality of the least
+>   capable init system or will behave differently (and have to be
+>   configured differently) on different ports.
+
+I think the "Debian" way of dealing with multiple init systems would be to
+provide a compatibility layer for the most common packaging and admin
+tasks, and allowing packages to provide fancier integration where
+appropriate. I'm thinking of things like newaliases and sendmail, and
+cgi-bin and apache modules, I guess. Probably that's already covered for
+init systems via sysvinit compatibility and update-rc.d. Maybe there's a
+missing tool that could be written to let you set init specific
+configuration somehow, which would change /etc/default for sysv and other
+files for upstart/systemd.
+
+It seems like there's maybe three separate questions then: what init system
+gets used by default, what work gets done to make that experience
+different/better than everything just having upstart or systemd pretending
+to be sysvinit, and what's the experience of maintaining packages to
+support secondary init systems and using secondary init systems on a Debian
+system?
+
+(Personally, I think a gr would be better for choosing the default then
+having the tech ctte decide that issue, but whatever)
+
+Based on what I've read, it seems like the ideas floating around amount to:
+
+- if systemd is default: there would be a release goal to include systemd
+configs added to packages and to get daemons converted to support socket
+activation. Maybe other stuff too? As far as maintaining sysvinit, openrc
+or upstart systemd goes, you'd just have to get upstart configs written and
+packaged, and accept that there's an unused systemd library on your system.
+Multiple inits must be supported to some extent, since systemd isn't
+available on ports and that isn't likely to change apparently.
+
+- upstart is default, other inits are supported: pull in Ubuntu configs for
+upstart for various packages. If systemd socket stuff is allowed, dummy
+library will probably be on most systems, if not, systemd in Debian won't
+be very interesting.
+
+- upstart is default and only init supported by Debian. Same support work
+for Jessie, except any ports that want to stick around need to get upstart
+enabled.
+
+I don't think the latter is really the Debian way - better to have the
+choice left in the users' hand if feasible, but it's likely a lot easier to
+get some impressive results that way. I think the ideal page for tradeoffs
+like that is in derivatives like Ubuntu personally.
+
+> I believe Debian should take this path forward:
+> 1. We should select a new init system for jessie, either systemd or
+>    upstart.  Support for that init system should be release-critical, but
+>    only in the sense that the daemon works properly under that init
+>    system.  In other words, use of the sysvinit compatibility of either
+>    init system is acceptable support for jessie.
+
+So that would mean switching the init system, and decorating anything that
+breaks as a result RC buggy. Seems sensible.
+
+> 2. All packages providing init scripts must continue to support sysvinit
+>    scripts through the jessie release.  Such support will continue to be
+>    release-critical.
+
+I'm not sure this makes sense, though. If someone packages a new daemon
+that works fine with systemd and upstart, I don't see why it shouldn't get
+released just because it doesn't work with two secondary init systems.
+Filling a wishlist bug with a patch and doing an NMU seem like they'd be
+sufficient here.
+
+As far as upgrades go, if the idea is that systemd is the way to go for
+Jessie it seems to me that an update would by default switch you from
+sysvinit to systemd (likewise for upstart) - I don't think it makes much
+sense to do systemd/upstart for new installs but leave upgrades with sysv
+until Jessie+1.
+
+> 7. After jessie, functionality between systems running the primary Linux
+>    init system and other init systems (including non-Linux ports) should
+>    be allowed to drift.  In other words, there will be cases where
+>    features will only be available with the primary init system.  Possible
+>    examples include security hardening, socket activation, automatic
+>    daemon restarts, and so forth.  Packagers are under no obligation to
+>    port those features to other init systems, but should welcome and merge
+>    patches that do so.  After jessie, packagers will no longer be required
+>    to preserve daemon configuration when the init system is switched, so
+>    use of such facilities as modification of upstart configuration files
+>    or systemd overrides may be used.
+
+The only way maintainers are required to do these things is that either a)
+someone else will do it and nmu their package, or b) the release team will
+drop it from Jessie prior to release, no? Personally I'd be inclined to
+encourage patches and nmus here, and limit the rc stuff to actual belated
+with whatever Jessie's default end up being. I don't see any reason that
+wouldn't suffice to allow comparability and an aggressive approach to
+making use of the new default init's extra capabilities.
+
+(I wonder if it might be interesting for the tech ctte to track the bugs
+for resulting from changing the init system rather than leaving it to the
+release team as either rc issues or release goals... Might be a good
+approach for some high impact improvements)
+
+(Fwiw, I'm employed by Red Hat, but have no particular stake in systemd vs
+upstart, nor much knowledge about either than what I've read here)
+
+Cheers,
+aj
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 06:21:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 06:21:05 GMT) (full text, mbox, link).

+ +

Message #2320 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Tue, 31 Dec 2013 22:18:08 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> Well, no.  I think that even if we select upstart as the default, we
+> should enable the systemd community to provide as complete a set of
+> integration in Debian as they care to put the work in for.
+
+> That translates directly to an expectation that the maintainer of any
+> daemon package must be willing to accept reasonable systemd integration
+> patches.
+
+> If the systemd community is very dynamic (and certainly we can't fault
+> their dynamism so far) this may well translate to all or almost all
+> daemons.  Certainly it could be expected to include most of the core
+> daemons where the extra dependencies are most troublesome.
+
+> So I think we need to say what we regard as "reasonable" patches, in
+> advance.  As the Debian maintainer for uservd (for example), am I
+> entitled to decline to incorporate systemd integration into my package
+> on the grounds that the patch involves additional build- and runtime
+> dependencies which I consider undesirable ?
+
+Ah!  Okay, now I understand why you think this is linked and something we
+should decide here.  Thank you.
+
+Okay, so let me see if I understand what we agree on and what we would
+need to debate.  Would you agree with both of these statements?
+
+* If we adopt systemd, then obviously integration with systemd would be
+  desirable and should be accepted, including build and runtime
+  dependencies as is appropriate for how systemd is integrated into the
+  distribution as a whole.
+
+* If a maintainer wishes to integrate with systemd via build and runtime
+  dependencies in their daemon, that would be their call, not something
+  the TC would decide.  (I think you do agree with this given the
+  statement below, but leaving this in as summary.)
+
+If so, then the problem reduces to what to do in the case where someone
+requests integration with systemd via a bug report and the maintainer
+doesn't want to provide that integration, at least with build or runtime
+dependencies or both.
+
+Let's put aside the question of how to handle this on the ports that don't
+have systemd for the moment, and hence the conditional build integration
+parts, since that was discussed in the other thread and I think there are
+possible lightweight schemes that are specific to the case where we just
+want to stub out the calls.
+
+I assume that the reason why you're bringing this up, per your original
+message, is that you don't want to introduce either build or runtime
+dependencies.  I don't, however, understand why; the logic doesn't make
+any sense to me.  Both of those dependencies are so lightweight that I
+have a hard time seeing how anyone would notice they exist, beyond having
+a couple of packages installed on the system that wouldn't otherwise be.
+
+I'm inclined to say that asking maintainers to add those dependencies is
+appropriate.  I'm not aware of a precedent for this for something that
+we're not committing to supporting for the archive, but it certainly
+parallels other deployments in Debian, such as SELinux and multi-arch.
+
+> I think the latter is the right approach, for two reasons.  Firstly, it
+> is less work overall.  Secondly, it is proper that the maintainers of an
+> init system should be encouraged to provide as simple and nonintrusive
+> an integration interface as possible.
+
+I believe that systemd has already provided this, and I find your belief
+that it hasn't to be strange.  I certainly don't think that we will
+succeed, or *should* succeed, in convincing systemd to adopt a new API
+that offers no clear benefit over their existing API and is incompatible
+with it.  If I were them, I'd reject it out of hand as a waste of time and
+effort.
+
+Incidentally, the tools in the init-system-helpers package are basically
+playing the same role as tools that are in the sysv-rc package now.  I
+think one could make a pretty good argument that, were we designing this
+from scratch today without worrying about history or backward
+compatibility, update-rc.d and invoke-rc.d would go into
+init-system-helpers, since they're (now) general tools that support a
+variety of underlying init systems.
+
+If the dependency on that package is really such a burden, one thing we
+could do is just move the two scripts in it into sysv-rc and use sysv-rc
+as the package that holds those tools.  I don't really care, and I don't
+mind having two packages, but looking at the current contents of both,
+they're really quite close to the same thing.  (sysv-rc also continues to
+provide a small amount of additional infrastructure for sysvinit, but it's
+pretty limited.)
+
+> I think maintainers should not be required to introduce the additional
+> build- and runtime dependencies, if they do not wish to.  Obviously if
+> they want to then that's fine by me.
+
+Ah, good, okay.  This is less of a conflict than at first I thought we
+had.
+
+I definitely understand the desire to not impose requirements on package
+maintainers that they don't like, and to minimize the impact of such
+requirements.
+
+>> If you feel like Policy should give advice on this, you can bring it up
+>> in the context of Policy.
+
+> The TC's mandate includes deciding on policy questions.
+
+I know, but it also contains the following statement:
+
+    Technical Committee makes decisions only as last resort.
+
+    The Technical Committee does not make a technical decision until
+    efforts to resolve it via consensus have been tried and failed, unless
+    it has been asked to make a decision by the person or body who would
+    normally be responsible for it.
+
+Basically, I'm really uncomfortable having this sort of conversation here
+among a rather small group of people.  I think it's likely that we're
+going to miss implications or impacts, and in some cases it's quite
+valuable to have more people available to provide a reality check.
+
+> I'm afraid to say that this is quite a frustrating approach.
+
+> If it will help I can go through the motions of filing a policy bug,
+> having everyone point out that this is entangled with the whole init
+> system debate, and having you reject my proposal.
+
+> But perhaps we could just pretend I had done that ?
+
+If we're going to discuss it here and now, then my recommendation for
+systemd integration is to do what I did with lbcd: use the presence of the
+LISTEN_FDS and LISTEN_PID environment variables to trigger socket
+activation code, and use the presence of the NOTIFY_SOCKET environment
+variable to trigger status notification.  In both cases, clear the
+environment variables after recovering the data (unless you're using the
+watchdog support) so that they aren't inherited by children.
+
+I think this provides the most natural integration with systemd and
+reduces the amount of fiddling that the packager has to do in setting up
+the daemon configuration.  It has the advantage of letting the daemon work
+either with socket activation or without, using the same unit
+configuration, and continuing to work if one cuts and pastes the same
+command line into the shell (to test something, for example).
+
+It doesn't hurt anything if someone wanted to add another flag to the
+daemon to tell it to look at those environment variables (as long as it
+keeps working when that flag is given but they're not set -- that's
+important for being able to switch from socket activation to not), but I
+don't see any need to do so.
+
+For upstart readiness, obviously one needs some sort of explicit flag or
+trigger to enable the raise(SIGSTOP) behavior, since that will otherwise
+cause rather obvious problems in getting the daemon to work outside of
+upstart.  I prefer to use a command-line flag for this (-Z, per your
+recommendation) since it has to be explicitly enabled and there isn't the
+same sort of safe fallback if it's missing the way that there is for the
+systemd protocol.  I don't see any real problem with using an environment
+variable, though, as long as it's unset afterwards so that it's not
+inherited by children.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 10:06:20 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 10:06:20 GMT) (full text, mbox, link).

+ +

Message #2325 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: Christoph Anton Mitterer <calestyo@scientia.net>
+
Subject: Re: Bug#727708: systemd status when using multiple block device + layers (MD/LVM/dm-crypt) below the root-fs
+
Date: Wed, 1 Jan 2014 02:05:13 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Dec 31, 2013 at 07:08:34PM -0800, Steve Langasek wrote:
+> On Tue, Dec 31, 2013 at 11:15:33AM -0800, Russ Allbery wrote:
+> > Similarly, I'm not sure why the focus on only adding necessary tools to
+> > the initramfs image.  Surely this doesn't matter much if the tools are
+> > harmless when unneeded?
+> 
+> In this context I'm not sure how applicable it is; but there are many x86
+                                                                        ^^^
+non-x86
+
+> platforms where the bootloader doesn't have particularly impressive I/O
+> performance, and having to load a large initramfs before booting the kernel
+> has a major impact on boot speed.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 12:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 12:54:05 GMT) (full text, mbox, link).

+ +

Message #2330 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Wed, 1 Jan 2014 12:51:49 +0000
+
+
On Tue, Dec 31, 2013 at 10:18:08PM -0800, Russ Allbery wrote:
+> For upstart readiness, obviously one needs some sort of explicit flag or
+> trigger to enable the raise(SIGSTOP) behavior, since that will otherwise
+> cause rather obvious problems in getting the daemon to work outside of
+> upstart.  I prefer to use a command-line flag for this (-Z, per your
+> recommendation) since it has to be explicitly enabled and there isn't the
+> same sort of safe fallback if it's missing the way that there is for the
+> systemd protocol.  I don't see any real problem with using an environment
+> variable, though, as long as it's unset afterwards so that it's not
+> inherited by children.
+
+Bear in mind that this may often be being done by the Debian maintainer
+in advance of upstream, and adding a one-character command-line option
+is problematic since that stands a decent chance of clashing.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 13:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 13:00:04 GMT) (full text, mbox, link).

+ +

Message #2335 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: cameron <camerontnorman@gmail.com>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Wed, 1 Jan 2014 12:56:39 +0000
+
+
On Tue, Dec 31, 2013 at 04:27:16AM -0008, cameron wrote:
+> On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson <cjwatson@debian.org>
+> >inotify is used to notice changes to configuration files.  This is
+> >certainly helpful for users, but it isn't critical as "initctl
+> >reload-configuration" works without it.  We could probably do without
+> >this with the aid of a dpkg trigger.
+> 
+> inotify use can easily be ported to kqueue within Upstart, or
+> libinotify-kqueue can be used.
+
+Note that I'm talking about the Hurd here.  kqueue is a kFreeBSD thing,
+as far as I know.  (Compare e.g.
+https://lists.debian.org/debian-hurd/2013/10/msg00021.html)
+
+> >prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification
+> >work properly when Upstart is supervising a user session.  This isn't
+> >a required feature and could easily be compiled out until suitable
+> >kernel support is available (this actually seems like the sort of
+> >thing that could be done in the Hurd without too much difficulty, but
+> >I haven't looked into it).  If absent, it might well impede the
+> >ability to do an advanced desktop port, but it wouldn't get in the
+> >way of porting the bulk of services.
+> 
+> Unity, likely the only desktop environment using Upstart as a
+> session init, is not in Debian. The sacrifice of this functionality
+> on non-linux systems is perfectly acceptable.
+
+While this is true today, we need to look to the future.  Using Upstart
+as a session init is not conceptually tied to Unity in any way, and I
+expect that other desktop environments will want to use more advanced
+session supervision soon enough.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 14:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to intrigeri <intrigeri@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 14:45:04 GMT) (full text, mbox, link).

+ +

Message #2340 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: intrigeri <intrigeri@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Wed, 01 Jan 2014 15:44:07 +0100
+
+
Hi,
+
+Ian Jackson wrote (31 Dec 2013 16:58:17 GMT) :
+> I think you have misunderstood.  Or perhaps I hae misunderstood you.
+> The "work" that I'm saying needs to be done anyway is the work to
+> disentange the parts of systemd which are required by (say) GNOME from
+> the parts which are only relevant for systemd as init.
+
+I was talking about the very same work, so I think we're understanding
+each other just fine on this point :)
+
+Your reply helped me focus and clarify my analysis (that is not "the
+project as whole" / "porters and upstart lovers" anymore), though.
+Thank you.
+
+It also helped me understand what, I think, a few things we disagree
+on: first, who would have the "moral" responsibility of doing this
+work; second, whether it matters at all; third, who would have to do
+this work in practice.
+
+In what follows, I'll try to keep my personal preferences (that don't
+matter at all as far as the TC decision is concerned) aside, but
+I don't expect to be entirely successful. Sorry about that in advance.
+My conscious intent here is to help make this discussion more fruitful
+and focused on what matters in practice; but it's obvious that my
+analysis is somehow affected by the investments I've personally made
+in the last 14 months (since then, I have been very happily running
+systemd on almost every Wheezy or newer system that I am responsible
+for). For the sake of full-disclosure, I have to add that I am a core
+developer of a Debian derivative that relies on GNOME and does not
+intend to switch any time soon.
+
+> intrigeri writes ("Bug#727708: init system other points, and conclusion"):
+>> The difference lies in who are the people who "need" to do this work
+>> "anyway", and who else may instead dedicate their time to other tasks,
+>> lead by their own desires and needs.
+
+> I think that it is right that the costs of undoing systemd's bundling,
+> be borne by the systemd community (including systemd's advocates and
+> maintainers in Debian) rather than by Debian (or the rest of the Free
+> Software world) at large.
+
+First, I beg to disagree about who, in full rightness, would have the
+"moral" responsibility to do this work. But as shown below, we don't
+care much about what you or I think.
+
+Second, regardless of what my or Ian's or the TC's or $DEITY's opinion
+on this moral matter is, that's very much unimportant: in my belief,
+the time and energy people put into Debian is rarely lead by a sense
+of "moral" responsibility, especially when the work that "needs to be
+done" is something they do *not* feel to be part of what they have
+committed to in the first place. I happen to very much doubt that the
+systemd community feels that they are committed to support the
+use-case we are discussing (systemd minus its init component).
+
+Hence, my third point is that in practice:
+
+* If upstart is chosen as the default init: it might be that the
+  systemd community shows little interest in doing this work (and, to
+  be fair, I would find this totally understandable, and not
+  surprising at all). Then, it is not unlikely that the people who end
+  up doing this work are those who maintain reverse dependencies of
+  the systemd stack, such as desktop environments (at least GNOME and
+  Unity, in Debian and/or Ubuntu). They might have to do this because
+  of the combination of 1. they want to keep their packages in working
+  state in Debian and/or Ubuntu; 2. the decision to use upstart
+  creates the need for someone to do this work; 3. for whatever
+  reason, nobody else is doing it.
+
+  If this were to happen, regardless of anyone's take on what full
+  rightness would have called for, then the cost of the initial and
+  ongoing work would be held by an important subset of our community,
+  that is anyone who wants Debian to deliver a given modern DE.
+  I realize that it's not the same as the Debian project as a whole,
+  contrary to what I initially wrote. But it's a lot more people than
+  just the systemd maintainers in Debian (I'm not comparing to the
+  broader systemd community here, for reasons I've given above).
+
+* If systemd is chosen as the default init: I am very doubtful that
+  a decision of the TC regarding who has the "moral" responsibility of
+  it would be enough to motivate the systemd community to tackle this
+  work if they don't feel it's part of the mission they are committed
+  to. It might be, but I don't think it's a reasonable assumption to
+  make.
+
+  So, with the information I have in hand, I'm sticking to my original
+  point here: in practice, this would be a job for porters, for anyone
+  who wants to allow users of Debian to give this amount of
+  flexibility, and for any derivative who wants to use another init
+  system; while others treat this effort with "deference and
+  reasonable accommodation", and can get themselves busy, as they
+  wish, with other means to scratch their own itch and/or make the
+  world a better place.
+
+My conclusion is that 1. in practice, the situation is far from being
+as simple as: the systemd community will have to do it anyway; and 2.
+the consequences of the TC decision is likely to affect very
+different, though non-disjoint, 1. sets of people and, 2. (IMO more
+importantly) use cases Debian has been supporting, and many
+derivatives have been building upon for many years.
+
+Cheers,
+-- 
+  intrigeri
+  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
+  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 16:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Neil McGovern <neil@halon.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 16:54:04 GMT) (full text, mbox, link).

+ +

Message #2345 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Neil McGovern <neil@halon.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Wed, 1 Jan 2014 16:50:51 +0000
+
+
On 30 Dec 2013, at 18:47, Russ Allbery <rra@debian.org> wrote:
+> However, I think it's the best available approach that balances our ideals
+> as a project against the opportunities offered by a new init system.  This
+> approach does permit full use of new init system features for jessie
+> except for eliminating /etc/default files (which I doubt we'd successfully
+> do quickly anyway), and opens up the full spectrum of use cases after
+> jessie.  The cost is that packagers should merge contributed patches to
+> the init systems that they don't use.  I don't think this is too much to
+> ask, nor do I think it will have serious effects on package complexity
+> based on my own experience configuring a package to work under all three
+> init systems I considered.
+> 
+
+I’m no longer a RM, but I would echo Russ’ comments here - an ordered transition is very important for Debian releases - and the size of this transition would be something that (in my opinion) would be very hard to achieve in one release cycle.
+
+Neil
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 16:54:07 GMT) (full text, mbox, link).

+ +

Message #2348 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: Colin Watson <cjwatson@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Wed, 01 Jan 2014 17:52:03 +0100
+
+
Hi,
+
+Colin Watson <cjwatson@debian.org> writes:
+> Reservations with systemd
+> -------------------------
+[...]
+> Basically, systemd would be more compelling to me if it tried to do
+> less.  I don't expect to persuade systemd advocates of this, as I think
+> it amounts to different basic views of the world, but the basic approach
+> here is probably the single biggest factor influencing my position.
+
+On the other hand even when using upstart as an init replacement, we'll
+continue to use large chunks of systemd (logind, other dbus
+services). I personally think "less is more" would only be a convincing
+argument if we actually would not need the aditional features.
+
+I also have one question: your mail doesn't mention the integration
+problems with logind into a system that uses upstart and not systemd as
+init. Do you think this will not be an issue? Given it means ongoing
+work instead of a one-time investment, this is one of my main gripes
+with upstart. I feel that minor technical differences between the init
+replacements are not work committing to long-time maintaince of a
+systemd-logind branch that works outside of systemd. There are more
+interesting areas we can invest our resources into.
+
+Note that this might also include session management functions in the
+future. As you mentioned yourself in [1], DEs are looking into using
+advanced session supervision. So far both kwin and GNOME seem to target
+systemd for this. So this would be another area that we would need to
+invest resources into to maintain an upstart replacement.
+
+  [1] <https://lists.debian.org/debian-ctte/2014/01/msg00017.html>
+
+Ansgar
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 17:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 17:21:04 GMT) (full text, mbox, link).

+ +

Message #2353 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: Ansgar Burchardt <ansgar@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Wed, 1 Jan 2014 17:17:25 +0000
+
+
On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
+> Colin Watson <cjwatson@debian.org> writes:
+> > Reservations with systemd
+> > -------------------------
+> [...]
+> > Basically, systemd would be more compelling to me if it tried to do
+> > less.  I don't expect to persuade systemd advocates of this, as I think
+> > it amounts to different basic views of the world, but the basic approach
+> > here is probably the single biggest factor influencing my position.
+> 
+> On the other hand even when using upstart as an init replacement, we'll
+> continue to use large chunks of systemd (logind, other dbus
+> services). I personally think "less is more" would only be a convincing
+> argument if we actually would not need the aditional features.
+
+I'm referring to features that I don't think we'll need, not to logind
+et al.  So far I feel that the debates about those seem to be a bit
+circular and go something like this:
+
+  A: This feature of systemd conflicts with something else; I'd rather
+     we didn't use it.
+  B: You can disable that, you know.
+  A: OK, let's disable it.
+  B: But you shouldn't disable it because that would make Debian systemd
+     less compatible with systemd on other distributions.
+  A: ...
+
+> I also have one question: your mail doesn't mention the integration
+> problems with logind into a system that uses upstart and not systemd as
+> init. Do you think this will not be an issue?
+
+I think the amount of time spent arguing about it has already exceeded
+the total amount of effort it would ever take.
+
+That said, I rather suspect that it was a tactical error for Upstart
+people to choose to use the logind code from systemd, even though that
+involved less reimplementation of wheels.  In the long term it would
+probably be better to write an independent implementation of the same
+interfaces or fork the existing code to a different source package,
+partly because that would help to dispose of the idea that Upstart is
+really dependent on systemd anyway, and partly because it would be
+friendlier to the Debian systemd maintainers.
+
+No doubt that could still be done.  It's unfortunate that it's not one
+of the components listed as "Reimplementable Independently", but I guess
+that just means more manual effort to keep track of the interface; and
+this would move the grunt work from the shoulders of the Debian systemd
+maintainers to those of the Upstart maintainers, which is probably the
+right place for it to lie.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 17:39:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 17:39:11 GMT) (full text, mbox, link).

+ +

Message #2358 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Colin Watson <cjwatson@debian.org>
+
Cc: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Wed, 1 Jan 2014 09:38:05 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Jan 1, 2014 at 4:56 AM, Colin Watson <cjwatson@debian.org> wrote:
+
+> On Tue, Dec 31, 2013 at 04:27:16AM -0008, cameron wrote:
+> > On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson <cjwatson@debian.org>
+> > >inotify is used to notice changes to configuration files.  This is
+> > >certainly helpful for users, but it isn't critical as "initctl
+> > >reload-configuration" works without it.  We could probably do without
+> > >this with the aid of a dpkg trigger.
+> >
+> > inotify use can easily be ported to kqueue within Upstart, or
+> > libinotify-kqueue can be used.
+>
+> Note that I'm talking about the Hurd here.  kqueue is a kFreeBSD thing,
+> as far as I know.  (Compare e.g.
+> https://lists.debian.org/debian-hurd/2013/10/msg00021.html)
+>
+> > >prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification
+> > >work properly when Upstart is supervising a user session.  This isn't
+> > >a required feature and could easily be compiled out until suitable
+> > >kernel support is available (this actually seems like the sort of
+> > >thing that could be done in the Hurd without too much difficulty, but
+> > >I haven't looked into it).  If absent, it might well impede the
+> > >ability to do an advanced desktop port, but it wouldn't get in the
+> > >way of porting the bulk of services.
+> >
+> > Unity, likely the only desktop environment using Upstart as a
+> > session init, is not in Debian. The sacrifice of this functionality
+> > on non-linux systems is perfectly acceptable.
+>
+> While this is true today, we need to look to the future.  Using Upstart
+> as a session init is not conceptually tied to Unity in any way, and I
+> expect that other desktop environments will want to use more advanced
+> session supervision soon enough.
+>
+>
+I place less importance on the session init capabilities of Upstart, as
+alternative home grown solutions ww.ritten by the environments are in place
+and are portable. Furthermore, portability of these environments hinges on
+a session and seat manager, ConsoleKit support in GNOME is quickly
+disappearing, and ConsoleKit itself is completely abandoned. What this
+means, to me, is there is a lot more effort required to accomplish this
+than to port Upstart's session init capabilities or use the current
+portable session inits.
+
+Sincerely,
+Cameron Norman
+
+--
+> Colin Watson                                       [cjwatson@debian.org]
+>
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 18:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 18:18:05 GMT) (full text, mbox, link).

+ +

Message #2363 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Wed, 01 Jan 2014 20:15:46 +0200
+
+
On Wed, 2014-01-01 at 17:17 +0000, Colin Watson wrote:
+> On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
+> > Colin Watson <cjwatson@debian.org> writes:
+> > > Basically, systemd would be more compelling to me if it tried to do
+> > > less.  I don't expect to persuade systemd advocates of this, as I think
+> > > it amounts to different basic views of the world, but the basic approach
+> > > here is probably the single biggest factor influencing my position.
+> > 
+> > On the other hand even when using upstart as an init replacement, we'll
+> > continue to use large chunks of systemd (logind, other dbus
+> > services). I personally think "less is more" would only be a convincing
+> > argument if we actually would not need the aditional features.
+
+I think this counterargument, while valid, misses the major flaw in the
+"would be more compelling if it tried to do less" claim:
+
+You can simply not install any of these additional services if you don't
+want them. This is completely trivial to do. Using systemd as init in no
+way requires using them. Thus their existence cannot cause any technical
+problems for the use of systemd in Debian (beyond possibly needing to do
+the trivial disabling).
+
+If some other components that Debian does want to use start to depend on
+those services, such that disabling them is not easy, then this problem
+would exist regardless of the chosen init, and is again not a reason for
+favor upstart.
+
+> I'm referring to features that I don't think we'll need, not to logind
+> et al.  So far I feel that the debates about those seem to be a bit
+> circular and go something like this:
+> 
+>   A: This feature of systemd conflicts with something else; I'd rather
+>      we didn't use it.
+>   B: You can disable that, you know.
+>   A: OK, let's disable it.
+>   B: But you shouldn't disable it because that would make Debian systemd
+>      less compatible with systemd on other distributions.
+>   A: ...
+
+Here B first correctly points out that the feature can be disabled if
+desired, and thus the situation cannot be worse than with upstart - you
+can do at least as well with systemd as you could with upstart. Then you
+(A) have a disagreement with B about whether disabling the feature is
+the _best_ way to handle the situation: B thinks that gaining
+compatibility with other distributions is a bigger plus, and that
+changing to the systemd way is an actual win over current situation,
+rather than just neutral like the the upstart and disabling with systemd
+cases.
+
+There is no technical reason to prefer upstart here. Given your
+preferences, systemd can do at least as well (after disabling the
+service). Given B's preferences, systemd can do better (after enabling
+the service). The only benefit that choosing upstart would give you here
+is that it'd let you automatically win your argument with B: "we already
+chose upstart, so enabling the systemd service is not an available
+choice any more".
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 01 Jan 2014 19:24:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Christoph Anton Mitterer <calestyo@scientia.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 01 Jan 2014 19:24:10 GMT) (full text, mbox, link).

+ +

Message #2368 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Christoph Anton Mitterer <calestyo@scientia.net>
+
To: Mourad De Clerck <mourad@aquazul.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: systemd status when using multiple block device + layers (MD/LVM/dm-crypt) below the root-fs
+
Date: Wed, 01 Jan 2014 20:22:10 +0100
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, 2014-01-01 at 05:48 +0100, Mourad De Clerck wrote:
+> So last time I tried, this just worked - my rootfs got mounted using a 
+> keyscript in the initramfs, and there were no problems, not a peep from 
+> systemd when it took over, no re-setup or anything.
+Sure... but that applies, AFAIU, only to the stuff mounted from within
+the initramfs (at most: rootfs / resume-fs).
+
+While I think that for most attack-scenarios, where on-disk-encryption
+makes sense (the notably exception being: coincidental theft of your
+device), a fully encrypted system (i.e. including the root-fs) is the
+only thing that makes sense... it's still necessary to support
+additional encrypted devices to be brought up during boot (which is
+AFAIU then systemd's task).
+
+I've added few thoughts to #618862, with things that IMHO are necessary
+to get proper keyscript support with systemd.
+
+> Stacking causes no problems in my experience. There are of course still 
+> problems with devices that aren't mounted in the initramfs but still 
+> need some keyscript (f.e. decrypt_derived comes to mind).
+Well from inside the initramfs this definitely does not work out of the
+box... since they initramfs-scripts expect a specific order (i.e. MDADM
+first, and so on... and especially the lvm scripts are kinda bogus).
+Not that it would make much sense to put dmcrypt below MDADM (in the
+meantime not even performance-wise)... security wise this might be even
+disastrous.
+
+
+Cheers,
+Chris.
+
+
[smime.p7s (application/x-pkcs7-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 00:03:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 00:03:05 GMT) (full text, mbox, link).

+ +

Message #2373 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Colin Watson <cjwatson@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Wed, 01 Jan 2014 16:00:23 -0800
+
+
Colin Watson <cjwatson@debian.org> writes:
+> The criticisms of Upstart's event model in the systemd position
+> statement simply do not make sense to me.  Events model how things
+> actually happen in reality; dependencies are artificial constructions on
+> top of them, and making them work requires the plethora of different
+> directives in systemd (e.g. Wants, which is sort of a non-depending
+> dependency) to avoid blocking the boot process on a single failing
+> service.  Yes, there are some bugs possible in the Upstart design, but I
+> don't agree that those are world-ending fundamental issues and I think
+> they're generally incrementally fixable.  The systemd design appears to
+> me to expose far more complexity to the user writing unit files, and I
+> think it's important that their mental model be as straightforward as
+> possible.
+>
+> (Now, I've been working with Upstart's model for years, and it's now a
+> pretty fundamental way of how I think of system operation; so if people
+> who are new to *both* models rather than partisans of one side or the
+> other consistently tell me that the systemd model is easier to grasp,
+> then I'll listen.)
+
+For what it's worth, I consider myself new to both the upstart and the
+systemd model, and for me the upstart event model has been pretty much
+the only reason to prefer systemd over upstart (though after reading
+Russ' opinion, that has changed a bit).
+
+For me, upstart was actually the reason for me switching from Debian to
+Ubuntu for a while. I am less familiar with systemd, so it may well be
+that I underestimate the complexities of the systemd model. However, I
+am very certain in my dislike for the upstart approach.
+
+
+My first point of criticism has already been described by Russ, but
+maybe I can make it clearer by giving an example. In my opinion, the
+following job looks completely harmless, and should not result in an
+unbootable system (but at least on Ubuntu 13.10 it does, you have to
+reboot with init=/bin/sh and remove/fix the evilJob.conf file):
+
+$ cat evilJob.conf
+start on (mounted MOUNTPOINT=/var and started lightdm)
+stop on runleves [016]
+respawn
+script
+   exec /bin/sleep 60
+end script
+
+I believe that the equivalent systemd unit (where dependencies are
+specified with Requires=) works just fine.  It is not clear to me how
+this can be "incrementally fixed" in upstart without fundamentally
+changing the design.
+
+
+My second point is that by treating dependencies as events, upstart does
+not seem to truly recognize dependencies as such and is then unable to
+resolve them.  For example, with the following two job files (created
+according to the upstart cookbook, 6.32.2):
+
+$ cat jobOne.conf
+start on (starting jobTwo and runlevel stop on runlevel [016])
+stop on runlevel [016]
+respawn
+script
+    exec /bin/sleep 60
+end script
+
+$ cat jobTwo.conf
+start on runlevel [2345]
+stop on runlevel [016]
+respawn
+script
+    exec /bin/sleep 60
+end script
+
+
+I can type "service start jobOne", and upstart will willingly start
+jobOne without starting jobTwo, or doing anything about the unfulfilled
+dependency (not even a warning):
+
+root@ubuntu-kvm:/etc/init# service jobOne status
+jobOne stop/waiting
+root@ubuntu-kvm:/etc/init# service jobTwo status
+jobTwo stop/waiting
+root@ubuntu-kvm:/etc/init# service jobOne start
+jobOne start/running, process 3177
+root@ubuntu-kvm:/etc/init# service jobTwo status
+jobTwo stop/waiting
+
+(on Ubuntu 13.10).
+
+As I understand, a systemd unit with "Requires=jobTwo" will not start
+without jobTwo running.
+
+I guess this could be fixed by hardcoding a special treatment of the
+"start on starting" event, but that would effectively be equivalent to
+introducing a new kind of "depends on" stanza, and thus acknowledge that
+the "everything is an event" model doesn't quite work.
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 00:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 00:39:04 GMT) (full text, mbox, link).

+ +

Message #2378 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Nikolaus Rath <Nikolaus@rath.org>, 727708@bugs.debian.org, + Colin Watson <cjwatson@debian.org>
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Wed, 1 Jan 2014 16:36:46 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath <Nikolaus@rath.org> wrote:
+
+> Colin Watson <cjwatson@debian.org> writes:
+> > The criticisms of Upstart's event model in the systemd position
+> > statement simply do not make sense to me.  Events model how things
+> > actually happen in reality; dependencies are artificial constructions on
+> > top of them, and making them work requires the plethora of different
+> > directives in systemd (e.g. Wants, which is sort of a non-depending
+> > dependency) to avoid blocking the boot process on a single failing
+> > service.  Yes, there are some bugs possible in the Upstart design, but I
+> > don't agree that those are world-ending fundamental issues and I think
+> > they're generally incrementally fixable.  The systemd design appears to
+> > me to expose far more complexity to the user writing unit files, and I
+> > think it's important that their mental model be as straightforward as
+> > possible.
+> >
+> > (Now, I've been working with Upstart's model for years, and it's now a
+> > pretty fundamental way of how I think of system operation; so if people
+> > who are new to *both* models rather than partisans of one side or the
+> > other consistently tell me that the systemd model is easier to grasp,
+> > then I'll listen.)
+>
+> For what it's worth, I consider myself new to both the upstart and the
+> systemd model, and for me the upstart event model has been pretty much
+> the only reason to prefer systemd over upstart (though after reading
+> Russ' opinion, that has changed a bit).
+>
+> For me, upstart was actually the reason for me switching from Debian to
+> Ubuntu for a while. I am less familiar with systemd, so it may well be
+> that I underestimate the complexities of the systemd model. However, I
+> am very certain in my dislike for the upstart approach.
+>
+>
+> My first point of criticism has already been described by Russ, but
+> maybe I can make it clearer by giving an example. In my opinion, the
+> following job looks completely harmless, and should not result in an
+> unbootable system (but at least on Ubuntu 13.10 it does, you have to
+> reboot with init=/bin/sh and remove/fix the evilJob.conf file):
+>
+> $ cat evilJob.conf
+> start on (mounted MOUNTPOINT=/var and started lightdm)
+> stop on runleves [016]
+> respawn
+> script
+>    exec /bin/sleep 60
+> end script
+>
+> I believe that the equivalent systemd unit (where dependencies are
+> specified with Requires=) works just fine.  It is not clear to me how
+> this can be "incrementally fixed" in upstart without fundamentally
+> changing the design.
+>
+>
+> My second point is that by treating dependencies as events, upstart does
+> not seem to truly recognize dependencies as such and is then unable to
+> resolve them.  For example, with the following two job files (created
+> according to the upstart cookbook, 6.32.2):
+>
+
+I think you raise a lot of good points in this email, but here you are
+saying something which may demonstrate your (understandable) confusion
+about the Upstart event model. Upstart does not treat dependencies as
+events. Often times, Upstart //jobs// treat dependencies as events (and the
+ones you wrote below do), but events do not signal a dependency. Just
+because you said that jobOne starts with jobTwo does not mean that jobOne
+needs jobTwo, just that during boot up jobOne will start with jobTwo. To
+express a dependency, jobTwo needs to have a "start on (event where I am
+needed)". If, for example, jobOne depends on a dbus interface of jobTwo,
+then jobTwo could have a "start on dbus ..." to show that dependency.
+Basically, to express dependencies in Upstart you express all the ways a
+job is needed inside of that job, not inside others. That said, Upstart
+developers and Ubuntu developers do not use Upstart this way and write jobs
+like you did below, so an Upstart system will most likely not act like I
+explained above (however this is not an inherent flaw in Upstart). I would
+also like to note that launchd acts the same exact way as I have described
+and had similar limitations. Furthermore, SystemStarter (Apple's previous
+init) acted in a very similar way to systemd:
+
+"The hardest part to manage during a launchd boot is dependencies.
+SystemStarter had a very simple system of dependencies that used the
+"Uses", "Requires", and "Provides" keys in the plist of a startup item.
+There are two main strategies when creating launch dependencies on [OS X] .
+Using IPC will allow the daemons to talk amongst themselves to work it out,
+or you can watch files or paths for changes. Using IPC is much more subtle
+than the SystemStarter's keys and requires more work from the developer,
+but it may* <https://en.wikipedia.org/wiki/Wikipedia:Citation_needed>*lead
+to cleaner and quicker startups." --
+https://en.wikipedia.org/wiki/Launchd#launchd
+
+I still think your points are relevant, however, because Upstart in Ubuntu
+acts in the same way as the below jobs, and Debian will most likely inherit
+that behavior if it uses Upstart.
+
+Happy New Year,
+
+Cameron Norman
+
+$ cat jobOne.conf
+> start on (starting jobTwo and runlevel stop on runlevel [016])
+> stop on runlevel [016]
+> respawn
+> script
+>     exec /bin/sleep 60
+> end script
+>
+> $ cat jobTwo.conf
+> start on runlevel [2345]
+> stop on runlevel [016]
+> respawn
+> script
+>     exec /bin/sleep 60
+> end script
+>
+>
+> I can type "service start jobOne", and upstart will willingly start
+> jobOne without starting jobTwo, or doing anything about the unfulfilled
+> dependency (not even a warning):
+>
+> root@ubuntu-kvm:/etc/init# service jobOne status
+> jobOne stop/waiting
+> root@ubuntu-kvm:/etc/init# service jobTwo status
+> jobTwo stop/waiting
+> root@ubuntu-kvm:/etc/init# service jobOne start
+> jobOne start/running, process 3177
+> root@ubuntu-kvm:/etc/init# service jobTwo status
+> jobTwo stop/waiting
+>
+> (on Ubuntu 13.10).
+>
+> As I understand, a systemd unit with "Requires=jobTwo" will not start
+> without jobTwo running.
+>
+> I guess this could be fixed by hardcoding a special treatment of the
+> "start on starting" event, but that would effectively be equivalent to
+> introducing a new kind of "depends on" stanza, and thus acknowledge that
+> the "everything is an event" model doesn't quite work.
+>
+>
+> Best,
+> Nikolaus
+>
+> --
+> Encrypted emails preferred.
+> PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+>
+>              »Time flies like an arrow, fruit flies like a Banana.«
+>
+>
+> --
+> To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
+> with a subject of "unsubscribe". Trouble? Contact
+> listmaster@lists.debian.org
+> Archive: http://lists.debian.org/87y52zuuaw.fsf@vostro.rath.org
+>
+>
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 00:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 00:45:05 GMT) (full text, mbox, link).

+ +

Message #2383 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Colin Watson <cjwatson@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Wed, 01 Jan 2014 16:41:19 -0800
+
+
On 01/01/2014 04:00 PM, Nikolaus Rath wrote:
+> My second point is that by treating dependencies as events, upstart does
+> not seem to truly recognize dependencies as such and is then unable to
+> resolve them.  For example, with the following two job files (created
+> according to the upstart cookbook, 6.32.2):
+> 
+> $ cat jobOne.conf
+> start on (starting jobTwo and runlevel stop on runlevel [016])
+> stop on runlevel [016]
+> respawn
+> script
+>     exec /bin/sleep 60
+> end script
+
+Wops, something went wrong with copy and paste here.
+
+This should be:
+
+$ cat jobOne.conf
+start on (starting jobTwo and runlevel [2345])
+stop on runlevel [016]
+respawn
+script
+    exec /bin/sleep 60
+end script
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 01:12:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 01:12:07 GMT) (full text, mbox, link).

+ +

Message #2388 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Cameron Norman <camerontnorman@gmail.com>
+
Cc: 727708@bugs.debian.org, Steve Langasek <vorlon@debian.org>
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Wed, 01 Jan 2014 17:09:55 -0800
+
+
Cameron Norman <camerontnorman@gmail.com> writes:
+> On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath <Nikolaus@rath.org> wrote:
+>
+>> Colin Watson <cjwatson@debian.org> writes:
+>> > The criticisms of Upstart's event model in the systemd position
+>> > statement simply do not make sense to me.  Events model how things
+>> > actually happen in reality; dependencies are artificial constructions on
+>> > top of them, and making them work requires the plethora of different
+>> > directives in systemd (e.g. Wants, which is sort of a non-depending
+>> > dependency) to avoid blocking the boot process on a single failing
+>> > service.  Yes, there are some bugs possible in the Upstart design, but I
+>> > don't agree that those are world-ending fundamental issues and I think
+>> > they're generally incrementally fixable.  The systemd design appears to
+>> > me to expose far more complexity to the user writing unit files, and I
+>> > think it's important that their mental model be as straightforward as
+>> > possible.
+>> >
+>> > (Now, I've been working with Upstart's model for years, and it's now a
+>> > pretty fundamental way of how I think of system operation; so if people
+>> > who are new to *both* models rather than partisans of one side or the
+>> > other consistently tell me that the systemd model is easier to grasp,
+>> > then I'll listen.)
+>>
+>> For what it's worth, I consider myself new to both the upstart and the
+>> systemd model, and for me the upstart event model has been pretty much
+>> the only reason to prefer systemd over upstart (though after reading
+>> Russ' opinion, that has changed a bit).
+>>
+>> For me, upstart was actually the reason for me switching from Debian to
+>> Ubuntu for a while. I am less familiar with systemd, so it may well be
+>> that I underestimate the complexities of the systemd model. However, I
+>> am very certain in my dislike for the upstart approach.
+>>
+>>
+>> My first point of criticism has already been described by Russ, but
+>> maybe I can make it clearer by giving an example. In my opinion, the
+>> following job looks completely harmless, and should not result in an
+>> unbootable system (but at least on Ubuntu 13.10 it does, you have to
+>> reboot with init=/bin/sh and remove/fix the evilJob.conf file):
+>>
+>> $ cat evilJob.conf
+>> start on (mounted MOUNTPOINT=/var and started lightdm)
+>> stop on runleves [016]
+>> respawn
+>> script
+>>    exec /bin/sleep 60
+>> end script
+>>
+>> I believe that the equivalent systemd unit (where dependencies are
+>> specified with Requires=) works just fine.  It is not clear to me how
+>> this can be "incrementally fixed" in upstart without fundamentally
+>> changing the design.
+>>
+>>
+>> My second point is that by treating dependencies as events, upstart does
+>> not seem to truly recognize dependencies as such and is then unable to
+>> resolve them.  For example, with the following two job files (created
+>> according to the upstart cookbook, 6.32.2):
+>>
+>
+> I think you raise a lot of good points in this email, but here you are
+> saying something which may demonstrate your (understandable) confusion
+> about the Upstart event model. Upstart does not treat dependencies as
+> events. Often times, Upstart //jobs// treat dependencies as events (and the
+> ones you wrote below do), but events do not signal a dependency. Just
+> because you said that jobOne starts with jobTwo does not mean that jobOne
+> needs jobTwo, just that during boot up jobOne will start with jobTwo. To
+> express a dependency, jobTwo needs to have a "start on (event where I am
+> needed)". If, for example, jobOne depends on a dbus interface of jobTwo,
+> then jobTwo could have a "start on dbus ..." to show that dependency.
+
+I think I understand what you're saying, thanks for the explanations!
+
+However, I can't say that this improved understanding has improved my
+opinion about upstart. If I understand correctly, this means that either
+
+a) every upstart job definition needs to explicitly list every possible
+   way in which another service may depend on it (and, furthermore,
+   every possible such dependency needs to have upstart integration so
+   that it can actually be used as an event)
+
+or
+
+b) a package providing jobOne that depends on jobTwo from another
+   package needs to patch the *other* package's configuration to add the
+   dependency information to jobTwo's definition.
+
+Neither of this sounds appealing to me at all, especially compared to
+systemd, where all you have to do is drop a Requires= line into jobOne's
+configuration.
+
+> Basically, to express dependencies in Upstart you express all the ways
+> a job is needed inside of that job, not inside others.  That said,
+> Upstart developers and Ubuntu developers do not use Upstart this way
+> and write jobs like you did below, so an Upstart system will most
+> likely not act like I explained above (however this is not an inherent
+> flaw in Upstart).
+
+Well, so what is the proper way to encode a dependency in an upstart job
+for Ubuntu (and presumable Debian) then? Apparently the proper way is
+extremly tedious and not used by anyone, and the other way isn't able to
+satisfy dependencies.
+
+
+Also, I would think that your statement above is a rather strong
+indication that this is *not* the upstart is meant to be used. Could the
+upstart developers comment on this?
+
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 01:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 01:36:04 GMT) (full text, mbox, link).

+ +

Message #2393 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Cameron Norman <camerontnorman@gmail.com>, 727708@bugs.debian.org, + Steve Langasek <vorlon@debian.org>
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Wed, 1 Jan 2014 17:33:15 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Jan 1, 2014 at 5:09 PM, Nikolaus Rath <Nikolaus@rath.org> wrote:
+
+> Cameron Norman <camerontnorman@gmail.com> writes:
+> > On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath <Nikolaus@rath.org> wrote:
+> >
+> >> Colin Watson <cjwatson@debian.org> writes:
+> >> > The criticisms of Upstart's event model in the systemd position
+> >> > statement simply do not make sense to me.  Events model how things
+> >> > actually happen in reality; dependencies are artificial constructions
+> on
+> >> > top of them, and making them work requires the plethora of different
+> >> > directives in systemd (e.g. Wants, which is sort of a non-depending
+> >> > dependency) to avoid blocking the boot process on a single failing
+> >> > service.  Yes, there are some bugs possible in the Upstart design,
+> but I
+> >> > don't agree that those are world-ending fundamental issues and I think
+> >> > they're generally incrementally fixable.  The systemd design appears
+> to
+> >> > me to expose far more complexity to the user writing unit files, and I
+> >> > think it's important that their mental model be as straightforward as
+> >> > possible.
+> >> >
+> >> > (Now, I've been working with Upstart's model for years, and it's now a
+> >> > pretty fundamental way of how I think of system operation; so if
+> people
+> >> > who are new to *both* models rather than partisans of one side or the
+> >> > other consistently tell me that the systemd model is easier to grasp,
+> >> > then I'll listen.)
+> >>
+> >> For what it's worth, I consider myself new to both the upstart and the
+> >> systemd model, and for me the upstart event model has been pretty much
+> >> the only reason to prefer systemd over upstart (though after reading
+> >> Russ' opinion, that has changed a bit).
+> >>
+> >> For me, upstart was actually the reason for me switching from Debian to
+> >> Ubuntu for a while. I am less familiar with systemd, so it may well be
+> >> that I underestimate the complexities of the systemd model. However, I
+> >> am very certain in my dislike for the upstart approach.
+> >>
+> >>
+> >> My first point of criticism has already been described by Russ, but
+> >> maybe I can make it clearer by giving an example. In my opinion, the
+> >> following job looks completely harmless, and should not result in an
+> >> unbootable system (but at least on Ubuntu 13.10 it does, you have to
+> >> reboot with init=/bin/sh and remove/fix the evilJob.conf file):
+> >>
+> >> $ cat evilJob.conf
+> >> start on (mounted MOUNTPOINT=/var and started lightdm)
+> >> stop on runleves [016]
+> >> respawn
+> >> script
+> >>    exec /bin/sleep 60
+> >> end script
+> >>
+> >> I believe that the equivalent systemd unit (where dependencies are
+> >> specified with Requires=) works just fine.  It is not clear to me how
+> >> this can be "incrementally fixed" in upstart without fundamentally
+> >> changing the design.
+> >>
+> >>
+> >> My second point is that by treating dependencies as events, upstart does
+> >> not seem to truly recognize dependencies as such and is then unable to
+> >> resolve them.  For example, with the following two job files (created
+> >> according to the upstart cookbook, 6.32.2):
+> >>
+> >
+> > I think you raise a lot of good points in this email, but here you are
+> > saying something which may demonstrate your (understandable) confusion
+> > about the Upstart event model. Upstart does not treat dependencies as
+> > events. Often times, Upstart //jobs// treat dependencies as events (and
+> the
+> > ones you wrote below do), but events do not signal a dependency. Just
+> > because you said that jobOne starts with jobTwo does not mean that jobOne
+> > needs jobTwo, just that during boot up jobOne will start with jobTwo. To
+> > express a dependency, jobTwo needs to have a "start on (event where I am
+> > needed)". If, for example, jobOne depends on a dbus interface of jobTwo,
+> > then jobTwo could have a "start on dbus ..." to show that dependency.
+>
+> I think I understand what you're saying, thanks for the explanations!
+>
+> However, I can't say that this improved understanding has improved my
+> opinion about upstart. If I understand correctly, this means that either
+>
+> a) every upstart job definition needs to explicitly list every possible
+>    way in which another service may depend on it (and, furthermore,
+>    every possible such dependency needs to have upstart integration so
+>    that it can actually be used as an event)
+>
+
+Pretty much all IPC mechanisms have integration into Upstart, so a lot of
+dependencies are covered.
+
+
+> or
+>
+> b) a package providing jobOne that depends on jobTwo from another
+>    package needs to patch the *other* package's configuration to add the
+>    dependency information to jobTwo's definition.
+>
+
+Yes. The patch would, however, be limited to a "or (...)" in the start on
+section. So it is not like the patch is going to change a ton.
+
+
+> Neither of this sounds appealing to me at all, especially compared to
+> systemd, where all you have to do is drop a Requires= line into jobOne's
+> configuration.
+>
+
+I agree, especially when one can have a "Requires=*.socket" or
+"Requires=*.bus" and get the same benefits.
+
+
+> > Basically, to express dependencies in Upstart you express all the ways
+> > a job is needed inside of that job, not inside others.  That said,
+> > Upstart developers and Ubuntu developers do not use Upstart this way
+> > and write jobs like you did below, so an Upstart system will most
+> > likely not act like I explained above (however this is not an inherent
+> > flaw in Upstart).
+>
+> Well, so what is the proper way to encode a dependency in an upstart job
+> for Ubuntu (and presumable Debian) then? Apparently the proper way is
+> extremly tedious and not used by anyone, and the other way isn't able to
+> satisfy dependencies.
+>
+>
+> Also, I would think that your statement above is a rather strong
+> indication that this is *not* the upstart is meant to be used. Could the
+> upstart developers comment on this?
+>
+>
+>
+Steve Langasek does not consider IPC activation to be integral to Upstart,
+so I assume he may disagree with me in some ways here. I am curious how he
+(and other Upstart devs) thinks your jobOne and jobTwo situation should be
+handled.
+
+Cheers,
+Cameron
+
+
+>
+> Best,
+> Nikolaus
+>
+> --
+> Encrypted emails preferred.
+> PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+>
+>              »Time flies like an arrow, fruit flies like a Banana.«
+>
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 02:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 02:21:04 GMT) (full text, mbox, link).

+ +

Message #2398 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: 727708@bugs.debian.org
+
Subject: requires in systemd
+
Date: Thu, 2 Jan 2014 03:17:44 +0100
+
+
> As I understand, a systemd unit with "Requires=jobTwo" will not start
+> without jobTwo running.
+If you request the start of "jobOne", without "jobTwo" running,
+systemd will start "jobTwo" in addition to "jobOne".
+
+There's also a Requisite= dependency, where if "jobTwo" isn't runnning,
+starting "jobOne" will fail.
+
+Zbyszek
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 06:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 06:21:04 GMT) (full text, mbox, link).

+ +

Message #2403 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Cameron Norman <camerontnorman@gmail.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Wed, 01 Jan 2014 22:18:18 -0800
+
+
Cameron Norman <camerontnorman@gmail.com> writes:
+>> > I think you raise a lot of good points in this email, but here you
+>> > are saying something which may demonstrate your (understandable)
+>> > confusion about the Upstart event model. Upstart does not treat
+>> > dependencies as events. Often times, Upstart //jobs// treat
+>> > dependencies as events (and the ones you wrote below do), but
+>> > events do not signal a dependency. Just because you said that
+>> > jobOne starts with jobTwo does not mean that jobOne needs jobTwo,
+>> > just that during boot up jobOne will start with jobTwo. To express
+>> > a dependency, jobTwo needs to have a "start on (event where I am
+>> > needed)". If, for example, jobOne depends on a dbus interface of
+>> > jobTwo, then jobTwo could have a "start on dbus ..." to show that
+>> > dependency.
+>>
+>> I think I understand what you're saying, thanks for the explanations!
+>>
+>> However, I can't say that this improved understanding has improved my
+>> opinion about upstart. If I understand correctly, this means that either
+>>
+[...]
+>> or
+>>
+>> b) a package providing jobOne that depends on jobTwo from another
+>>    package needs to patch the *other* package's configuration to add the
+>>    dependency information to jobTwo's definition.
+>>
+>
+> Yes. The patch would, however, be limited to a "or (...)" in the start on
+> section. So it is not like the patch is going to change a ton.
+
+No it's not a difficult change, but you'd be patching a *different
+packages* configuration file. I am not a dpkg expert, but I'm pretty
+sure this is not something a maintainer script should do.
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 06:21:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 06:21:08 GMT) (full text, mbox, link).

+ +

Message #2408 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: requires in systemd
+
Date: Wed, 01 Jan 2014 22:20:06 -0800
+
+
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
+>> As I understand, a systemd unit with "Requires=jobTwo" will not start
+>> without jobTwo running.
+>
+> If you request the start of "jobOne", without "jobTwo" running,
+> systemd will start "jobTwo" in addition to "jobOne".
+>
+> There's also a Requisite= dependency, where if "jobTwo" isn't runnning,
+> starting "jobOne" will fail.
+
+Thanks for the confirmation! This is what I concluded from the
+documentation, and also what I consider to be the right behavior.
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 09:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 09:39:04 GMT) (full text, mbox, link).

+ +

Message #2413 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Colin Watson <cjwatson@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Thu, 02 Jan 2014 10:33:51 +0100
+
+
Hi Colin,
+
+Le mercredi 01 janvier 2014 à 17:17 +0000, Colin Watson a écrit : 
+> > > Basically, systemd would be more compelling to me if it tried to do
+> > > less.  I don't expect to persuade systemd advocates of this, as I think
+> > > it amounts to different basic views of the world, but the basic approach
+> > > here is probably the single biggest factor influencing my position.
+
+> I'm referring to features that I don't think we'll need, not to logind
+> et al.
+
+Could you list the features you don’t think we’ll need in the list from
+the wiki? 
+      * Reliable service management through cgroups 
+      * Logging features 
+      * Multi-seat 
+      * Defense-in-depth security features 
+      * Centralized service startup and monitoring 
+      * timedated/hostnamed/… 
+      * D-Bus API for service control 
+      * Transparent virtual environment support 
+      * Watchdog 
+      * Initramfs support 
+      * Introspection and debugging 
+      * Configuration-less system 
+      * User sessions
+
+I’m curious as to what features you consider not relevant for Debian.
+
+Thanks,
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 11:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 11:00:04 GMT) (full text, mbox, link).

+ +

Message #2418 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Thu, 02 Jan 2014 11:58:45 +0100
+
+
Le mardi 31 décembre 2013 à 19:01 -0800, Steve Langasek a écrit : 
+> It's not true that it's unrelated.  In v205, logind hands off the cgroup
+> heirarchy creation to PID 1, precisely because it's preparing for the
+> anticipated future kernel requirement of a single cgroup writer.  
+
+This change would have happened sooner or later. The fact that logind
+used to work without systemd as init was purely coincidental, since
+logind was designed as an integral part of systemd from the very
+beginning (particularly because of the cgroups design). This specific
+change might has been triggered by anticipation for a kernel change (a
+change that still doesn’t exist), but if not for cgroups, it would have
+been for another reason.
+
+> If we're
+> expecting this "single cgroup writer" requirement to manifest, then it makes
+> sense to move cgroup writing out of logind.  The problem is with moving it
+> to PID1, causing increasingly tight coupling between the components of
+> systemd.
+
+Let’s imagine for a minute that the systemd developers would have
+listened to this request and put the cgroup manager outside of PID 1.
+
+Since systemd starts up everything it spawns using cgroups, the very
+first thing it would need to do would be to start up the cgroups manager
+at boot time, before anything else. For systems with systemd in the
+initramfs, the cgroups manager needs to be in the initramfs too.
+
+A new protocol would be introduced for PID 1 to talk to the cgroups
+manager, and every time a process is spawned, every time a query comes
+from an interface, PID 1 would talk to the cgroups manager through this
+protocol. Other processes would talk to PID 1 through one protocol, and
+to the cgroups manager through another one, having to gather the
+information afterwards, unable to obtain it in an atomic way.
+
+What, exactly, would be the benefit of such a situation for systemd
+users?
+
+> > Let’s say that GNOME migrates to systemd user sessions, like what is
+> > planned for GNOME 2.12 (yes, the version we intend to ship in jessie,
+> > ain’t that sweet).
+> 
+>   "It's important to note that with these patches, we still support
+>   non-systemd systems (as well as older systemd). How far into the future we
+>   do so is an open question, but it should not be too difficult to leave
+>   non-systemd systems with the previous model over the next few cycles."
+
+Oh but of course we can cripple our packages by disabling systemd
+support and live without user sessions. We can always do that. That was
+exactly my point.
+
+> There are
+> advantages to using systemd for user session management, particularly when
+> coupled with Wayland... 
+
+And maybe after upstart, you intend to try forcing Mir upon us when
+GNOME packages introduce a dependency on Wayland?
+
+> but these can just as well be delivered on top of
+> upstart rather than systemd.  It does not follow that GNOME upstream should
+> dictate to Debian that they adopt systemd rather than upstart.
+
+You’re acting like a good salesperson, but I’m afraid your product is
+inferior. These advantages cannot be provided by upstart. Just like for
+system services, the available features for user sessions are not
+comparable.
+
+> I think the current Debian GNOME team has a not-undeserved reputation for
+> being obstructionist with respect to bugfixes that require divergence from
+> upstream's stated direction.  
+
+This criticism is totally undeserved. The GNOME team is involved with
+GNOME upstream and understands where that stated direction comes from.
+And usually agrees with it, but not every time: we have maintained large
+sets of patches in Debian because of disagreements with the way
+PulseAudio and GDM were managed upstream. 
+
+It shouldn’t come as a surprise that it is hard for developers to
+respect the TC’s decisions when we see disrespectful sentences like the
+one above from some of its members.
+
+It strikes me that in general, the init system discussion has been
+polluted by hateful comments directed towards the GNOME, freedesktop and
+systemd projects and the Debian developers involved, by people who don’t
+even try to understand the technicalities behind. Too many people have
+let this happen, and too many developers have been hurt and demotivated.
+Do not expect a TC decision that would rely on political arguments
+instead of technical ones to improve that situation.
+
+> If the team demonstrated they were open to
+> contributions of the kind you described, volunteers to do the work would not
+> be hard to come by.
+
+You don’t just need volunteers to dig patches in the Ubuntu patch
+tracker and email them. You need volunteers to maintain the resulting
+packages.
+
+In other words, if you disagree with the ways the GNOME team maintains
+their packages, and appeal to the TC in order to change these ways,
+you’d better discuss with all current maintainers whether they are ready
+to abide by your rules, and have a proposal for what to put in the
+Uploaders: field of the resulting packages. I am pretty sure the same
+holds for a systemd package that would be required to remain at version
+204, stripped of stuff that doesn’t work with upstart.
+
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 12:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 12:33:05 GMT) (full text, mbox, link).

+ +

Message #2423 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Thu, 2 Jan 2014 12:31:14 +0000
+
+
On Wed, Jan 01, 2014 at 08:15:46PM +0200, Uoti Urpala wrote:
+> On Wed, 2014-01-01 at 17:17 +0000, Colin Watson wrote:
+> > On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
+> > > On the other hand even when using upstart as an init replacement, we'll
+> > > continue to use large chunks of systemd (logind, other dbus
+> > > services). I personally think "less is more" would only be a convincing
+> > > argument if we actually would not need the aditional features.
+> 
+> I think this counterargument, while valid, misses the major flaw in the
+> "would be more compelling if it tried to do less" claim:
+> 
+> You can simply not install any of these additional services if you don't
+> want them. This is completely trivial to do.
+
+It is indeed technically trivial, but I invite you to review your own
+responses to the binfmt-support thread to see why it isn't socially
+trivial.
+
+To put it another way, it will help to be careful with pronouns.  The
+"you" in your sentence necessarily doesn't refer to me (as the person
+objecting to the presence of certain features in this case), but to the
+Debian systemd maintainers.
+
+It's also not, in general, "trivial" to do something if it involves a
+massive argument, even if the patch would end up being a one-liner.
+Social costs are costs too.
+
+> > I'm referring to features that I don't think we'll need, not to logind
+> > et al.  So far I feel that the debates about those seem to be a bit
+> > circular and go something like this:
+> > 
+> >   A: This feature of systemd conflicts with something else; I'd rather
+> >      we didn't use it.
+> >   B: You can disable that, you know.
+> >   A: OK, let's disable it.
+> >   B: But you shouldn't disable it because that would make Debian systemd
+> >      less compatible with systemd on other distributions.
+> >   A: ...
+> 
+> Here B first correctly points out that the feature can be disabled if
+> desired, and thus the situation cannot be worse than with upstart - you
+> can do at least as well with systemd as you could with upstart. Then you
+> (A) have a disagreement with B about whether disabling the feature is
+> the _best_ way to handle the situation: B thinks that gaining
+> compatibility with other distributions is a bigger plus, and that
+> changing to the systemd way is an actual win over current situation,
+> rather than just neutral like the the upstart and disabling with systemd
+> cases.
+
+Perhaps this is the fundamental disagreement.  I do not necessarily
+consider compatibility as an end in itself.  Where Debian is already
+better than other distributions, we should remain better, not stick to a
+lowest common denominator for the sake of compatibility.
+
+I'm specifically referring here to cases where Debian already has a
+superior implementation of a given feature.  And to answer the strawman
+that several people have directed my way, I obviously have no objection
+to enabling features in the case where they're the best implementation
+available.  But it looks as though the default is to rank compatibility
+above quality of behaviour; that is certainly the impression I get from
+the e-mails I've received.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 13:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 13:45:04 GMT) (full text, mbox, link).

+ +

Message #2428 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: init system discussion status
+
Date: Thu, 2 Jan 2014 13:42:31 +0000
+
+
So we know where Colin, Steve, Russ and I stand on the main question.
+If we want to make a decision soon we need to start to thrash out the
+details so that we have something concrete to vote on.
+
+It would be helpful to know how far along the other TC members are.
+So:
+
+Andreas, Bdale, Don, Keith: please let us know what you're thinking,
+and what more information/discussion would be useful.
+
+FAOD I don't expect all the other TC members to read the whole
+discussion, which is very extensive.  Reading the primary statements
+by the other TC members who have reported so far is probably helpful.
+
+Given the politicisation of the dispute, and its very high status, I
+think it's important to have as many of the TC voting as possible.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 16:09:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 16:09:14 GMT) (full text, mbox, link).

+ +

Message #2433 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Thu, 02 Jan 2014 18:04:00 +0200
+
+
On Thu, 2014-01-02 at 12:31 +0000, Colin Watson wrote:
+> On Wed, Jan 01, 2014 at 08:15:46PM +0200, Uoti Urpala wrote:
+> > You can simply not install any of these additional services if you don't
+> > want them. This is completely trivial to do.
+> 
+> It is indeed technically trivial, but I invite you to review your own
+
+> It's also not, in general, "trivial" to do something if it involves a
+> massive argument, even if the patch would end up being a one-liner.
+> Social costs are costs too.
+
+So your position is essentially "systemd may be a technically better
+init, but it would allow maintainers to choose services I do not like,
+so I'll try to pre-empt that by choosing upstart"? The obvious
+alternative, and IMO correct choice, would be to decide the init on
+technical merits and handle choice of services separately (if needed).
+
+
+> > the _best_ way to handle the situation: B thinks that gaining
+> > compatibility with other distributions is a bigger plus, and that
+
+> Perhaps this is the fundamental disagreement.  I do not necessarily
+> consider compatibility as an end in itself.  Where Debian is already
+
+Maybe that's a basic disagreement in discussions concerning specific
+services, but certainly not for init system choice. What I view as the
+basic reasons I find your given rationale for choosing upstart
+completely unsatisfactory:
+
+* I don't think it's appropriate to use the init decision to push your
+views on the service choice question, when the latter could be decided
+independently regardless.
+* Your initial posting of the rationale represented it as a technical
+issue. Now you say it's a social one (pre-empting future arguments), but
+you still haven't given any real analysis to support your view. No
+mention of the obvious alternatives, no estimation of how common service
+disagreements would be, almost nothing at all. Basically you've only
+mentioned two discussions you didn't like; there's a gap from that to
+"and therefore this should be resolved by choosing a different init".
+
+I also do not consider it plausible that disagreements over which
+services to use could be so bad that they would override all other
+concerns in choosing an init system.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 16:09:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 16:09:17 GMT) (full text, mbox, link).

+ +

Message #2438 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ansgar Burchardt <ansgar@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: CTTE and Developer Buy-in [Re: Bug#727708: init system other points, and conclusion]
+
Date: Thu, 02 Jan 2014 08:05:01 -0800
+
+
Ansgar Burchardt <ansgar@debian.org> writes:
+
+> Sometimes I also wonder if a GR might be a better way to deal with the
+> decision as this feels more and more like an "political" or "opinion"
+> decision rather then a technical decision to me as tech-ctte members
+> have found both upstart and systemd to be suitable so far and only minor
+> reasons were responsible for the final decision.
+
+For what it's worth, I actually disagree with this.  I believe upstart is
+technically unsuitable to be Debian's init system.
+
+Now, the upstart maintainers are committing to implement a whole bunch of
+new functionality in upstart to *make* it suitable if we adopt it, so
+that's a situation that could change.  But, at the present time, I think
+upstart is clearly technically inferior to systemd, and not in just minor
+ways.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 16:12:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 16:12:04 GMT) (full text, mbox, link).

+ +

Message #2443 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: CTTE and Developer Buy-in [Re: Bug#727708: init system other points, and conclusion]
+
Date: Thu, 02 Jan 2014 08:09:44 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> And, despite the fact that the decision has become very politicised (to
+> some extent along the lines of preexisting camps of strongly disagreeing
+> contributors), I think it is primarily a technical decision.
+
+I think this is a remarkable statement given that you're the primary one
+who has been politicizing it.  I am really unsure how to respond usefully
+to the outright attacks you have been posting against both systemd
+upstream and other maintenance teams in Debian.  The degree to which you
+are assuming not only bad faith but malicious motives among other people
+in the free software community is deeply disturbing to me.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 16:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 16:18:04 GMT) (full text, mbox, link).

+ +

Message #2448 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: CTTE and Developer Buy-in [Re: Bug#727708: init system other points, and conclusion]
+
Date: Thu, 02 Jan 2014 08:15:25 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> As the TC, I think we have two options for the process:
+
+> (a) Make a decision based on our assessment of the merits; that
+>     includes considering the strength and health of the communites
+>     behind each project.  But for me it doesn't include consideration
+>     of their raw popularity or unpopularity in the Debian ecosystem.
+>     Expect a GR if our decision is too unpopular.
+
+> (b) Decline to make a decision and propose a GR.
+
+> Colin was casting about for a plausible intermediate approach perhaps
+> involving a straw poll.  I'm explaining why I think that's not a good
+> idea; perhaps even a worse idea than (b).
+
+> I don't think any of the TC are going to propose (b).  Perhaps we
+> should put (b) on the TC ballot for form's sake; I guess most of the
+> TC would vote it above FD.
+
+I had actually been considering proposing (b) be on the ballot based on
+Guillem and Anthony's reaction.
+
+If the criteria that we're using to decide between systemd and upstart is
+about discomfort with systemd's upstream development practices and their
+attempt to create a unified and consistent experience, I think a GR may be
+a better way to decide this question.  That's not a technical question;
+that's a question of overall project direction, a question about whether
+we force loose coupling even when our upstreams are preferring tight
+coupling.  And if we are going to drop some core flexibility inside Debian
+to get tighter integration and (at least IMO) technically superior
+solutions.  It's also to some extent a question about how much portability
+should drive our core software adoption, which again is more of a
+wide-ranging question about project direction than it is a purely
+technical decision.
+
+That's starting to sound much more like the sort of decision that should
+be decided by GR rather than by a small group of people.  And as
+previously mentioned, we have the advantage of being able to go into the
+GR with a large set of well-researched data that we didn't have before.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 16:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 16:27:05 GMT) (full text, mbox, link).

+ +

Message #2453 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: CTTE and Developer Buy-in [Re: Bug#727708: init system other points, and conclusion]
+
Date: Thu, 2 Jan 2014 16:25:13 +0000
+
+
Russ Allbery writes ("Bug#727708: CTTE and Developer Buy-in [Re: Bug#727708: init system other points, and conclusion]"):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > I don't think any of the TC are going to propose (b).  Perhaps we
+> > should put (b) on the TC ballot for form's sake; I guess most of the
+> > TC would vote it above FD.
+> 
+> I had actually been considering proposing (b) be on the ballot based on
+> Guillem and Anthony's reaction.
+
+I have no objection to (b) being on the ballot.  (Obviously.)  If we
+are to reject it it would be good to do so explicitly.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 16:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 16:30:04 GMT) (full text, mbox, link).

+ +

Message #2458 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Thu, 02 Jan 2014 17:26:55 +0100
+
+
]] Colin Watson 
+
+> Perhaps this is the fundamental disagreement.  I do not necessarily
+> consider compatibility as an end in itself.  Where Debian is already
+> better than other distributions, we should remain better, not stick to a
+> lowest common denominator for the sake of compatibility.
+
+I think it might well be the fundamental disagreement, since I believe
+there is value by us helping other distributions catch up and
+accomodating their use cases where we reasonably can.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 16:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 16:39:04 GMT) (full text, mbox, link).

+ +

Message #2463 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart dependency handling
+
Date: Thu, 02 Jan 2014 08:35:06 -0800
+
+
I wanted to lift this out of the thread it was buried in and see if I'm
+understanding it correctly, since if I am, it seems like a significant
+issue.
+
+Cameron Norman <camerontnorman@gmail.com> writes:
+
+> I think you raise a lot of good points in this email, but here you are
+> saying something which may demonstrate your (understandable) confusion
+> about the Upstart event model. Upstart does not treat dependencies as
+> events. Often times, Upstart //jobs// treat dependencies as events (and
+> the ones you wrote below do), but events do not signal a
+> dependency. Just because you said that jobOne starts with jobTwo does
+> not mean that jobOne needs jobTwo, just that during boot up jobOne will
+> start with jobTwo. To express a dependency, jobTwo needs to have a
+> "start on (event where I am needed)". If, for example, jobOne depends on
+> a dbus interface of jobTwo, then jobTwo could have a "start on dbus ..."
+> to show that dependency.
+
+But does that actually provide a dependency?  In other words, if the
+sysadmin manualy starts jobTwo, does that either prevent jobTwo from
+starting becaus the dbus service isn't available, or start the dbus
+service?  Or is jobTwo just started without dbus to cope as best it can?
+
+Having actual dependencies strikes me as an important technical feature.
+I don't like the idea of the init system not caring about whether the
+prerequisites for a job are met and just blindly starting it anyway.
+We're all somewhat used to that behavior, since that's what we get with
+sysvinit, but it's inherently fragile.  We can try to hold all software
+packaged in Debian to the standard that it will fail cleanly and without
+problems if started in the wrong sequence, but it still seems to preserve
+the possibility of a whole class of bugs that systemd would close.
+
+Assuming, that is, that the understanding expressed on this thread is
+correct.
+
+Note that dependency handling is relevant to socket activation as well.
+As I discovered when experimenting with systemd, for reproducible
+behavior, you want to ensure that the job is always started with socket
+activation if that's how you have it configured; if not, such things as
+bind addresses may not be honored, which could even pose security issues.
+That includes the case where the job is configured to not start by default
+but is manually started by the administrator.
+
+Now, you could introduce a new dependency model just for socket activation
+or treat socket activation as part of that service rather than (as systemd
+does) a separate service that's tightly coupled with the daemon.  So this
+is addressable by making socket setup a special case of sorts, such as by
+converting the request for the socket into a method event that is
+triggered before starting the daemon itself.  But all that does feel
+harder to understand to me, particularly since you really want the sockets
+started independently of the jobs and early in the boot process so that
+other services can start talking to them, which makes the method call
+approach tricky.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 16:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 16:54:04 GMT) (full text, mbox, link).

+ +

Message #2468 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org, Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Thu, 02 Jan 2014 09:50:58 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Josselin Mouette <joss@debian.org> writes:
+
+> It shouldn’t come as a surprise that it is hard for developers to
+> respect the TC’s decisions when we see disrespectful sentences like the
+> one above from some of its members.
+
+I agree.
+
+We are of course each entitled to hold opinions about such things, but I
+would strongly prefer if we could all try *very* hard to keep such
+assertions out of TC discussion.  They have no place here.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 16:54:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 16:54:07 GMT) (full text, mbox, link).

+ +

Message #2473 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: CTTE and Developer Buy-in [Re: Bug#727708: init system other points, and conclusion]
+
Date: Thu, 02 Jan 2014 17:51:11 +0100
+
+
]] Colin Watson 
+
+> On Tue, Dec 31, 2013 at 05:50:59PM -0800, Don Armstrong wrote:
+> > On Wed, 01 Jan 2014, Tollef Fog Heen wrote:
+> > > and I think it'd be a shame if we ended up losing or demotivating a
+> > > good bunch of good developers again.
+> > 
+> > Pretty much every time the CTTE makes a ruling, someone is going to be
+> > annoyed or demotivated. Easy, non-contentious decisions never make it to
+> > us. 
+> > 
+> > If there are concrete ways we can be better at making sure that it's
+> > clear developers concerns are being heard and taken into account which
+> > we are not already doing, I'd certainly like to hear them.
+> 
+> Is there any useful way we could take a reasonably quick non-binding
+> straw poll of developers?  Sort of an "if we voted a particular way, is
+> it likely that we would be on the wrong side of developer opinion".
+
+In addition to the popcon numbers referenced from Sjoerd, we have the
+numbers from Michael's systemd survey in May 2013.  The numbers there
+were 35%/30%/33% for yes/dunno/no for systemd as default init when only
+counting DD/DMs/package maintainers
+
+Of course, those numbers might have changed since then.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 17:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 17:09:04 GMT) (full text, mbox, link).

+ +

Message #2478 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart dependency handling
+
Date: Thu, 2 Jan 2014 09:06:26 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Thu, Jan 2, 2014 at 8:35 AM, Russ Allbery <rra@debian.org> wrote:
+
+> I wanted to lift this out of the thread it was buried in and see if I'm
+> understanding it correctly, since if I am, it seems like a significant
+> issue.
+>
+> Cameron Norman <camerontnorman@gmail.com> writes:
+>
+> > I think you raise a lot of good points in this email, but here you are
+> > saying something which may demonstrate your (understandable) confusion
+> > about the Upstart event model. Upstart does not treat dependencies as
+> > events. Often times, Upstart //jobs// treat dependencies as events (and
+> > the ones you wrote below do), but events do not signal a
+> > dependency. Just because you said that jobOne starts with jobTwo does
+> > not mean that jobOne needs jobTwo, just that during boot up jobOne will
+> > start with jobTwo. To express a dependency, jobTwo needs to have a
+> > "start on (event where I am needed)". If, for example, jobOne depends on
+> > a dbus interface of jobTwo, then jobTwo could have a "start on dbus ..."
+> > to show that dependency.
+>
+> But does that actually provide a dependency?  In other words, if the
+> sysadmin manualy starts jobTwo, does that either prevent jobTwo from
+> starting becaus the dbus service isn't available, or start the dbus
+> service?  Or is jobTwo just started without dbus to cope as best it can?
+>
+
+That is where you have to start going down the dependency list and make
+sure that dbus is (a) pretty much always started when it is possible for
+jobTwo to be started or (b) started when any service connects to dbus's
+socket (I think /run/dbus/system_bus_socket or whatever for the system
+socket, and then ~/.dbus/session-bus). The dbus socket address is actually
+stored in an environment variable, so it is pretty easy to handle in
+Upstart jobs.
+
+
+> Having actual dependencies strikes me as an important technical feature.
+> I don't like the idea of the init system not caring about whether the
+> prerequisites for a job are met and just blindly starting it anyway.
+> We're all somewhat used to that behavior, since that's what we get with
+> sysvinit, but it's inherently fragile.  We can try to hold all software
+> packaged in Debian to the standard that it will fail cleanly and without
+> problems if started in the wrong sequence, but it still seems to preserve
+> the possibility of a whole class of bugs that systemd would close.
+>
+> Assuming, that is, that the understanding expressed on this thread is
+> correct.
+>
+> Note that dependency handling is relevant to socket activation as well.
+> As I discovered when experimenting with systemd, for reproducible
+> behavior, you want to ensure that the job is always started with socket
+> activation if that's how you have it configured; if not, such things as
+> bind addresses may not be honored, which could even pose security issues.
+> That includes the case where the job is configured to not start by default
+> but is manually started by the administrator.
+>
+> Now, you could introduce a new dependency model just for socket activation
+> or treat socket activation as part of that service rather than (as systemd
+> does) a separate service that's tightly coupled with the daemon.  So this
+> is addressable by making socket setup a special case of sorts, such as by
+> converting the request for the socket into a method event that is
+> triggered before starting the daemon itself.  But all that does feel
+> harder to understand to me, particularly since you really want the sockets
+> started independently of the jobs and early in the boot process so that
+> other services can start talking to them, which makes the method call
+> approach tricky.
+>
+
+AFAIU, one can just use:
+
+start on socket PROTO=unix SOCKET_PATH=/run/dbus/system_bus_socket
+
+for the system job and:
+
+start on socket PROTO=unix SOCKET_PATH=DBUS_SESSION_BUS_ADDRESS
+
+for the session job. If I am correct, this will ensure that dbus will be
+started whenever a job tries to create a dbus interface (or access one).
+This is much less verbose than every single dbus using service listing dbus
+as a dependency. I would very much like to know what Steve Langasek's
+thoughts are on this.
+
+Something else that is relevant to this discussion is this Upstart cookbook
+section:
+http://upstart.ubuntu.com/cookbook/#critique-of-dependency-based-init-systems
+.
+
+Cheers,
+Cameron Norman
+
+
+>
+> --
+> Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+>
+>
+> --
+> To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
+> with a subject of "unsubscribe". Trouble? Contact
+> listmaster@lists.debian.org
+> Archive: http://lists.debian.org/87mwjeqr45.fsf_-_@windlord.stanford.edu
+>
+>
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 17:39:23 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 17:39:23 GMT) (full text, mbox, link).

+ +

Message #2483 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Cc: Thomas Goirand <zigo@debian.org>
+
Subject: Bug#727708: additional OpenRC information
+
Date: Thu, 02 Jan 2014 09:25:46 -0800
+
+
As I mentioned in some of my previous notes, I was unable to evaluate
+OpenRC in a meaningful way during my general experiments for a few
+reasons.  My impression was formed based on previous discussion and what
+documentation I could find, which was fairly minimal.
+
+Thomas Goirand sent me considerably more information, including some
+details about OpenRC project goals that corrects information in my
+original writeup.  With his permission, I'm including that here for the
+benefit of everyone else who is following this debate.
+
+Thomas, please follow up with anything that I left out or anything else
+that you think people should be aware of.
+
+Thomas Goirand <zigo@debian.org> writes:
+> I could read at 727708@bugs.debian.org the following from you:
+
+>> If we're going to the effort of
+>> replacing init systems and changing our startup scripts, a bare
+>> minimum requirement for me is that we at least address the known
+>> weaknesses of the sysvinit mechanism, namely:
+
+>> * Lack of integration with kernel-level events to properly order
+>> startup.
+>> * No mechanism for process monitoring and restarting beyond inittab.
+>> * Heavy reliance on shell scripting rather than declarative syntax.
+>> * A fork and exit with PID file model for daemon startup.
+
+>> My impression of OpenRC is that it is not attempting to solve these
+>> issues in the same way that systemd and upstart are.
+
+> I'm not sure how I should take this. Yes, OpenRC isn't doing "the same
+> way", though it's addressing all of the above points. Did you really try
+> OpenRC?
+
+> FYI, OpenRC does understand and use cgroups. So that's for the last
+> point above. OpenRC does use runscript so this address the "reliance on
+> shell scripting rather than declarative syntax". OpenRC is currently
+> implementing the use of "monit" so it can monitor and restart processes,
+> without reinventing the wheel (monit has been around for years...). As
+> much as I know, that part is nearly done, though it needs to have a few
+> issues solved (that's what I heard from upstream). I think this is an
+> awesome approach to use monit. If you haven't used monit, I would
+> recommend you to try it. It's modular and checks for the actual service
+> to be running rather than a process running.
+
+> The only thing which it might lack support of would be kernel-level
+> events, but I think this is really overrated in the current discussion,
+> and also it can be handled most of the time with some very easy to
+> implement loops (there's some examples in some of the Gentoo runscripts).
+
+> I think you should re-evaluate OpenRC. Yes, it's not as big as Upstart
+> and Systemd (and for me, that's a *good* point, not a bad point), though
+> it's not as bad as you describe it.
+
+> If the tech committee was to decide to switch to systemd or upstart, I
+> think one of the key decision that could come with it would be to
+> deprecate sysv-rc in the favor of OpenRC (with or without mandatory
+> support in linux versions of Debian, that's up to the tech-ctte to
+> decide...).
+
+and, in another message, some details on how to test:
+
+> FYI, I have just uploaded a new version of OpenRC to the new queue. It's
+> IMO back into shape again after fixing the /sbin/rc and /sbin/runscript
+> renames, though there's still some corner cases to fix, like "apt-get
+> install --reinstall initscripts" fails because there's no runlevels in
+> the LSB headers of these scripts (I don't understand why yet though). I
+> don't think it'd be hard to fix that one though...
+
+> Anyway, you can try OpenRC from the Git repository on Alioth:
+
+> git clone ssh://git.debian.org/git/collab-maint/openrc.git
+> cd openrc
+> ./debian/rules make-orig-file
+> git-buildpackage
+
+> Then simply dpkg -i the resulting libs and openrc itself. This should
+> normally work on both Wheezy and Sid, and in all ports (I tested it on
+> kFreeBSD and amd64).
+
+> A quick run-through now. Once you've installed it, it wont know about
+> started stuff, so the first reboot will not shutdown correctly. I'm not
+> really sure how to fix the first reboot case currently. Though after the
+> first reboot, you can try "rc-status" which is a nice stuff.
+
+> I couldn't change "service" utility since it's owned by sysv-utils and
+> not OpenRC, though I have updated invoke-rc.d so that it continues to
+> update the symlinks in /run/openrc/started (so rc-status will work as
+> expected). Unless the sheebang is changed from /bin/sh to
+> /sbin/openrc-run in scripts in /etc/init.d, starting the init scripts
+> "by hand" with /etc/init.d/<whatever> start/stop will not update the
+> status either. All this is fine since everything should be using
+> update-rc.d and invoke-rc.d, it's just nice to other ways to start/stop
+> daemons work with rc-status support as well for our users.
+
+> I would recommend that you also have a look into /etc/rc.conf, and play
+> a bit with the options. Note that "rc_parrallel" does work, even though
+> it has an ugly output.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 17:45:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 17:45:15 GMT) (full text, mbox, link).

+ +

Message #2488 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Thu, 02 Jan 2014 10:42:30 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> Andreas, Bdale, Don, Keith: please let us know what you're thinking,
+> and what more information/discussion would be useful.
+
+Right.  I've meant to post something before now, but after returning
+home from a family road trip over the holidays, I was hit by a nasty
+cold.  Feeling a bit better today.
+
+I could spend a lot of time talking about what I learned from dealing
+with various init system and on-demand daemon launching approaches long
+before Linux even existed, but since I suspect that's better done over
+beers at places like Debconf than here, I'll simply summarize by saying
+that I've found sysvinit adequate but never satisfying.  Clinging to it
+when there are superior options available would not make sense to me.
+
+There are things about OpenRC that I find really appealing, but I agree
+that it seems too immature to even evaluate well, and thus I don't think
+it is a credible alternative to be the default for Debian GNU/Linux. 
+
+So I dove in and have spent quite a bit of time learning about and
+studying both systemd and upstart... both of which I've basically
+steered clear of in the past.  I've done an *immense* amount of reading,
+talked to many people with both strong and weak opinions about both
+systems, and spent a modest amount of time working with the VMs that
+Steve so graciously provided us to learn what each system "feels like"
+in real use.  I have not (yet) used either init system on any of the
+machines I personally admin. 
+
+It's now clear to me that systemd is technically superior as an init
+system to upstart.  I find the dependency approach easier to think about
+and work with, unit files seem quite easy to craft and read, I like the
+status reporting and logging tools, and I find myself agreeing more with
+Russ that with Ian about the best way to augment daemons that might
+benefit from it with a readiness protocol.
+
+It bothers me on some philosophical level that so much functionality
+that I'd like to keep conceptually separate from an init system is being
+pulled in to the systemd upstream.  And as someone who has spent much of
+my professional career working with non-x86 systems and who has worked
+with many non-Linux kernels in different contexts, I've found the
+anti-portability rhetoric from Lennart, et al, particularly grating.
+
+But a long time ago, in a rec.crafts.metalworking post about teachers, a
+fellow named Fitch Williams wrote that "in any endeavour it is a fact
+that you have to succeed with the people who are willing to
+participate."  This sentiment struck me as true enough that I added it 
+to my quotes file, and it's one I'm often reminded of when working on
+Debian, where we are all volunteers who choose to be here and work on
+things that matter to us individually.  I find it particularly relevant
+in the context of this init system discussion... because whether I "like
+it" or not, lots of really good work is being done by people who choose
+to associate themselves with the systemd project, much of which I agree
+is important to Debian.  
+
+> FAOD I don't expect all the other TC members to read the whole
+> discussion, which is very extensive.
+
+Actually, I have.  I'd like to take this opportunity to thank Ian and
+Russ for their detailed and very thoughtful write-ups, and the various
+other contributors of technical input to the discussion these provoked.
+My opinions were formed independently, but reading through these threads
+really helped raise my confidence in those opinions.
+
+So, to summarize, I think systemd should be our choice for a new default
+init system for Debian GNU/Linux.  Where I think we still need to focus
+attention is on how to manage the transition, and how to make *any* new
+init system default for Linux palatable for Debian's non-Linux ports.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 18:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 18:00:05 GMT) (full text, mbox, link).

+ +

Message #2493 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Thu, 02 Jan 2014 09:57:11 -0800
+
+
Russ Allbery <rra@debian.org> writes:
+> This message is about a transition plan for an init system replacement and
+> about how to handle portability to our non-Linux ports.  I'm keeping the
+> same subject as Ian's message on the same basic topics and attaching it to
+> the same thread, but this is more of a separate writeup than a reply.
+[...]
+>
+> 5. Support for the other init system that was not chosen should be handled
+>    in the same fashion, should a team choose to pursue it.  If we select
+>    systemd, package maintainers should still be willing to merge
+>    contributed upstart configuration, with the understanding that they
+>    can't test it and any support is on a best-effort basis only.
+>    Similarly, if we select upstart, package maintainers should be willing
+>    to merge systemd unit files and to enable upstream systemd support
+>    where requested and where it doesn't interfere with the operation of
+>    the daemon under upstart, with the understanding that the package
+>    maintainer is not committing to testing or directly supporting this
+>    configuration.
+
+Thanks all a lot for all your detailed writeups Russ. It is much
+appreciated.
+
+
+I think there is one additional questions that will probably need to be
+decided by the tc but hasn't really been discussed yet:
+
+Will packages that explicity depend on a (non-default) init system be
+allowed in Debian?
+
+
+For example, if I want to package a program that depends on a feature
+available only in upstart, but systemd was chosen as the default init
+system, can I upload this package with a depends on upstart, or will
+this be rejected?
+
+If such packages will not be allowed in the archive, does the burden of
+making them work with the default init lie on the maintainers of the
+default init (to add the missing feature), or the package maintainer (to
+work around the features absence if he wants the package in Debian)?
+
+
+The specific situation that I have in mind is of course when upstart
+becomes the default, and gnome becomes dependent on systemd, but I think
+the question is larger than just this example.
+
+
+Best,
+-Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 18:00:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 18:00:14 GMT) (full text, mbox, link).

+ +

Message #2498 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Bdale Garbee <bdale@gag.com>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Thu, 2 Jan 2014 17:59:04 +0000
+
+
Bdale Garbee writes ("Bug#727708: init system discussion status"):
+> [stuff]
+
+Thanks for posting your views.
+
+You'll have seen Russ's comments on the details and loose ends as I
+call them.  Russ and I were mostly agreed on these points.
+
+I have written a draft resolution from my own point of view and
+checked it into the tech-ctte git repo.  Perhaps some of it is useful.
+Ansgar commented a bit on it on IRC.  I guess I should post it.
+
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > FAOD I don't expect all the other TC members to read the whole
+> > discussion, which is very extensive.
+> 
+> Actually, I have.  [...]
+
+Thanks :-).
+
+> So, to summarize, I think systemd should be our choice for a new default
+> init system for Debian GNU/Linux.  Where I think we still need to focus
+> attention is on how to manage the transition, and how to make *any* new
+> init system default for Linux palatable for Debian's non-Linux ports.
+
+I agree with the latter part of this.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 18:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Raphael Hertzog <hertzog@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 18:06:05 GMT) (full text, mbox, link).

+ +

Message #2503 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Raphael Hertzog <hertzog@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: CTTE and Developer Buy-in [Re: Bug#727708: init + system other points, and conclusion]
+
Date: Thu, 2 Jan 2014 19:02:07 +0100
+
+
On Thu, 02 Jan 2014, Russ Allbery wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> 
+> > And, despite the fact that the decision has become very politicised (to
+> > some extent along the lines of preexisting camps of strongly disagreeing
+> > contributors), I think it is primarily a technical decision.
+> 
+> I think this is a remarkable statement given that you're the primary one
+> who has been politicizing it.  I am really unsure how to respond usefully
+> to the outright attacks you have been posting against both systemd
+> upstream and other maintenance teams in Debian.  The degree to which you
+> are assuming not only bad faith but malicious motives among other people
+> in the free software community is deeply disturbing to me.
+
++1
+
+Thank you for saying it so clearly while still avoiding the ad-hominem
+attack. I didn't find a good way to say it without picking on Ian's
+behaviour but you express it very well.
+
+Cheers,
+-- 
+Raphaël Hertzog ◈ Debian Developer
+
+Discover the Debian Administrator's Handbook:
+→ http://debian-handbook.info/get/
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 18:06:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to james.hunt@ubuntu.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 18:06:08 GMT) (full text, mbox, link).

+ +

Message #2508 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: James Hunt <james.hunt@ubuntu.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: tech-ctte: Decide which init system to default to in Debian.
+
Date: Thu, 02 Jan 2014 18:03:11 +0000
+
+
On Mon, Dec 30, 2013 at 02:03:22 -0800, Steve Langasek wrote:
+> The upstart "session init" runs as the user, not as root.
+Note that a session init can run as root ("sudo init --user") but yes,
+conventionally they are run as non-priv users.
+
+> I'm not sure if
+> upstart as a user session has any dependencies on upstart being PID 1.
+> Cc:ing James, who would know better - James, do you know if upstart session
+> init works on non-upstart systems?
+I've got a Session Init running fine on Wheezy with SysVinit as PID 1.
+To do this:
+
+1) sudo apt-get install libnih1
+2) sudo apt-get -y build-dep upstart
+3) Download an upstart release (or branch the code from lp:upstart).
+4) Unpack.
+5) autoreconf -fi && ./configure && make
+6) Manually install the following:
+
+util/initctl from the build tree as /sbin/initctl
+init/init from the build tree as /sbin/session-init.
+
+7) Setup a few basics and create a single job to start a terminal (no WM :)
+
+mkdir -p ~/.config/upstart
+mkdir -p ~/.cache/upstart
+cat >>~/.xsession<<EOT
+XDG_RUNTIME_DIR=/some/where
+export XDG_RUNTIME_DIR
+mkdir -p "$XDG_RUNTIME_DIR"
+exec /sbin/session-init --user
+EOT
+chmod 755 ~/.xsession
+
+cat >>~/.config/upstart/terminal.conf<<EOT
+start on startup
+exec gnome-terminal
+EOT
+
+8) Login.
+
+
+Kind regards,
+
+James.
+--
+James Hunt
+____________________________________
+#upstart on freenode
+http://upstart.ubuntu.com/cookbook
+https://lists.ubuntu.com/mailman/listinfo/upstart-devel
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 18:18:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 18:18:08 GMT) (full text, mbox, link).

+ +

Message #2513 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Thu, 2 Jan 2014 18:16:25 +0000
+
+
Ian Jackson writes ("Re: Bug#727708: init system discussion status"):
+> I have written a draft resolution from my own point of view and
+> checked it into the tech-ctte git repo.  Perhaps some of it is useful.
+> Ansgar commented a bit on it on IRC.  I guess I should post it.
+
+Here's my draft.
+
+
+Those who prefer systemd will want to s/upstart/systemd/ and vice
+versa, obviously.  Aside from that:
+
+0,3,4,5,8,10 are probably not very controversial (mutatis mutandi
+   for those who prefer systemd).
+
+2 (non-Linux ports) needs attention in the systemd case.
+
+6 will not be controversial (mutatis mutandi) except:
+
+6C (and the consequential paragraphs) may be quite controversial even
+   amongst those who prefer upstart.  This needs further discussion.
+
+7 probably needs to deal with systemd too in any case; the
+   corresponding feature is "guess main pid" I think.
+
+9's usefulness was doubted by Russ, but I hope the substance at least
+   is uncontroversial.
+
+11 is probably going to be thought inappropriate but I wanted to at
+   least float it.
+
+Of course some of you may want to take a completely different
+approach, perhaps specifying things in much less detail.
+
+For the "punt it to a GR" option, I don't think we should specify this
+level of detail about compatibility, policy, accepting patches etc.
+We should provide at least four draft ballot options (upstart,
+systemd, sysvinit, openrc) and request that the DPL propose the GR as
+the TC is too unweildy for handling amendments for something
+time-critical like this.  The ballot options we suggest should all
+state that sysvinit is still mandatory to support in jessie.
+
+Thanks,
+Ian.
+
+| Rubric:
+| 
+| 0. We decide as follows (Constitution 6.1(1),(2)).  Text in square
+|    brackets "[]" is non-binding advice (Constitution 6.1(5)).  We
+|    require the Policy Editors (Constitution 6.1(1)) to make the policy
+|    changes they think appropriate to give effect to this resolution.
+| 
+| Choice of init system:
+| 
+| 1. The default init(1) in jessie will be upstart.
+|
+| 2. Architectures which do not currently support upstart should try to
+|    port it.  If this is not achieved in time, those architectures may
+|    continue to use sysvinit.  [ Non-use of upstart should not be a
+|    criterion for architecture qualification status in jessie. ]
+| 
+| 3. At least in jessie, unless a satisfactory compatibility approach is
+|    developed and deployed (see paragraph 10), packages must continue
+|    to provide sysvinit scripts.  Lack of a sysvinit script (for a
+|    daemon which contains integration with at least one other init
+|    system) is an RC bug in jessie.
+| 
+|    [ After jessie, the policy editors may drop this requirement;
+|    perhaps entirely, or perhaps in favour of a requirement to provide
+|    at least one of sysvinit or systemd integration.  The policy
+|    editors may wish to refer this decision to us in due course. ]
+| 
+| Policy is not ready, so hold off on updating all packages:
+| 
+| 4. [ The current Debian policy for upstart, in the policy manual,
+|    could do with some improvement and enhancement.  The current Debian
+|    policy for systemd needs to be finished and agreed, and then
+|    incorporated in the policy manual.  We encourage the maintainers of
+|    upstart and systemd, and others, to submit relevant policy
+|    enhancements.
+| 
+|    Contributors should delay introducing patches for native support
+|    for upstart, systemd or openrc until the relevant Debian Policy is
+|    declared, by the Policy editors, to be ready. ]
+| 
+| Support requirements for packages:
+| 
+| 5. Subject to paragraphs 4 and 6 of this resolution, packages should
+|    provide native upstart jobs where relevant.
+| 
+|    Lack of native upstart support is not a release-critical bug for
+|    jessie.
+| 
+|    [ Patches for upstart support should be treated the way "release
+|    goals" have been treated in the past; so, for example, there should
+|    be a low NMU threshold for patches meeting suitable criteria.
+| 
+|    The Debian Project Leader and/or applicable Delegates should give
+|    effect to this part of our decision. ]
+| 
+| 6. [ Maintainers should accept reasonable patches for native upstart,
+|    systemd and openrc support.
+| 
+|    A. A reasonable patch:
+|     (i) is proposed after the relevant policy is finalised;
+|     (ii) complies with that policy;
+|     (iii) complies with the advice and requirements in this
+|         resolution; and
+|     (iv) takes the approaches to integration chosen by upstream,
+|         or failing that by the Debian maintainer.
+| 
+|    B. A patch is not unreasonable just because:
+|     (i) the package upstream (or the Debian maintainer) does not wish
+|         to support the relevant init system at all; or
+|     (ii) they do not wish to support any of the suitable non-forking
+|         startup protocols offered by that init system.
+| 
+|    C. However, a maintainer is entitled to consider a patch unreasonable
+|       if it:
+|     (i) Requires additional build-dependencies; or
+|     (ii) Requires additional runtime dependencies except sysv-rc; or
+|     (iii) Introduces other than trivial new code into the daemon; or
+|     (iv) "Abuses" SIGSTOP as done by the upstart "expect stop"
+|       protocol and as disliked by the systemd community.
+| 
+|    Code to write to an already-open fd and close it, or to raise a
+|    signal, will usually be trivial for these purposes.  (This includes
+|    enabling the new protocol via command-line switches or environment
+|    variable tests, and removing any small fixed set of associated
+|    variables from the environment.)  Code to connect to an AF_UNIX
+|    socket and send a message will not usually be considered trivial.
+| 
+|    We are aware that at present it is not possible to provide a patch
+|    for any of systemd's or upstart's main non-forking daemon startup
+|    readiness protocols which is necessarily reasonable by this
+|    definition.
+| 
+|    Therefore if the upstart and systemd communities in Debian want the
+|    widest adoption in the project, these problems should be addressed
+|    by changes to the upstart and systemd package to widen their
+|    support for different startup protocols.  Ideally each init should
+|    in any case provide support for the main protocols supported by
+|    their competition.
+| 
+|    Failure to apply reasonable patches, including failure to explain
+|    promptly and constructively why a patch is not reasonable, is
+|    likely to lead to the maintainer being overruled. ]
+| 
+| Detailed policy specifications:
+| 
+| 7. [ No package in Debian should use "expect fork" or "expect daemon"
+|    in upstart jobs.  The corresponding code in upstart may be disabled
+|    or compiled out on some or all architectures. ]
+| 
+| 8. Policy rules for support for init systems must:
+| 
+|    (a) Specify the use of a non-forking startup protocol (for
+|        upstart and systemd),
+| 
+|    (b) Use facilities documented in the reference manuals for the init
+|        system in question (as found in sid).  [ This requirement
+|        cannot be met until the init system has a suitable reference
+|        manual. ]
+| 
+|    (c) Require that environment variables and fds involved in the
+|        daemon startup protocol should not in general be inherited by
+|        the daemon's descendants.
+| 
+|    (d) Forbid the introduction of embedded copies of library code
+|        (or the use of any embedded copies included by upstream).
+| 
+| 9. [ Policy should provide non-binding suggestions to Debian
+|    contributors who are converting daemons to upstart and/or systemd,
+|    for example:
+| 
+|    (a) If changes are necessary to the core daemon code, make those
+|        changes acceptable to the daemon's upstream if possible.
+| 
+|    (b) It is fine to introduce new code in the main body of the daemon
+|        to support non-forking startup, socket activation or readiness
+|        signalling.
+| 
+|    (c) Support for upstart is usually best provided with the
+|        raise(SIGSTOP) non-forking daemon readiness protocol, unless
+|        and until a better protocol is available.
+| 
+|    (d) It is fine to introduce new command-line options to request the
+|        new startup mode(s), or to honour additional
+|        init-system-specific environment variables to request the new
+|        startup mode(s). ]
+| 
+| Cross-init-system compatibility:
+| 
+| 10. Debian contributors are encouraged to explore and develop ways in
+|    which a package can provide support for non-forking startup in
+|    multiple different init systems without having to have separate
+|    support for each init system in the source package; and, ideally,
+|    without having to have separate support for each init system in the
+|    binary package.
+| 
+| Replacement of existing functionality - process:
+| 
+| 11. [ Sometimes it is proposed that a package should take over some
+|    function currently performed by an existing different package.
+| 
+|    In such cases, the consent of the maintainers of the the package
+|    currently providing the functionality should be sought, or failing
+|    that, consensus obtained from the project as a whole in the usual
+|    way.
+| 
+|    This discussion should ideally take place before implementation
+|    work starts on the proposed replacement.  If and when the change is
+|    agreed, it should be accompanied by the appropriate policy changes.
+| 
+|    It is not proper for anyone declare an existing program obsolete,
+|    simply on the grounds that they have planned or implemented a
+|    replacement (whether as part of an existing codebase or otherwise).
+| 
+|    These principles apply regardless of whether the proposed new
+|    implementation provides the functionality via a reimplementation of
+|    the existing interface, or via a wholly new interface. ]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 18:18:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 18:18:11 GMT) (full text, mbox, link).

+ +

Message #2518 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Thu, 02 Jan 2014 10:16:27 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+> However, I think this gets to the heart of why upstart upstream has avoided
+> ever recommending the use of socket-based activation.  There are some fairly
+> fundamental problems that basically halted development of socket-based
+> activation in upstart (beyond merging of Scott's original implementation,
+> which is rudimentary, as has been noted), and a look at systemd usage on
+> Fedora led me to believe that systemd had not overcome these problems at
+> all.
+[...]
+
+I really hope that you wrote this email (and a few other recent ones)
+with your upstart maintainer hat on, and not your ctte member hat.
+
+Unless I have missed something, pretty much all the statements you have
+made (in a rather confrontational and certain tone) about systemd in
+this mail have been refuted. It seems that you have misunderstood some
+important parts of the systemd architecture, and instead of asking
+anyone to clarify, you went on to construct contra-systemd arguments
+from them.
+
+That can happen, and I am pretty sure that I have done the same. In my
+opinion, however, this is not acceptable from a ctte member who is
+expected to make a decision about the better init system for Debian as a
+whole.
+
+I do not believe that being the upstart maintainer disqualifies you from
+making this decision as a ctte member. I believe, however, that it
+places a special responsibility on you to be especially diligent in your
+research on systemd. Being the upstart maintainer means you have twice
+as much time available to learn about systemd (every other ctte member
+needs to split his time between upstart and systemd), and it means that
+you have to work extra hard to obtain at least a roughly comparable
+familiarity with both systemd and upstart.
+
+From your emails thus far, it does not look as if you have done
+this. Quite the contrary, I have the impression that you are using your
+familiarity with upstart as a reason to not investigate systemd in much
+depth.
+
+
+To put a long story short, I hope you are going to spend some more time
+on systemd before casting a vote.
+
+
+Thanks for considering, and happy new year!
+
+Best,
+-Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 18:24:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 18:24:09 GMT) (full text, mbox, link).

+ +

Message #2523 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Nikolaus Rath <Nikolaus@rath.org>, + 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Thu, 2 Jan 2014 18:20:50 +0000
+
+
Nikolaus Rath writes ("Bug#727708: loose ends for init system decision"):
+> I think there is one additional questions that will probably need to be
+> decided by the tc but hasn't really been discussed yet:
+> 
+> Will packages that explicity depend on a (non-default) init system be
+> allowed in Debian?
+
+My answer to this is "no".
+
+So, firstly, I would say that all packages must, in jessie at least,
+continue to support sysvinit.  Russ (from the other side of the
+upstart/systemd fence) agrees.  Failure to support sysvinit would be
+an RC bug.
+
+And since all the proposed replacement inits have a compatibility
+mode, that naturally means they'll work.
+
+Contributors who support the non-default new init system will be able
+to supply patches for native support and should have them accepted.
+
+> If such packages will not be allowed in the archive, does the burden of
+> making them work with the default init lie on the maintainers of the
+> default init (to add the missing feature), or the package maintainer (to
+> work around the features absence if he wants the package in Debian)?
+
+The latter.
+
+> The specific situation that I have in mind is of course when upstart
+> becomes the default, and gnome becomes dependent on systemd, but I think
+> the question is larger than just this example.
+
+Such a decision by Gnome (implying ditching all non-Linux
+architectures, too) would be very disappointing IMO.  I think this is
+a bridge we should cross if and when we come to it.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 18:33:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 18:33:10 GMT) (full text, mbox, link).

+ +

Message #2528 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, + 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Thu, 02 Jan 2014 10:28:30 -0800
+
+
On 01/02/2014 10:20 AM, Ian Jackson wrote:
+> Nikolaus Rath writes ("Bug#727708: loose ends for init system decision"):
+>> I think there is one additional questions that will probably need to be
+>> decided by the tc but hasn't really been discussed yet:
+>>
+>> Will packages that explicity depend on a (non-default) init system be
+>> allowed in Debian?
+> 
+> My answer to this is "no".
+> 
+> So, firstly, I would say that all packages must, in jessie at least,
+> continue to support sysvinit.  Russ (from the other side of the
+> upstart/systemd fence) agrees.  Failure to support sysvinit would be
+> an RC bug.
+> 
+> And since all the proposed replacement inits have a compatibility
+> mode, that naturally means they'll work.
+> 
+> Contributors who support the non-default new init system will be able
+> to supply patches for native support and should have them accepted.
+> 
+>> If such packages will not be allowed in the archive, does the burden of
+>> making them work with the default init lie on the maintainers of the
+>> default init (to add the missing feature), or the package maintainer (to
+>> work around the features absence if he wants the package in Debian)?
+> 
+> The latter.
+
+Just to make sure that I expressed myself correctly: I was not thinking
+about a package that depends on a specific init system to start or stop,
+but about a program that is really specific to the *new* features of
+upstart or systemd.
+
+
+For example, a hypothetical future program to interactively adjust
+program cgroups cannot be sysvinit compatible in any meaningful sense,
+because it does not need to be supervised, started, or stopped. However,
+this program would depend on the cgroups API offered by systemd. So this
+program would not be allowed in Debian, unless its maintainer adds
+support for whatever cgroups managed we would eventually use with upstart?
+
+
+Best,
+Nikolaus
+
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 18:33:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 18:33:13 GMT) (full text, mbox, link).

+ +

Message #2533 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Nikolaus Rath <Nikolaus@rath.org>
+
Cc: 727708@bugs.debian.org, + Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Thu, 2 Jan 2014 18:30:32 +0000
+
+
Nikolaus Rath writes ("Re: Bug#727708: loose ends for init system decision"):
+> For example, a hypothetical future program to interactively adjust
+> program cgroups cannot be sysvinit compatible in any meaningful sense,
+> because it does not need to be supervised, started, or stopped. However,
+> this program would depend on the cgroups API offered by systemd. So this
+> program would not be allowed in Debian, unless its maintainer adds
+> support for whatever cgroups managed we would eventually use with upstart?
+
+I would hope that we can standardise on a single API to the system's
+single cgroup writer.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 18:33:16 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 18:33:16 GMT) (full text, mbox, link).

+ +

Message #2538 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Thu, 2 Jan 2014 10:31:07 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Thu, Jan 2, 2014 at 10:16 AM, Ian Jackson <
+ijackson@chiark.greenend.org.uk> wrote:
+
+> Ian Jackson writes ("Re: Bug#727708: init system discussion status"):
+> > I have written a draft resolution from my own point of view and
+> > checked it into the tech-ctte git repo.  Perhaps some of it is useful.
+> > Ansgar commented a bit on it on IRC.  I guess I should post it.
+>
+> Here's my draft.
+>
+>
+> Those who prefer systemd will want to s/upstart/systemd/ and vice
+> versa, obviously.  Aside from that:
+>
+> 0,3,4,5,8,10 are probably not very controversial (mutatis mutandi
+>    for those who prefer systemd).
+>
+> 2 (non-Linux ports) needs attention in the systemd case.
+>
+> 6 will not be controversial (mutatis mutandi) except:
+>
+> 6C (and the consequential paragraphs) may be quite controversial even
+>    amongst those who prefer upstart.  This needs further discussion.
+>
+> 7 probably needs to deal with systemd too in any case; the
+>    corresponding feature is "guess main pid" I think.
+>
+> 9's usefulness was doubted by Russ, but I hope the substance at least
+>    is uncontroversial.
+>
+> 11 is probably going to be thought inappropriate but I wanted to at
+>    least float it.
+>
+> Of course some of you may want to take a completely different
+> approach, perhaps specifying things in much less detail.
+>
+> For the "punt it to a GR" option, I don't think we should specify this
+> level of detail about compatibility, policy, accepting patches etc.
+> We should provide at least four draft ballot options (upstart,
+> systemd, sysvinit, openrc) and request that the DPL propose the GR as
+> the TC is too unweildy for handling amendments for something
+> time-critical like this.  The ballot options we suggest should all
+> state that sysvinit is still mandatory to support in jessie.
+>
+> Thanks,
+> Ian.
+>
+> | Rubric:
+> |
+> | 0. We decide as follows (Constitution 6.1(1),(2)).  Text in square
+> |    brackets "[]" is non-binding advice (Constitution 6.1(5)).  We
+> |    require the Policy Editors (Constitution 6.1(1)) to make the policy
+> |    changes they think appropriate to give effect to this resolution.
+> |
+> | Choice of init system:
+> |
+> | 1. The default init(1) in jessie will be upstart.
+> |
+> | 2. Architectures which do not currently support upstart should try to
+> |    port it.  If this is not achieved in time, those architectures may
+> |    continue to use sysvinit.  [ Non-use of upstart should not be a
+> |    criterion for architecture qualification status in jessie. ]
+> |
+> | 3. At least in jessie, unless a satisfactory compatibility approach is
+> |    developed and deployed (see paragraph 10), packages must continue
+> |    to provide sysvinit scripts.  Lack of a sysvinit script (for a
+> |    daemon which contains integration with at least one other init
+> |    system) is an RC bug in jessie.
+> |
+> |    [ After jessie, the policy editors may drop this requirement;
+> |    perhaps entirely, or perhaps in favour of a requirement to provide
+> |    at least one of sysvinit or systemd integration.  The policy
+> |    editors may wish to refer this decision to us in due course. ]
+> |
+> | Policy is not ready, so hold off on updating all packages:
+> |
+> | 4. [ The current Debian policy for upstart, in the policy manual,
+> |    could do with some improvement and enhancement.  The current Debian
+> |    policy for systemd needs to be finished and agreed, and then
+> |    incorporated in the policy manual.  We encourage the maintainers of
+> |    upstart and systemd, and others, to submit relevant policy
+> |    enhancements.
+> |
+> |    Contributors should delay introducing patches for native support
+> |    for upstart, systemd or openrc until the relevant Debian Policy is
+> |    declared, by the Policy editors, to be ready. ]
+> |
+> | Support requirements for packages:
+> |
+> | 5. Subject to paragraphs 4 and 6 of this resolution, packages should
+> |    provide native upstart jobs where relevant.
+> |
+> |    Lack of native upstart support is not a release-critical bug for
+> |    jessie.
+> |
+> |    [ Patches for upstart support should be treated the way "release
+> |    goals" have been treated in the past; so, for example, there should
+> |    be a low NMU threshold for patches meeting suitable criteria.
+> |
+> |    The Debian Project Leader and/or applicable Delegates should give
+> |    effect to this part of our decision. ]
+> |
+> | 6. [ Maintainers should accept reasonable patches for native upstart,
+> |    systemd and openrc support.
+> |
+> |    A. A reasonable patch:
+> |     (i) is proposed after the relevant policy is finalised;
+> |     (ii) complies with that policy;
+> |     (iii) complies with the advice and requirements in this
+> |         resolution; and
+> |     (iv) takes the approaches to integration chosen by upstream,
+> |         or failing that by the Debian maintainer.
+> |
+> |    B. A patch is not unreasonable just because:
+> |     (i) the package upstream (or the Debian maintainer) does not wish
+> |         to support the relevant init system at all; or
+> |     (ii) they do not wish to support any of the suitable non-forking
+> |         startup protocols offered by that init system.
+> |
+> |    C. However, a maintainer is entitled to consider a patch unreasonable
+> |       if it:
+> |     (i) Requires additional build-dependencies; or
+> |     (ii) Requires additional runtime dependencies except sysv-rc; or
+> |     (iii) Introduces other than trivial new code into the daemon; or
+> |     (iv) "Abuses" SIGSTOP as done by the upstart "expect stop"
+> |       protocol and as disliked by the systemd community.
+> |
+> |    Code to write to an already-open fd and close it, or to raise a
+> |    signal, will usually be trivial for these purposes.  (This includes
+> |    enabling the new protocol via command-line switches or environment
+> |    variable tests, and removing any small fixed set of associated
+> |    variables from the environment.)  Code to connect to an AF_UNIX
+> |    socket and send a message will not usually be considered trivial.
+> |
+> |    We are aware that at present it is not possible to provide a patch
+> |    for any of systemd's or upstart's main non-forking daemon startup
+> |    readiness protocols which is necessarily reasonable by this
+> |    definition.
+> |
+> |    Therefore if the upstart and systemd communities in Debian want the
+> |    widest adoption in the project, these problems should be addressed
+> |    by changes to the upstart and systemd package to widen their
+> |    support for different startup protocols.  Ideally each init should
+> |    in any case provide support for the main protocols supported by
+> |    their competition.
+> |
+> |    Failure to apply reasonable patches, including failure to explain
+> |    promptly and constructively why a patch is not reasonable, is
+> |    likely to lead to the maintainer being overruled. ]
+> |
+> | Detailed policy specifications:
+> |
+> | 7. [ No package in Debian should use "expect fork" or "expect daemon"
+> |    in upstart jobs.  The corresponding code in upstart may be disabled
+> |    or compiled out on some or all architectures. ]
+> |
+> | 8. Policy rules for support for init systems must:
+> |
+> |    (a) Specify the use of a non-forking startup protocol (for
+> |        upstart and systemd),
+> |
+> |    (b) Use facilities documented in the reference manuals for the init
+> |        system in question (as found in sid).  [ This requirement
+> |        cannot be met until the init system has a suitable reference
+> |        manual. ]
+> |
+> |    (c) Require that environment variables and fds involved in the
+> |        daemon startup protocol should not in general be inherited by
+> |        the daemon's descendants.
+> |
+> |    (d) Forbid the introduction of embedded copies of library code
+> |        (or the use of any embedded copies included by upstream).
+> |
+>
+| 9. [ Policy should provide non-binding suggestions to Debian
+> |    contributors who are converting daemons to upstart and/or systemd,
+> |    for example:
+> |
+> |    (a) If changes are necessary to the core daemon code, make those
+> |        changes acceptable to the daemon's upstream if possible.
+> |
+> |    (b) It is fine to introduce new code in the main body of the daemon
+> |        to support non-forking startup, socket activation or readiness
+> |        signalling.
+> |
+> |    (c) Support for upstart is usually best provided with the
+> |        raise(SIGSTOP) non-forking daemon readiness protocol, unless
+> |        and until a better protocol is available.
+> |
+>
+
+Should it not be added that raise(SIGSTOP) should only be used with a
+command line option (like --debian-Z) to ensure that the daemon does not
+hang on sysv or systemd?
+
+Cheers,
+Cameron Norman
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 18:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 18:39:04 GMT) (full text, mbox, link).

+ +

Message #2543 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Cameron Norman <camerontnorman@gmail.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Thu, 2 Jan 2014 18:37:18 +0000
+
+
Cameron Norman writes ("Re: Bug#727708: init system discussion status"):
+> On Thu, Jan 2, 2014 at 10:16 AM, Ian Jackson <
+> ijackson@chiark.greenend.org.uk> wrote:
+...
+> | 9. [ Policy should provide non-binding suggestions to Debian
+> > |    contributors who are converting daemons to upstart and/or systemd,
+> > |    for example:
+> > |
+> > |    (a) If changes are necessary to the core daemon code, make those
+> > |        changes acceptable to the daemon's upstream if possible.
+> > |
+> > |    (b) It is fine to introduce new code in the main body of the daemon
+> > |        to support non-forking startup, socket activation or readiness
+> > |        signalling.
+> > |
+> > |    (c) Support for upstart is usually best provided with the
+> > |        raise(SIGSTOP) non-forking daemon readiness protocol, unless
+> > |        and until a better protocol is available.
+> > |
+> 
+> Should it not be added that raise(SIGSTOP) should only be used with a
+> command line option (like --debian-Z) to ensure that the daemon does not
+> hang on sysv or systemd?
+
+I think in practice this isn't going to be much of a problem but I
+don't mind putting it in this section of my proposed resolution.  This
+is advice to the the policy editors which they can ignore it if they
+feel it's clogging up the manual.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 18:45:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 18:45:08 GMT) (full text, mbox, link).

+ +

Message #2548 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Thu, 02 Jan 2014 10:42:09 -0800
+
+
On 01/02/2014 10:30 AM, Ian Jackson wrote:
+> Nikolaus Rath writes ("Re: Bug#727708: loose ends for init system decision"):
+>> For example, a hypothetical future program to interactively adjust
+>> program cgroups cannot be sysvinit compatible in any meaningful sense,
+>> because it does not need to be supervised, started, or stopped. However,
+>> this program would depend on the cgroups API offered by systemd. So this
+>> program would not be allowed in Debian, unless its maintainer adds
+>> support for whatever cgroups managed we would eventually use with upstart?
+> 
+> I would hope that we can standardise on a single API to the system's
+> single cgroup writer.
+
+I certainly hope so too, but I think the question of how such a
+situation would be handled needs to be answered. Even if we end up with
+a standardized cgroup API, it may show up in a different disguise.
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 18:45:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 18:45:11 GMT) (full text, mbox, link).

+ +

Message #2553 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Thu, 02 Jan 2014 10:43:50 -0800
+
+
Cameron Norman <camerontnorman@gmail.com> writes:
+
+> Should it not be added that raise(SIGSTOP) should only be used with a
+> command line option (like --debian-Z) to ensure that the daemon does not
+> hang on sysv or systemd?
+
+No, because see Colin's point that Debian developers may be doing the
+integration and adding a new command-line option may conflict with
+upstream's intentions or just be more intrusive.  Another reasonable
+option is to use an environment variable that you then unset after
+noticing its existence.  There may be others.  I think it's best to be
+agnostic in the TC decision on how this integration is done, since I think
+it's really a matter of technical detail and won't be controversial, and
+be more verbose about the options in Policy.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 18:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 18:57:04 GMT) (full text, mbox, link).

+ +

Message #2558 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Thu, 2 Jan 2014 18:52:44 +0000
+
+
Russ Allbery writes ("Bug#727708: init system discussion status"):
+> Cameron Norman <camerontnorman@gmail.com> writes:
+> > Should it not be added that raise(SIGSTOP) should only be used with a
+> > command line option (like --debian-Z) to ensure that the daemon does not
+> > hang on sysv or systemd?
+> 
+> No, because see Colin's point that Debian developers may be doing the
+> integration and adding a new command-line option may conflict with
+> upstream's intentions or just be more intrusive.  Another reasonable
+> option is to use an environment variable that you then unset after
+> noticing its existence.  There may be others.  I think it's best to be
+> agnostic in the TC decision on how this integration is done, since I think
+> it's really a matter of technical detail and won't be controversial, and
+> be more verbose about the options in Policy.
+
+I think it would be reasonable to state that the raise(SIGSTOP)
+integration should be done with a new command line option OR a new
+environment variable; ie that the daemon should not be changed to
+raise(SIGSTOP) by default.
+
+I don't know whether it's valuable to mention this explicitly.
+
+If there is any significant risk that anyone might patch a daemon to
+SIGSTOP by default then I would want to put something in the
+resolution or in policy to suggest not to do that!  Would anyone
+really be so daft ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 19:24:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 19:24:08 GMT) (full text, mbox, link).

+ +

Message #2563 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Thu, 02 Jan 2014 11:21:04 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Ian Jackson writes ("Re: Bug#727708: init system discussion status"):
+
+>> I have written a draft resolution from my own point of view and checked
+>> it into the tech-ctte git repo.  Perhaps some of it is useful.  Ansgar
+>> commented a bit on it on IRC.  I guess I should post it.
+
+> Here's my draft.
+
+Thank you very much for writing this.  (And, in general, thank you for
+often taking the initiative in producing drafts.  It's something that I
+find difficult, and I really appreciate your work on it.)
+
+> For the "punt it to a GR" option, I don't think we should specify this
+> level of detail about compatibility, policy, accepting patches etc.  We
+> should provide at least four draft ballot options (upstart, systemd,
+> sysvinit, openrc) and request that the DPL propose the GR as the TC is
+> too unweildy for handling amendments for something time-critical like
+> this.  The ballot options we suggest should all state that sysvinit is
+> still mandatory to support in jessie.
+
+That sounds right to me too.
+
+> | Rubric:
+> | 
+> | 0. We decide as follows (Constitution 6.1(1),(2)).  Text in square
+> |    brackets "[]" is non-binding advice (Constitution 6.1(5)).  We
+> |    require the Policy Editors (Constitution 6.1(1)) to make the policy
+> |    changes they think appropriate to give effect to this resolution.
+> | 
+> | Choice of init system:
+> | 
+> | 1. The default init(1) in jessie will be upstart.
+> |
+> | 2. Architectures which do not currently support upstart should try to
+> |    port it.  If this is not achieved in time, those architectures may
+> |    continue to use sysvinit.  [ Non-use of upstart should not be a
+> |    criterion for architecture qualification status in jessie. ]
+
+The thrust of this seems right, but I dislike telling people what to do.
+Can we recast this in a way that avoids that problem?  Maybe something
+like:
+
+  1. The default init(1) in jessie for linux-any architectures will be
+     upstart/systemd.
+
+  2. The default init(1) in jessie for non-Linux ports will be
+     upstart/systemd if that init system has been ported and confirmed by
+     the porters to be working by the time of the jessie release.  Failing
+     this, the default init(1) in jessie for non-Linux ports is left to
+     the discretion of the maintainers of that port.  [ However, the
+     Technical Committee requests that, should upstart/systemd not be
+     available for either Hurd or kFreeBSD ports, the Hurd and kFreeBSD
+     porters agree on a single alternative init(1) implementation that
+     will be shared by both ports. ]
+
+I'm not sure the point of the bracketed text in yours and whether I've
+addressed it.
+
+Another issue, which I did not address here but which we should probably
+say something about, is that the init process 1 implementation and the
+system used to run daemon configuration and startup jobs is separable, and
+in fact is separated in OpenRC.  We should be clear about what we're
+talking about, particularly when it comes to non-Linux ports.
+
+> | 3. At least in jessie, unless a satisfactory compatibility approach is
+> |    developed and deployed (see paragraph 10), packages must continue
+> |    to provide sysvinit scripts.  Lack of a sysvinit script (for a
+> |    daemon which contains integration with at least one other init
+> |    system) is an RC bug in jessie.
+
+This needs the same exception as is currently in Policy 9.11, namely:
+
+    An exception to this rule is scripts or jobs provided by the init
+    implementation itself; such jobs may be required for an
+    implementation-specific equivalent of the /etc/rcS.d/ scripts and may
+    not have a one-to-one correspondence with the init scripts.
+
+> |    [ After jessie, the policy editors may drop this requirement;
+> |    perhaps entirely, or perhaps in favour of a requirement to provide
+> |    at least one of sysvinit or systemd integration.  The policy
+> |    editors may wish to refer this decision to us in due course. ]
+
+This seems okay, although I have a minor preference to just omit this
+part, since I think it casts Policy in a somewhat weird role and I'm also
+worried about resources for the Policy process in making that sort of
+decision.  (I'm committing to work on Policy for upstart and systemd
+support for this specific decision, but can't commit jessie+1 resources.)
+That's why I was proposing having the TC make the decision now about
+whether we drop compatibility with sysvinit in jessie+1.  If we don't make
+it, someone else needs to make it, and I'm not sure who that body would
+be.
+
+One possibilty is to explicitly say that we'll make it ourselves after the
+jessie release.
+
+> | Policy is not ready, so hold off on updating all packages:
+> | 
+> | 4. [ The current Debian policy for upstart, in the policy manual,
+> |    could do with some improvement and enhancement.  The current Debian
+> |    policy for systemd needs to be finished and agreed, and then
+> |    incorporated in the policy manual.  We encourage the maintainers of
+> |    upstart and systemd, and others, to submit relevant policy
+> |    enhancements.
+> | 
+> |    Contributors should delay introducing patches for native support
+> |    for upstart, systemd or openrc until the relevant Debian Policy is
+> |    declared, by the Policy editors, to be ready. ]
+
+"Should delay" is a bit strong given that we have many packages in the
+archive that already provide native support for upstart, and several
+(including ones maintained by both Colin and myself) that have native
+support for systemd.  Maybe something more like:
+
+    Contributors who have not already added native support for upstart,
+    systemd, or OpenRC may wish to wait until the relevant Debian Policy
+    is declared, by the Policy editors, to be ready.  Early adopters
+    should be aware that the requirements may change and their packages
+    may require updates.
+
+> | Support requirements for packages:
+> | 
+> | 5. Subject to paragraphs 4 and 6 of this resolution, packages should
+> |    provide native upstart jobs where relevant.
+> | 
+> |    Lack of native upstart support is not a release-critical bug for
+> |    jessie.
+> | 
+> |    [ Patches for upstart support should be treated the way "release
+> |    goals" have been treated in the past; so, for example, there should
+> |    be a low NMU threshold for patches meeting suitable criteria.
+> | 
+> |    The Debian Project Leader and/or applicable Delegates should give
+> |    effect to this part of our decision. ]
+
+This seems fine.
+
+> | 6. [ Maintainers should accept reasonable patches for native upstart,
+> |    systemd and openrc support.
+> | 
+> |    A. A reasonable patch:
+> |     (i) is proposed after the relevant policy is finalised;
+> |     (ii) complies with that policy;
+> |     (iii) complies with the advice and requirements in this
+> |         resolution; and
+> |     (iv) takes the approaches to integration chosen by upstream,
+> |         or failing that by the Debian maintainer.
+
+Looks good.
+
+> |    B. A patch is not unreasonable just because:
+> |     (i) the package upstream (or the Debian maintainer) does not wish
+> |         to support the relevant init system at all; or
+> |     (ii) they do not wish to support any of the suitable non-forking
+> |         startup protocols offered by that init system.
+
+Looks good.
+
+> |    C. However, a maintainer is entitled to consider a patch unreasonable
+> |       if it:
+> |     (i) Requires additional build-dependencies; or
+> |     (ii) Requires additional runtime dependencies except sysv-rc; or
+> |     (iii) Introduces other than trivial new code into the daemon; or
+> |     (iv) "Abuses" SIGSTOP as done by the upstart "expect stop"
+> |       protocol and as disliked by the systemd community.
+
+I would drop (i) and (iv).  (ii) is fine if and only if the sysv-rc
+maintainers *and* the init-system-helper maintainers both think that
+merging their packages is a reasonable thing to do; if not, I would also
+drop (ii).  I don't see a need for the TC to force a package merger.
+(And, really, I'd drop it regardless since I think it's too far into the
+implementation weeds for the TC to need to have an opinion.)
+
+> |    Code to write to an already-open fd and close it, or to raise a
+> |    signal, will usually be trivial for these purposes.  (This includes
+> |    enabling the new protocol via command-line switches or environment
+> |    variable tests, and removing any small fixed set of associated
+> |    variables from the environment.)  Code to connect to an AF_UNIX
+> |    socket and send a message will not usually be considered trivial.
+
+Obviously I don't agree with this, as per previous discussion.
+
+> |    We are aware that at present it is not possible to provide a patch
+> |    for any of systemd's or upstart's main non-forking daemon startup
+> |    readiness protocols which is necessarily reasonable by this
+> |    definition.
+> | 
+> |    Therefore if the upstart and systemd communities in Debian want the
+> |    widest adoption in the project, these problems should be addressed
+> |    by changes to the upstart and systemd package to widen their
+> |    support for different startup protocols.  Ideally each init should
+> |    in any case provide support for the main protocols supported by
+> |    their competition.
+
+I'm not at all fond of this approach.  Neither the upstart nor the systemd
+notification processes are so unreasonable as to warrant the TC explicitly
+asking the projects to change their designs.
+
+> |    Failure to apply reasonable patches, including failure to explain
+> |    promptly and constructively why a patch is not reasonable, is
+> |    likely to lead to the maintainer being overruled. ]
+
+I think we already covered this with "should" in the first sentence of
+this section without needing to make an explicit threat.
+
+> | Detailed policy specifications:
+> | 
+> | 7. [ No package in Debian should use "expect fork" or "expect daemon"
+> |    in upstart jobs.  The corresponding code in upstart may be disabled
+> |    or compiled out on some or all architectures. ]
+
+I'm not fond of this functionality either, but this feels quite strong.
+Do we really anticipate that this is going to be enough of a problem that
+we have to proactively forbid it with a TC ruling?
+
+> | 8. Policy rules for support for init systems must:
+> | 
+> |    (a) Specify the use of a non-forking startup protocol (for
+> |        upstart and systemd),
+> | 
+> |    (b) Use facilities documented in the reference manuals for the init
+> |        system in question (as found in sid).  [ This requirement
+> |        cannot be met until the init system has a suitable reference
+> |        manual. ]
+> | 
+> |    (c) Require that environment variables and fds involved in the
+> |        daemon startup protocol should not in general be inherited by
+> |        the daemon's descendants.
+> | 
+> |    (d) Forbid the introduction of embedded copies of library code
+> |        (or the use of any embedded copies included by upstream).
+
+I'm not sure what the point of (b) is.  I think (d) is too strong.  Policy
+4.13 currently says:
+
+    If the included code is already in the Debian archive in the form of a
+    library, the Debian packaging should ensure that binary packages
+    reference the libraries already in Debian and the convenience copy is
+    not used. If the included code is not already in Debian, it should be
+    packaged separately as a prerequisite if possible.
+
+using the Policy definition of "should" (meaning that it's a bug but not
+necessarily RC).  I don't see why we would treat this instance of code
+copies any differently than we would treat any other instance in the
+archive.
+
+I think Policy 4.13 already covers this adequately and we don't need to
+say anything further in the decision.
+
+> | 9. [ Policy should provide non-binding suggestions to Debian
+> |    contributors who are converting daemons to upstart and/or systemd,
+> |    for example:
+> | 
+> |    (a) If changes are necessary to the core daemon code, make those
+> |        changes acceptable to the daemon's upstream if possible.
+> | 
+> |    (b) It is fine to introduce new code in the main body of the daemon
+> |        to support non-forking startup, socket activation or readiness
+> |        signalling.
+> | 
+> |    (c) Support for upstart is usually best provided with the
+> |        raise(SIGSTOP) non-forking daemon readiness protocol, unless
+> |        and until a better protocol is available.
+> | 
+> |    (d) It is fine to introduce new command-line options to request the
+> |        new startup mode(s), or to honour additional
+> |        init-system-specific environment variables to request the new
+> |        startup mode(s). ]
+
+This all seems fine.
+
+> | Cross-init-system compatibility:
+> | 
+> | 10. Debian contributors are encouraged to explore and develop ways in
+> |    which a package can provide support for non-forking startup in
+> |    multiple different init systems without having to have separate
+> |    support for each init system in the source package; and, ideally,
+> |    without having to have separate support for each init system in the
+> |    binary package.
+
+I don't see anything objectionable about this, but I also don't really
+understand why it's important for us to say it.  But regardless, I think
+this should be in brackets?  It sounds like technical advice per the
+preamble.
+
+> | Replacement of existing functionality - process:
+> | 
+> | 11. [ Sometimes it is proposed that a package should take over some
+> |    function currently performed by an existing different package.
+> | 
+> |    In such cases, the consent of the maintainers of the the package
+> |    currently providing the functionality should be sought, or failing
+> |    that, consensus obtained from the project as a whole in the usual
+> |    way.
+> | 
+> |    This discussion should ideally take place before implementation
+> |    work starts on the proposed replacement.  If and when the change is
+> |    agreed, it should be accompanied by the appropriate policy changes.
+> | 
+> |    It is not proper for anyone declare an existing program obsolete,
+> |    simply on the grounds that they have planned or implemented a
+> |    replacement (whether as part of an existing codebase or otherwise).
+> | 
+> |    These principles apply regardless of whether the proposed new
+> |    implementation provides the functionality via a reimplementation of
+> |    the existing interface, or via a wholly new interface. ]
+
+This all seems nice in theory but rather problematic in practice.
+
+First, with my Policy Editor hat on, I object to Policy being placed in a
+blocking position.  We are simply not responsive enough right now to hold
+that position responsibly.  Multiple valuable, useful changes to Debian
+have happened without Policy changes, and with Policy only being added
+after the fact; consider, for instance, symbols support, triggers, and
+multiarch.  I don't think we want to say that's not okay.
+
+Second, I think "take over" needs to be clearer.  I assume that the intent
+of the term is to apply to cases where the new functionality conflicts
+with the old package and would make it impossible to use both at the same
+time.  In other words, I don't think this should apply to, for instance,
+use of FDO desktop files for menus instead of the Debian menu system,
+since both can continue to work in parallel and neither takes over from
+the other in a way that prevents the other from working.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 19:24:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 19:24:15 GMT) (full text, mbox, link).

+ +

Message #2568 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Thu, 02 Jan 2014 11:22:56 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I think it would be reasonable to state that the raise(SIGSTOP)
+> integration should be done with a new command line option OR a new
+> environment variable; ie that the daemon should not be changed to
+> raise(SIGSTOP) by default.
+
+Agreed.
+
+> I don't know whether it's valuable to mention this explicitly.
+
+> If there is any significant risk that anyone might patch a daemon to
+> SIGSTOP by default then I would want to put something in the resolution
+> or in policy to suggest not to do that!  Would anyone really be so
+> daft ?
+
+I think this falls under Manoj's old saying that it's not the role of
+Policy to rule out all possible bugs.  That's such an obviously wrong
+thing to do that I'm not sure we really need to say it, although there's
+no harm in saying it, I suppose.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 19:48:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 19:48:09 GMT) (full text, mbox, link).

+ +

Message #2573 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: Nikolaus Rath <Nikolaus@rath.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Thu, 02 Jan 2014 20:46:02 +0100
+
+
Le jeudi 02 janvier 2014 à 18:30 +0000, Ian Jackson a écrit : 
+> I would hope that we can standardise on a single API to the system's
+> single cgroup writer.
+
+I have already explained why this is not going to happen. The cgroups
+API in systemd is already part of the core systemd interface and subject
+to the stability promise. The only other existing implementation
+(cgmanager) is merely wrapping in D-Bus the existing kernel API, which
+is going to die when a single writer becomes necessary.
+
+-- 
+ .''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 19:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 19:51:05 GMT) (full text, mbox, link).

+ +

Message #2578 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Thu, 2 Jan 2014 19:49:50 +0000
+
+
Russ Allbery writes ("Bug#727708: init system discussion status"):
+> Thank you very much for writing this.  (And, in general, thank you for
+> often taking the initiative in producing drafts.  It's something that I
+> find difficult, and I really appreciate your work on it.)
+
+Thanks.  I agree with much of what you say.  I will deal with your
+comments again in more detail later, particularly the bits I don't
+disagree with, but for now:
+
+> Another issue, which I did not address here but which we should probably
+> say something about, is that the init process 1 implementation and the
+> system used to run daemon configuration and startup jobs is separable, and
+> in fact is separated in OpenRC.  We should be clear about what we're
+> talking about, particularly when it comes to non-Linux ports.
+
+I'm not sure what kind of things you are proposing should be in the
+resolution text (or, what in my proposal is wrong).  Is it not
+sufficient to say that people should accept openrc patches as and when
+the openrc policy is done ?
+
+> > | 3. At least in jessie, unless a satisfactory compatibility approach is
+> > |    developed and deployed (see paragraph 10), packages must continue
+> > |    to provide sysvinit scripts.  Lack of a sysvinit script (for a
+> > |    daemon which contains integration with at least one other init
+> > |    system) is an RC bug in jessie.
+> 
+> This needs the same exception as is currently in Policy 9.11, namely:
+> 
+>     An exception to this rule is scripts or jobs provided by the init
+>     implementation itself; such jobs may be required for an
+>     implementation-specific equivalent of the /etc/rcS.d/ scripts and may
+>     not have a one-to-one correspondence with the init scripts.
+
+Ansgar said something similar on IRC.  I didn't feel it worth
+mentioning but if you want it too then I'm convinced.
+
+> > |    [ After jessie, the policy editors may drop this requirement;
+> > |    perhaps entirely, or perhaps in favour of a requirement to provide
+> > |    at least one of sysvinit or systemd integration.  The policy
+> > |    editors may wish to refer this decision to us in due course. ]
+> 
+> This seems okay, although I have a minor preference to just omit this
+> part, since I think it casts Policy in a somewhat weird role and I'm also
+> worried about resources for the Policy process in making that sort of
+> decision.  (I'm committing to work on Policy for upstart and systemd
+> support for this specific decision, but can't commit jessie+1 resources.)
+> That's why I was proposing having the TC make the decision now about
+> whether we drop compatibility with sysvinit in jessie+1.  If we don't make
+> it, someone else needs to make it, and I'm not sure who that body would
+> be.
+
+I don't mind dropping this part entirely.
+
+Certainly I don't think we can make this decision now.
+
+> One possibilty is to explicitly say that we'll make it ourselves after the
+> jessie release.
+
+I don't want to do this in case it turns out to be uncontroversial.
+
+> > |    Therefore if the upstart and systemd communities in Debian want the
+> > |    widest adoption in the project, these problems should be addressed
+> > |    by changes to the upstart and systemd package to widen their
+> > |    support for different startup protocols.  Ideally each init should
+> > |    in any case provide support for the main protocols supported by
+> > |    their competition.
+> 
+> I'm not at all fond of this approach.  Neither the upstart nor the systemd
+> notification processes are so unreasonable as to warrant the TC explicitly
+> asking the projects to change their designs.
+
+I think that's not the right the question.  The real question is this:
+
+Are the protocols offered by systemd and upstart each so plainly
+reasonable, that we are willing to overrule a maintainer who feels
+they protocol they are asked to support is too ugly or burdensome ?
+Are such a maintainer's objections so unreasonable ?
+
+The init system is a core facility.  Compatibility with a wide range
+of other projects with a wide range of different opinions amongst
+their developers is imporant.  Supporting one more protocol is very
+easy for the init system.
+
+In practice if systemd and upstart each implement each other's main
+protocol, I would expect very few if any packages to remain
+unsupported.
+
+For me the objection that to invent a new protocol would be
+multiplying standards carries no weight.  There is little cost to
+these competing standards, and we already have at least eight in the
+world (sd_notify, SIGSTOP, systemd socket activation, upstart socket
+activation, upstart "expect fork", daemon(3), inetd, and what systemd
+calls "simple").
+
+> > |    Failure to apply reasonable patches, including failure to explain
+> > |    promptly and constructively why a patch is not reasonable, is
+> > |    likely to lead to the maintainer being overruled. ]
+> 
+> I think we already covered this with "should" in the first sentence of
+> this section without needing to make an explicit threat.
+
+I would like to include this because it will stiffen our resolve.  It
+also includes the important point that it is up to the maintainer to
+justify non-inclusion, not the other way around.
+
+> > | Detailed policy specifications:
+> > | 
+> > | 7. [ No package in Debian should use "expect fork" or "expect daemon"
+> > |    in upstart jobs.  The corresponding code in upstart may be disabled
+> > |    or compiled out on some or all architectures. ]
+> 
+> I'm not fond of this functionality either, but this feels quite strong.
+> Do we really anticipate that this is going to be enough of a problem that
+> we have to proactively forbid it with a TC ruling?
+
+The main practical reason for ruling this out, and converting existing
+packages, is that not all the ports of upstart can be expected to
+implement the underlying strace mechanism used by upstart to implement
+these.
+
+The project needs to make a choice between requiring all our ports to
+support those protocols (which are very unpleasant, and also hard to
+port), and forbidding packages from usign them.  Having the protocol
+for a single init system depend on the platform would be too awkward
+IMO.  So something about this needs to be in policy.
+
+I'd rather deal with this here in the TC having done all the research
+than remand it to the policy list and then perhaps having it come back
+when it turns out that there are differing opinions about the value of
+the non-Linux ports, etc.
+
+(This is advice on policy, of course, not a binding decision.)
+
+> > | Cross-init-system compatibility:
+> > | 
+> > | 10. Debian contributors are encouraged to explore and develop ways in
+> > |    which a package can provide support for non-forking startup in
+> > |    multiple different init systems without having to have separate
+> > |    support for each init system in the source package; and, ideally,
+> > |    without having to have separate support for each init system in the
+> > |    binary package.
+> 
+> I don't see anything objectionable about this, but I also don't really
+> understand why it's important for us to say it.  But regardless, I think
+> this should be in brackets?  It sounds like technical advice per the
+> preamble.
+
+Yes, I just failed to bracket it.
+
+I want to put this in because I'd like to be able to drop sysvinit in
+(its current form at least) in jessie+1, without duplicating or
+triplicating all the init system integration work.
+
+Putting this in here sends a signal that we would look favourably on
+some kind of compatibility layers.  I don't think it's essential if
+people object to it.
+
+> This all seems nice in theory but rather problematic in practice.
+>
+> [...]  In other words, I don't think this should apply to, for instance,
+> use of FDO desktop files for menus instead of the Debian menu system,
+> since both can continue to work in parallel and neither takes over from
+> the other in a way that prevents the other from working.
+
+I don't agree.  Unless we either have a compatibility shim, or a
+policy decision to transition, every package ought to be required to
+provide something in the Debian menus.  Isn't this situation analogous
+to the mime-support argument where we required a package to reinstate
+a mime entry ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 19:54:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 19:54:10 GMT) (full text, mbox, link).

+ +

Message #2583 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Josselin Mouette <joss@debian.org>, + 727708@bugs.debian.org
+
Cc: Nikolaus Rath <Nikolaus@rath.org>
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Thu, 2 Jan 2014 19:51:23 +0000
+
+
Josselin Mouette writes ("Bug#727708: loose ends for init system decision"):
+> Le jeudi 02 janvier 2014 à 18:30 +0000, Ian Jackson a écrit : 
+> > I would hope that we can standardise on a single API to the system's
+> > single cgroup writer.
+> 
+> I have already explained why this is not going to happen. The cgroups
+> API in systemd is already part of the core systemd interface and subject
+> to the stability promise. The only other existing implementation
+> (cgmanager) is merely wrapping in D-Bus the existing kernel API, which
+> is going to die when a single writer becomes necessary.
+
+Err, I'm not sure I see what is stopping the provision of the systemd
+cgroup manager API by a program other than systemd.  But I haven't
+looked at this in detail.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 20:06:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 20:06:09 GMT) (full text, mbox, link).

+ +

Message #2588 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, Nikolaus Rath <Nikolaus@rath.org>
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Thu, 2 Jan 2014 12:03:35 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Thu, Jan 2, 2014 at 11:46 AM, Josselin Mouette <joss@debian.org> wrote:
+
+> Le jeudi 02 janvier 2014 à 18:30 +0000, Ian Jackson a écrit :
+> > I would hope that we can standardise on a single API to the system's
+> > single cgroup writer.
+>
+> I have already explained why this is not going to happen. The cgroups
+> API in systemd is already part of the core systemd interface and subject
+> to the stability promise. The only other existing implementation
+> (cgmanager) is merely wrapping in D-Bus the existing kernel API, which
+> is going to die when a single writer becomes necessary.
+>
+>
+It seems like you just explained how it has already happened. systemd's
+cgroup interface is covered under the stability promise, and seems like a
+good fit for a standard interface to the single cgroup arbitrator.
+
+Cameron
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 20:57:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 20:57:09 GMT) (full text, mbox, link).

+ +

Message #2593 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Thu, 02 Jan 2014 21:53:19 +0100
+
+
]] Ian Jackson 
+
+> I think it would be reasonable to state that the raise(SIGSTOP)
+> integration should be done with a new command line option OR a new
+> environment variable; ie that the daemon should not be changed to
+> raise(SIGSTOP) by default.
+
+I don't see why you think that doing so because a configuration file
+tells it to, is wrong.
+
+I think it's a bad thing to overspecify how a daemon is configured,
+which I think you're doing here.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 21:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 21:15:05 GMT) (full text, mbox, link).

+ +

Message #2598 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Thu, 02 Jan 2014 22:11:08 +0100
+
+
]] Ian Jackson 
+
+> Nikolaus Rath writes ("Bug#727708: loose ends for init system decision"):
+> > I think there is one additional questions that will probably need to be
+> > decided by the tc but hasn't really been discussed yet:
+> > 
+> > Will packages that explicity depend on a (non-default) init system be
+> > allowed in Debian?
+> 
+> My answer to this is "no".
+> 
+> So, firstly, I would say that all packages must, in jessie at least,
+> continue to support sysvinit.  Russ (from the other side of the
+> upstart/systemd fence) agrees.  Failure to support sysvinit would be
+> an RC bug.
+
+I think it would be unwise to require upstart and systemd to continue to
+support sysvinit.  I'm not even sure what that would mean, in particular
+in the case of systemd-sysv whose sole purpose is to replace sysvinit.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 21:15:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 21:15:08 GMT) (full text, mbox, link).

+ +

Message #2603 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Thu, 02 Jan 2014 13:11:57 -0800
+
+
Tollef Fog Heen <tfheen@err.no> writes:
+> ]] Ian Jackson 
+
+>> I think it would be reasonable to state that the raise(SIGSTOP)
+>> integration should be done with a new command line option OR a new
+>> environment variable; ie that the daemon should not be changed to
+>> raise(SIGSTOP) by default.
+
+> I don't see why you think that doing so because a configuration file
+> tells it to, is wrong.
+
+> I think it's a bad thing to overspecify how a daemon is configured,
+> which I think you're doing here.
+
+I basically agree with the latter point, but the reason why I wouldn't
+want to use a configuration file is that administrators are still going to
+want to start daemons by hand (such as when debugging things), presumably
+with the same configuration as when the daemon is run by the init system.
+The SIGSTOP behavior is rather confusing when you're not expecting it.
+
+That's why I prefer either environment variables (which are the easiest to
+keep clear of the administrator action, but which have the problem of
+leaking) or a command-line option (which the administrator has to remember
+to remove when starting things by hand, but which don't leak).
+
+I think it's important that anything we say here is marked as technical
+advice, as Ian helpfully distinguished in the draft proposal, which means
+that the TC is not *requiring* things and maintainers can go a different
+direction if the advice doesn't make sense.  That makes it less of a
+specification and more of a collection of things we think make sense and
+that one should probably follow unless one has thought about the problem.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 21:30:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 21:30:09 GMT) (full text, mbox, link).

+ +

Message #2608 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Tollef Fog Heen <tfheen@err.no>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: loose ends for init system decision
+
Date: Thu, 2 Jan 2014 21:27:20 +0000
+
+
Tollef Fog Heen writes ("Bug#727708: loose ends for init system decision"):
+> Ian Jackson:
+> > So, firstly, I would say that all packages must, in jessie at least,
+> > continue to support sysvinit.  Russ (from the other side of the
+> > upstart/systemd fence) agrees.  Failure to support sysvinit would be
+> > an RC bug.
+> 
+> I think it would be unwise to require upstart and systemd to continue to
+> support sysvinit.  I'm not even sure what that would mean, in particular
+> in the case of systemd-sysv whose sole purpose is to replace sysvinit.
+
+I was speaking looaely.  I meant, still loosely speaking but rather
+less so, all packages which contain daemons which are to be started by
+the init system.
+
+In my draft resolution I gave an even longer and more precise
+definition which proves still yet to have edge cases people aren't
+happy with.  But I hope you understand roughly what I'm getting at.
+
+For the avoidance of doubt, I mean to include things like inetd and
+apache and the system dbus and udev and the nameserver, but to exclude
+things like systemd-sysv and upstart-socket-bridge.
+
+The wording in my draft resolution is designed to tolerate (although
+obviously not encourage) a hypothetical daemon whose bare bones
+packaging doesn't arrange for the daemon to be started at all,
+regardless of the init system in use.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 21:39:18 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 21:39:18 GMT) (full text, mbox, link).

+ +

Message #2613 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: CTTE and Developer Buy-in [Re: Bug#727708: init + system other points, and conclusion]
+
Date: Thu, 2 Jan 2014 21:34:48 +0000
+
+
On Thu, Jan 02, 2014 at 05:51:11PM +0100, Tollef Fog Heen wrote:
+> In addition to the popcon numbers referenced from Sjoerd, we have the
+> numbers from Michael's systemd survey in May 2013.  The numbers there
+> were 35%/30%/33% for yes/dunno/no for systemd as default init when only
+> counting DD/DMs/package maintainers
+> 
+> Of course, those numbers might have changed since then.
+
+Thanks.  That's marginal enough that I guess it's not likely to be an
+obviously dominating factor, so bearing in mind Ian's comments I'm happy
+to drop this suggestion.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 21:57:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 21:57:08 GMT) (full text, mbox, link).

+ +

Message #2618 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: 727708@bugs.debian.org
+
Subject: requirement of non-forking startup protocol
+
Date: Thu, 2 Jan 2014 22:54:30 +0100
+
+
| 8. Policy rules for support for init systems must:
+| 
+|    (a) Specify the use of a non-forking startup protocol (for
+|        upstart and systemd),
+I'm not sure about upstart, but systemd is perfectly happy with
+daemons which double fork (Type=forking in systemd parlance).
+ It is mildly discouraged, because:
+
+1. it is hard to get right
+2. it is more code than the other options
+3. it is easier to start the program manually if non-forking protocol is used
+
+For new code, other protocols are certainly better. But for existing
+daemons which work correctly, points 1 and 2 don't matter, and 3 is not
+important enough.
+
+This requirement might force mantainers to modify some hairy
+internals in the startup code of daemons to avoid double forking. This
+seems pointless, as in most cases it wouldn't result in any noticable
+difference in speed or behaviour or correctness.
+
+I think this should be changed to:
+
+| 8. Policy rules for support for init systems must:
+| 
+|    (a) Encourage the use of a non-forking startup protocol (for
+|        upstart and systemd),
+
+Zbyszek
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 22:06:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 22:06:05 GMT) (full text, mbox, link).

+ +

Message #2623 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: requirement of non-forking startup protocol
+
Date: Thu, 2 Jan 2014 22:04:12 +0000
+
+
Zbigniew Jędrzejewski-Szmek writes ("Bug#727708: requirement of non-forking startup protocol"):
+> | 8. Policy rules for support for init systems must:
+> | 
+> |    (a) Specify the use of a non-forking startup protocol (for
+> |        upstart and systemd),
+
+[ Replying to this thread after a large glass of wine is probalby a
+bad idea, but this one seems OK I hope.  Please forgive me if I'm
+incoherent or rude, although of osurse I'll try not to be. ]
+
+> I'm not sure about upstart, but systemd is perfectly happy with
+> daemons which double fork (Type=forking in systemd parlance).
+>  It is mildly discouraged, because:
+> 
+> 1. it is hard to get right
+> 2. it is more code than the other options
+> 3. it is easier to start the program manually if non-forking protocol is used
+
+Am I right in thingking that this is what is described as "guess main
+pid" in the systemd documentation ?  In which case it is indeed
+discouraged.q
+
+> For new code, other protocols are certainly better. But for existing
+> daemons which work correctly, points 1 and 2 don't matter, and 3 is not
+> important enough.
+
+I think if we're going to the trouble of converting all of the init
+systems, we should do so once and have them use the best arrangements.
+
+> This requirement might force mantainers to modify some hairy
+> internals in the startup code of daemons to avoid double forking. This
+> seems pointless, as in most cases it wouldn't result in any noticable
+> difference in speed or behaviour or correctness.
+
+Does this actualy arise as a problem in practice ?  I find it
+difficult to think of a case where it would but perhaps you know of
+one.
+
+> I think this should be changed to:
+> 
+> | 8. Policy rules for support for init systems must:
+> | 
+> |    (a) Encourage the use of a non-forking startup protocol (for
+> |        upstart and systemd),
+
+In the case of upstart the -forking startup protocols are difficult to
+implement portably so in that case I think we should definitely retain
+a prohibition.
+
+I'm less sure about the systemd version of the resolution.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 22:06:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 22:06:08 GMT) (full text, mbox, link).

+ +

Message #2628 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: requirement of non-forking startup protocol
+
Date: Thu, 02 Jan 2014 14:04:28 -0800
+
+
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
+
+> | 8. Policy rules for support for init systems must:
+> | 
+> |    (a) Specify the use of a non-forking startup protocol (for
+> |        upstart and systemd),
+
+> I'm not sure about upstart, but systemd is perfectly happy with daemons
+> which double fork (Type=forking in systemd parlance).  It is mildly
+> discouraged, because:
+
+> 1. it is hard to get right
+> 2. it is more code than the other options
+> 3. it is easier to start the program manually if non-forking protocol is used
+
+> For new code, other protocols are certainly better. But for existing
+> daemons which work correctly, points 1 and 2 don't matter, and 3 is not
+> important enough.
+
+> This requirement might force mantainers to modify some hairy
+> internals in the startup code of daemons to avoid double forking. This
+> seems pointless, as in most cases it wouldn't result in any noticable
+> difference in speed or behaviour or correctness.
+
+> I think this should be changed to:
+
+> | 8. Policy rules for support for init systems must:
+> | 
+> |    (a) Encourage the use of a non-forking startup protocol (for
+> |        upstart and systemd),
+
+Yeah, this is a good point.  Since systemd uses the daemon-written PID
+file for tracking forking daemons, it doesn't have the same issues as the
+upstart expect fork or expect daemon protocols.  Obviously, an external
+PID file is not ideal, but it will work fine with systemd.  (Now, daemons
+that don't support a daemon-written PID file either will require
+modifications, but even there, patching the daemon to write a PID file may
+be less intrusive than patching it to change the startup behavior.)
+
+I think upstart doesn't have a similar capability to use an external PID
+file to figure out what process it should track, so we may have to keep
+this restriction for upstart if we really want to get rid of expect fork
+and expect daemon.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 22:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 22:15:04 GMT) (full text, mbox, link).

+ +

Message #2633 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: requirement of non-forking startup protocol
+
Date: Thu, 2 Jan 2014 22:11:03 +0000
+
+
Russ Allbery writes ("Bug#727708: requirement of non-forking startup protocol"):
+> Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
+> > I think this should be changed to:
+> > | 8. Policy rules for support for init systems must:
+> > | 
+> > |    (a) Encourage the use of a non-forking startup protocol (for
+> > |        upstart and systemd),
+> 
+> Yeah, this is a good point.  Since systemd uses the daemon-written PID
+> file for tracking forking daemons, it doesn't have the same issues as the
+> upstart expect fork or expect daemon protocols.  Obviously, an external
+> PID file is not ideal, but it will work fine with systemd.  (Now, daemons
+> that don't support a daemon-written PID file either will require
+> modifications, but even there, patching the daemon to write a PID file may
+> be less intrusive than patching it to change the startup behavior.)
+
+I would have expected protocols involving pid files to be racy.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 22:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 22:30:04 GMT) (full text, mbox, link).

+ +

Message #2638 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Bdale Garbee <bdale@gag.com>, 727708@bugs.debian.org
+
Cc: Josselin Mouette <joss@debian.org>, + Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Thu, 2 Jan 2014 14:27:14 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Thu, Jan 02, 2014 at 09:50:58AM -0700, Bdale Garbee wrote:
+> Josselin Mouette <joss@debian.org> writes:
+
+> > It shouldn’t come as a surprise that it is hard for developers to
+> > respect the TC’s decisions when we see disrespectful sentences like the
+> > one above from some of its members.
+
+> I agree.
+
+> We are of course each entitled to hold opinions about such things, but I
+> would strongly prefer if we could all try *very* hard to keep such
+> assertions out of TC discussion.  They have no place here.
+
+I recognize that we as TC members have a moral duty to not gratuitously
+demotivate Debian contributors.  However, the duty to not alienate
+contributors is secondary to our duty of defending the technical integrity
+of Debian, and so I stand behind that comment and am going to elaborate with
+reference to an example so that the other members of the TC, and the GNOME
+team, understand exactly where I'm coming from.  (The example is from a
+question that was referred to the TC in July 2012 - bug #681687 - so it may
+ring a bell for some here.)
+
+For several years the GNOME Team ignored section 9.7 of Policy, concerning
+integration with the MIME handling system.  They did this in favor of
+implementing the related freedesktop.org on the grounds that the fd.o
+standard is technically superior (and less work, since it was already
+implemented upstream).
+
+As it happens, I think the fd.o standard *is* technically superior (and I
+think any other member of the TC who looked at the question would agree).
+However, "my way is technically superior" is not a valid justification for
+ignoring Debian Policy.  Policy is not *just* about being technically
+better, it's *also* about having consistent behavior that all packages in
+the archive can coordinate around.  No single upstream, no matter how large
+or prominent they might be, has any business dictating behavior that
+contradicts Debian Policy; Debian exists as a distribution to provide a
+coherent, integrated OS, not to deliver half a dozen incompatible upstream
+experiences to our users, and when Policy needs to be changed it needs to be
+changed with transition handling in mind.
+
+Each Debian maintainer has an obligation to ensure their packages comply
+with Debian Policy, regardless of what direction upstream is headed in.
+Sometimes this means writing compatibility code that's Debian specific;
+sometimes it means getting Policy changed so that packages have new, better
+rules guiding their integration.  Never does it mean silently ignoring the
+issue as The Other Maintainer's Problem.
+
+In case anyone missed it at the time,
+https://lists.debian.org/debian-devel/2012/01/msg00830.html is the start of
+a very long thread on this topic two years ago, when it came to the
+attention of the wider project that Josselin had dropped support for mailcap
+from evince, the single pdf reader that many Debian users had installed on
+their desktop.  (Other packages, such as the eog image viewer, had dropped
+their integration long before, but with a lower impact than evince.)
+
+What struck me in that discussion is that at no point did the GNOME
+maintainers raise this issue on debian-devel or debian-policy to ask for
+help with this integration problem.  Instead, they uploaded breakage to the
+archive and waited for users to trip over it, apparently in the belief that
+if no one had provided a fix by now - /for the bug they had not asked the
+developer community for help with/ - that such an automated system was not
+important enough to worry about complying with policy for. 
+(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658139#29)
+
+Ultimately, bug #497779 and bug #658139 were resolved by someone
+volunteering, in response to that thread, to implement an automated tool for
+merging .desktop files into mailcap for backwards-compatibility.  This was
+the desirable outcome all along; however, it happened in spite of the GNOME
+Team, not because of them, and after a fair amount of good will had been
+spent on both sides in the list discussions.  I completely understand the
+GNOME Team not having time to write (or maintain) the tool to do this
+automated conversion.  What I don't find acceptable is their not bringing
+this issue to the project's attention /and asking for help/.
+
+Maybe 'obstructionist' is not the right word.  But the GNOME Team has a
+pattern of failing to engage constructively with the rest of the project
+around crucial integration issues.  Josselin claims that a comment from a TC
+member calling this out makes it difficult for developers to respect TC
+decisions.  I counter that the GNOME Team's past handling of such problems
+shows an existing lack of respect for project values and procedures, and I'm
+merely giving voice to a view widely held among Debian developers who would
+in fact be more than happy to contribute to improving GNOME's integration in
+Debian, if only they believed this help would be welcomed by the current
+package maintainers.
+
+While I stop short of calling for the formal censure of the Debian GNOME
+Team as Ian has in the past, I think the GNOME Team should take a hard look
+at how their own actions have contributed to any sense they might have that
+they lack the resources to comply with Policy.  I don't think it's a
+coincidence that over the past two years, over a quarter of all the issues
+decided by the TC have related to GNOME packages.
+
+
+To reconnect this with the actual point of this subthread:  it is entirely
+possible that the TC will decide that systemd is the technically better
+solution for Debian to move forward with; and any member who thinks this
+should certainly vote accordingly.  But if the members of the TC do
+*not* think this is true - if, indeed, our collective preference is for
+upstart rather than for systemd - then I don't think we should be swayed by
+assertions that GNOME upstream is tethering itself to a specific init system
+and that the current GNOME maintainers may force the issue by uploading
+packages to the archive that have a hard dependency on systemd as PID1. 
+That's nothing more than hostage taking, especially when there would be no
+difficulty getting cycles for the integration bugs with GNOME and whatever
+init system Debian standardized on... *provided that* the GNOME maintainers
+showed themselves open to this work instead of blocking it.  From Joss's
+reply to my message, it seems altogether too likely that he *would* block
+such work.  But that is a bridge we should cross when we come to it, not
+something we should allow to drive the future course of Debian...  nor
+something we should beat the GNOME Team up about before it's actually
+happened.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 22:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 22:33:05 GMT) (full text, mbox, link).

+ +

Message #2643 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: requirement of non-forking startup protocol
+
Date: Thu, 2 Jan 2014 23:28:33 +0100
+
+
On Thu, Jan 02, 2014 at 10:04:12PM +0000, Ian Jackson wrote:
+> Zbigniew Jędrzejewski-Szmek writes ("Bug#727708: requirement of non-forking startup protocol"):
+> > | 8. Policy rules for support for init systems must:
+> > | 
+> > |    (a) Specify the use of a non-forking startup protocol (for
+> > |        upstart and systemd),
+> 
+> [ Replying to this thread after a large glass of wine is probalby a
+> bad idea, but this one seems OK I hope.  Please forgive me if I'm
+> incoherent or rude, although of osurse I'll try not to be. ]
+In vino veritas :) Anyway, your mail seems fine :)
+
+> > I'm not sure about upstart, but systemd is perfectly happy with
+> > daemons which double fork (Type=forking in systemd parlance).
+> >  It is mildly discouraged, because:
+> > 
+> > 1. it is hard to get right
+> > 2. it is more code than the other options
+> > 3. it is easier to start the program manually if non-forking protocol is used
+> 
+> Am I right in thingking that this is what is described as "guess main
+> pid" in the systemd documentation ?  In which case it is indeed
+> discouraged.
+Not always. If PIDFile= is specified, than GuessMainPID is not necessary.
+Also, if there just one process after initialization has finished (which
+is normally true with double forking), "guessing" the main PID is trivial,
+so GuessMainPID is also fine. So it's mainly GuessMainPID=true with a dameon
+consisting of multiple processes that is discouraged.
+
+> > For new code, other protocols are certainly better. But for existing
+> > daemons which work correctly, points 1 and 2 don't matter, and 3 is not
+> > important enough.
+> 
+> I think if we're going to the trouble of converting all of the init
+> systems, we should do so once and have them use the best arrangements.
+>
+> > This requirement might force mantainers to modify some hairy
+> > internals in the startup code of daemons to avoid double forking. This
+> > seems pointless, as in most cases it wouldn't result in any noticable
+> > difference in speed or behaviour or correctness.
+> 
+> Does this actualy arise as a problem in practice ?  I find it
+> difficult to think of a case where it would but perhaps you know of
+> one.
+I don't have any examples. But as you yourself argued, changing both
+the build system and the code and init system wrapper to add this
+functionality *is* a bit of work. It's not too much work to do if
+there's a reason for it, but in case of correctly working
+double-forking daemons is see no reason. Multiplying it by all packages
+in the archive to be converted I'd much rather see maintainers doing
+things which have visible impact.
+
+> > I think this should be changed to:
+> > 
+> > | 8. Policy rules for support for init systems must:
+> > | 
+> > |    (a) Encourage the use of a non-forking startup protocol (for
+> > |        upstart and systemd),
+> 
+> In the case of upstart the -forking startup protocols are difficult to
+> implement portably so in that case I think we should definitely retain
+> a prohibition.
+> 
+> I'm less sure about the systemd version of the resolution.
+Ah, yes. So for upstart the trade-offs are different and it must stay
+as you drafted it originally.
+
+Zbyszek
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 02 Jan 2014 22:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 02 Jan 2014 22:39:04 GMT) (full text, mbox, link).

+ +

Message #2648 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: requirement of non-forking startup protocol
+
Date: Thu, 02 Jan 2014 14:37:45 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Russ Allbery writes:
+
+>> Yeah, this is a good point.  Since systemd uses the daemon-written PID
+>> file for tracking forking daemons, it doesn't have the same issues as
+>> the upstart expect fork or expect daemon protocols.  Obviously, an
+>> external PID file is not ideal, but it will work fine with systemd.
+>> (Now, daemons that don't support a daemon-written PID file either will
+>> require modifications, but even there, patching the daemon to write a
+>> PID file may be less intrusive than patching it to change the startup
+>> behavior.)
+
+> I would have expected protocols involving pid files to be racy.
+
+Yeah, most daemons that write external PID files have issues with external
+PID files left from other running instances of the same daemon.  (I assume
+that's what you're talking about.)  It's probably possible to avoid that
+with judicious use of file locking, but that's not common and is more
+complex.  It's not a great long-term solution.  But it's certainly no
+worse than what we have today, where we use daemon-written PID files
+extensively.
+
+I think the issue basically reduces to how much we want to push package
+maintainers to switch to something more reliable when it requires upstream
+changes.  Personally, I don't think the current problems with PID files
+written by daemons are sufficiently bad to outlaw them entirely, although
+I'd certainly encourage upstreams to provide non-forking behavior as at
+least an option.  But maybe it's worse than I realize?
+
+Incidentally, systemd's PID guessing support is only needed for daemons
+that are forking and *don't* write a PID file.  It's basically a version
+of expect daemon, but it's only used when daemons fork and exit and a PID
+file is not configured.  This, like expect fork and expect daemon in
+upstart, feels to me like something that we don't want to rely on, even if
+it's occasionally convenient that it exists.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 00:21:23 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 00:21:23 GMT) (full text, mbox, link).

+ +

Message #2653 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Fri, 03 Jan 2014 01:17:22 +0100
+
+
Le jeudi 02 janvier 2014 à 14:27 -0800, Steve Langasek a écrit : 
+> For several years the GNOME Team ignored section 9.7 of Policy, concerning
+> integration with the MIME handling system.  They did this in favor of
+> implementing the related freedesktop.org on the grounds that the fd.o
+> standard is technically superior (and less work, since it was already
+> implemented upstream).
+[snip] 
+> What struck me in that discussion is that at no point did the GNOME
+> maintainers raise this issue on debian-devel or debian-policy to ask for
+> help with this integration problem.
+
+You forgot to mention that the actual bug at hand affected only a small,
+although quite vocal, number of users – vocal users with a lot of time
+to spend on debian-devel (and now debian-ctte) being a recurrent issue
+in Debian nowadays.
+
+The maintainer for mime-support had been aware of the problem for more
+than three years without any change happening. There was a failure of
+Debian as a whole to have let this part of the policy rot for such a
+long time, and I’ll admit to my share of responsibility in letting that
+happen, but certainly not to the whole of it.
+
+I still stand on the opinion that, after such a long time, aggressive
+removal of legacy MIME files was a right course of action. 
+
+> I'm
+> merely giving voice to a view widely held among Debian developers who would
+> in fact be more than happy to contribute to improving GNOME's integration in
+> Debian, if only they believed this help would be welcomed by the current
+> package maintainers.
+
+Vague, unsubstantiated, false claims. Again.
+
+I do not recall the members of the team rejecting the help proposed by
+other contributors, apart from a handful of people who obviously failed
+to meet the technical standards to contribute to any Debian package. If
+there are any developers who would be happy to contribute to GNOME
+packaging but are afraid their help will be refused, any member of the
+team will be happy to soothe their fears. We have always been inclusive,
+since, as a former DPL said, “what can’t you undo?”
+
+Anyway, I have serious doubts about your allegation that manpower issues
+are related to the current team members, unless you want to extend this
+criticism to most core packaging teams. I might have to remind you that
+the kernel, glibc, KDE, GNOME, Xfce and Xorg maintainers have all
+repeatedly and publicly stated their lack of contributors and difficulty
+to handle bug reports.
+
+> I don't think it's a
+> coincidence that over the past two years, over a quarter of all the issues
+> decided by the TC have related to GNOME packages.
+
+“Over a quarter” being three issues, two of them being the same. And
+let’s not mention some TC member’s behavior regarding the handling of
+that one, shall we?
+
+> That's nothing more than hostage taking, especially when there would be no
+> difficulty getting cycles for the integration bugs with GNOME and whatever
+> init system Debian standardized on... *provided that* the GNOME maintainers
+> showed themselves open to this work instead of blocking it.  From Joss's
+> reply to my message, it seems altogether too likely that he *would* block
+> such work.
+
+This is not what I wrote. I implied that I would not contribute to it in
+any way. I know this is the point of view of some other members of the
+Debian GNOME team, but maybe not all of them. You’d have to ask them
+individually.
+
+Given the general tone of your message, I might have to remind you that
+I am not the GNOME team, especially since I have not been providing much
+packaging help during the last months. The reason why I’m the one doing
+most of the talking is that other people have been so disinterested,
+demotivated, or even disgusted, by the confrontational tone of any
+public discussion about GNOME, freedesktop or systemd that they don’t
+even want to talk about it anymore. Therefore, you should not think I am
+the most likely person to block such changes or abandon the ship while
+it is sinking.
+
+This kind of attitude is making Debian the fun topic to talk about among
+upstreams, not the major Linux player we should be. Debian as a whole
+needs to rethink how it can be more friendly to some important upstream
+projects, or we will simply stop being the “universal” operating system.
+
+-- 
+ .''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 00:33:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 00:33:17 GMT) (full text, mbox, link).

+ +

Message #2658 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Info received (Bug#727708: requirement of + non-forking startup protocol)
+
Date: Fri, 3 Jan 2014 01:30:16 +0100
+
+
> Yeah, most daemons that write external PID files have issues with external
+> PID files left from other running instances of the same daemon.  (I assume
+> that's what you're talking about.)  It's probably possible to avoid that
+> with judicious use of file locking, but that's not common and is more
+> complex.
+
+systemd will unlink the pidfile after the daemon is stopped (and during
+restart, etc.). Stale files shouldn't be an issue.
+
+Zbyszek
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 01:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 01:21:04 GMT) (full text, mbox, link).

+ +

Message #2663 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Thu, 2 Jan 2014 17:19:40 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Dec 30, 2013 at 09:52:04PM -0800, Russ Allbery wrote:
+> Steve Langasek <vorlon@debian.org> writes:
+
+> > Upstart (as implemented in Ubuntu) restores this guarantee (with
+> > provisions for failsafe booting in the case of a wrong network config),
+> > and it takes advantage of upstart's capability of sending arbitrary
+> > signals to do so.  I can see how one could implement the equivalent of
+> > upstart's static-network-up event on systemd, using generators.  But
+> > what would the equivalent to /etc/init/failsafe.conf look like?  I think
+> > this would be very difficult to express in systemd language, yet it's
+> > altogether vital for providing a boot that is both reliably ordered, and
+> > recoverable in the event of problems.
+
+> I'm not sure I completely understand what failsafe.conf actually does,
+
+The purpose of failsafe.conf is to ensure that services which have not been
+converted to the native format, but instead provide initscripts that are
+called upon reaching runlevel 2, are started at the right time - so that
+they aren't unreliable due to racing the network stack.  This is an existing
+bug on sysvinit systems, but the race is hit much less frequently there
+because sysvinit is slower.
+
+The failsafe.conf strikes a balance between never waiting for networks
+(breaking services that assume the network is up) and always waiting for all
+networks (breaking systems that have stale network configs in
+/etc/network/interfaces), by ensuring services will start as soon as all the
+static networks come up *if* they are present, and falling back to a
+"reasonable" timed delay if they're not.
+
+Without an equivalent to failsafe.conf, server systems converted from
+sysvinit to systemd will find some of their (poorly-coded, but nevertheless
+common and supported in Debian) services randomly failing to start on boot
+where they started reliably before.
+
+> So, in other words, assuming that I understand this correctly, the way
+> that you implement this in systemd is that you add a Before= dependency to
+> the network.target (hm, which implies that my assumption about things
+> meddling with dependencies of core services being less likely is not as
+> correct as I thought it was, although I still think it's less likely to be
+> done by accident) that waits for the network to be configured, but
+> implements a timeout to ensure that you don't stall forever.
+
+From your answer and Tollef's, I'm satisfied that this requirement can be
+represented in a reasonable fashion on top of systemd, probably with a
+combination of an if-up.d hook (like for upstart) and a systemd unit that
+wraps a script much like /etc/init/failsafe.conf to set a timeout.
+
+I am left with the concern that I seem to be the first person to ask this
+question, in discussions with the TC, six months after AIUI the systemd
+maintainers considered systemd ready to be made the default.  The kinds of
+race conditions that I'm highlighting here are ones that Ubuntu identified
+and resolved over the course of two years of experience with Upstart in the
+wild, at the cost of quite a bit of pain for Ubuntu's users in the meantime.
+I fear that switching Debian to systemd by default would inflict the same
+kind of pain on Debian's users, because the fixes available in Ubuntu will
+not translate directly to systemd and no other distribution that has adopted
+systemd has dealt with these issues yet.
+
+Russ, the feature gaps that you rightly point out between systemd and
+upstart, while they represent a significant amount of work, are all IMHO
+solvable for jessie.  The integration work, in contrast, feels very
+open-ended to me; I'm not worried that the work will be insurmountable, but
+that we will fail to identify the issues in a timely fashion before the
+jessie release.  I'm not saying this to deliberately engage in FUD by
+pointing to an unquantifiable risk; I genuinely fear that this *is* a risk,
+and the full extent of the risk is only becoming clear to me as a result of
+these discussions.  Ifupdown integration was one of the very first things I
+addressed after adopting the upstart package in Debian, and I would never
+have proposed people run it on their systems without this in place.  So I
+fear that switching to systemd by default is going to result in easier
+package maintenance for early adopters, but a much buggier experience for
+our users.  If we decide for systemd, what do you think is the right way to
+mitigate such problems for jessie?  Some of these issues are only going to
+be seen once people start making use of systemd in anger with their existing
+server configs (e.g., an ec2 VM with a simple disk and network config is not
+going to expose these problems), and I don't really think we want to do this
+by way of switching the default in unstable and waiting for the bugs to roll
+in.
+
+Perhaps you're right that there is such a night and day difference between
+systemd and upstart that it warrants us redoing the integration work on top
+of systemd that has already been done on top of upstart in Ubuntu.  But in
+that case I would still want to know that, while redoing that integration,
+we aren't leaving our users in the lurch.
+
+On Tue, Dec 31, 2013 at 09:36:54AM +0100, Tollef Fog Heen wrote:
+> There is none, and it would not be ifupdown-specific.  We could easily
+> enough add a «wait for a default ipv4 and ipv6 default route to appear»
+> unit if somebody desired that, which would be pulled in by
+> network-online.target.  It's a pretty trivial piece of code.
+
+> Alternatively, just put systemctl start network-online.target into a
+> fragment in if-up.d if you consider ifup considering a network interface
+> up to be enough.  (I don't, but as pointed out on the systemd wiki page
+> referenced, people have different ideas about what «network online»
+> means.)
+
+I believe the correct behavior, for compatibility with legacy sysvinit
+scripts, is to call 'systemctl start network-online.target' (or possibly,
+'systemctl start network.target') only after all statically configured
+network interfaces have been brought up.  The 'all_interfaces_up' handler
+in /etc/network/if-up.d/upstart should be directly translatable for
+systemd's purposes.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 01:45:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 01:45:15 GMT) (full text, mbox, link).

+ +

Message #2668 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstart and upgrading from sysvinit scripts
+
Date: Thu, 2 Jan 2014 17:42:29 -0800
+
+
[Message part 1 (text/plain, inline)]
+
To wrap up this subthread, I want to state clearly for the record that the
+answers that have been given here have addressed my concerns about the
+raciness of systemd socket activation.  It appears that the state of the art
+is rather substantially improved since the last time I had looked at
+Fedora's systemd deployment - I suspect as a result of continued feature
+development in systemd upstream that closed the gaps I'd previously
+identified.  Whatever the cause, while I don't believe that socket-based
+activation is strictly a necessary feature for the next generation init
+solution, I am satisfied that the systemd implementation of it isn't
+actively detrimental to the reliability or security of our systems.  (With
+my upstream hat, I am also convinced that further development is warranted
+on upstart's socket activation implementation, to bring it to feature parity
+with systemd's.)
+
+On Sun, Dec 29, 2013 at 10:37:10AM -0800, Russ Allbery wrote:
+> > Indeed, when I looked at this problem on an earlier version of Fedora, I
+> > found what I believe to be a latent security problem in the cups units,
+> > because it was nondeterministic whether the service would start with
+> > sockets passed from systemd, or a different set of sockets as defined in
+> > the cups config!
+
+> Did the cups service unit explicitly depend on its socket unit?
+
+At this point, I certainly can't remember - bearing in mind that at the time
+I was doing a comparative analysis for purposes of improving upstart, not to
+evaluate systemd for adoption, so having identified a critical problem I
+didn't dig very much farther to determine if this was fixable within the
+constraints of systemd's dependency system.
+
+Thanks,
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + + + + + +Added indication that bug 727708 blocks 670170 +Request was from intrigeri <intrigeri@debian.org> +to 670170-submit@bugs.debian.org. + (Fri, 03 Jan 2014 02:12:06 GMT) (full text, mbox, link).

+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 05:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to intrigeri <intrigeri@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 05:18:04 GMT) (full text, mbox, link).

+ +

Message #2675 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: intrigeri <intrigeri@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Fri, 03 Jan 2014 06:14:26 +0100
+
+
Hi,
+
+first, thank you for describing this problem in details.
+
+I have never met it while using systemd on Debian Wheezy and sid for
+18 months. Anyhow, with your indications at hand, I realize that my
+use cases probably fall into the category that does not expose
+this problem.
+
+Steve Langasek wrote (03 Jan 2014 01:19:40 GMT) :
+> Without an equivalent to failsafe.conf, server systems converted from
+> sysvinit to systemd will find some of their (poorly-coded, but nevertheless
+> common and supported in Debian) services randomly failing to start on boot
+> where they started reliably before.
+
+Just to check that I understood you correctly: this will be the case
+"only" for services that do not provide systemd integration, right?
+
+I'm obviously not saying we should disregard these, but I think it is
+useful for this discussion to clearly state which packages would be
+affected, and which would not.
+
+> The kinds of race conditions that I'm highlighting here are ones
+> that Ubuntu identified and resolved over the course of two years of
+> experience with Upstart in the wild, at the cost of quite a bit of
+> pain for Ubuntu's users in the meantime.
+
+Trying to better evaluate the required effort, I am wondering to what
+extend Debian would benefit from the "Ubuntu identified" part, even if
+the fixes cannot be directly translated to systemd. So, I have a few
+questions for you.
+
+First, do you expect the list of race conditions identified and
+resolved in Ubuntu to cover most of those that could hit Debian if we
+were to use systemd?
+
+Second, if we don't want to simply wait for the bugs to roll in, as
+you put it, regardless of whether we go with systemd or upstart, we
+will need to build this list at some point (to measure progress, to
+start with the most critical issues, and in last resort to document
+remaining ones in the release notes). The earlier, the better.
+I wonder how spread out the information is. Does the resolution of
+these problems live primarily in upstart jobs (easily gathered), or in
+other kinds of Ubuntu-specific patches (flagged in a special way to
+make upstreaming easier, I would hope), or elsewhere? If the answer is
+"meld in various kinds of Ubuntu-specific patches", how do we identify
+the relevant bits?
+
+It seems to me that the answer to this last set of questions is not
+only relevant in case we pick systemd, but also if we choose upstart:
+if *gathering* this list of problems and (upstart-specific) solutions
+is hard for Debian+systemd, then I fail to see why it would be easy
+for Debian+upstart.
+
+If we agree that compiling this list will be needed at some point
+anyway, I'm now wondering if it would perhaps be useful input for the
+current decision making process: not only it would help us assert the
+scope of the problem, but it would avoid a potential outcome I am
+personally scared about: after picking upstart in part because
+integrating it would be so much easier, realizing later that, oh well,
+the best we can do is often to go dig stuff from
+https://patches.ubuntu.com/ as we see bug reports roll in.
+
+> [...] no other distribution that has adopted systemd has dealt with
+> these issues yet.
+
+If I were among the ones who make the decision, I would want to see
+this statement supported by a list of bugs caused by this fact, that
+were reported against distributions that ship systemd by default.
+Anyway, I'm curious, but if I'm the only one who cares, please don't
+waste your time on it :)
+
+Also, I suppose that Red Hat is actively tackling these issues, with
+RHEL7 now in beta. It is not clear to me what amount of their fixes we
+can (find and) take if we pick systemd. Same here, depends how broadly
+the fixes are gathered, and how deeply they are meld in with changes
+we do not care about, I guess.
+
+> If we decide for systemd, what do you think is the right way to
+> mitigate such problems for jessie?  Some of these issues are only going to
+> be seen once people start making use of systemd in anger with their existing
+> server configs (e.g., an ec2 VM with a simple disk and network config is not
+> going to expose these problems), and I don't really think we want to do this
+> by way of switching the default in unstable and waiting for the bugs to roll
+> in.
+
+I think that designing a good plan depends quite a bit on the answer
+to questions above, wrt. reusing the list of race conditions
+identified by Ubuntu, and the corresponding list of fixes.
+
+Cheers,
+-- 
+  intrigeri
+  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
+  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 08:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Piotr Meyer <aniou@smutek.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 08:45:04 GMT) (full text, mbox, link).

+ +

Message #2680 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Piotr Meyer <aniou@smutek.pl>
+
To: 727708@bugs.debian.org
+
Subject: bystander note about systemd role
+
Date: Fri, 3 Jan 2014 09:31:46 +0100
+
+
Side note from bystander: in this, fascinating thread I mention one, 
+small thing: systemd is disputed here only as primary init system.
+
+But systemd is on fast track to evolving into something bigger and
+larger than process supervisor - something like universal platform
+for LinuxOS, like - I don't know how properly describe it with one
+word - maybe like Android? It is not my personal impression, it was
+articulated - for example - by Lennart Poetering, as cited in [1]:
+
+...
+Note that systemd is not an init system (since quite a while), it's
+a basic set of userspace tools to build an OS from. And hell yes, sane
+IPC is something we believe should be at the core of every OS, and hence
+it needs to be at the core of what systemd does.
+...
+
+Also, at this moment, Debian still claims that "we are trying to
+produce, amongst other things, a free Unix"[2], but some of devs 
+involved into systemd or kdbus development and many supporters
+seconded opinion that "unix philosophy is dead" as - for example
+- in following thread and mentioned LWN comments[3].
+
+From my, humble POV, in this thread TC should also dispute about
+general direction for Debian project - because systemd brings more
+changes to whole system than - simply - "removing /etc/init.d and
+/etc/inittab in favour of new init system alternatives". 
+
+
+1 - https://plus.google.com/117255203942825212306/posts/ZpW1Pa2TWin
+2 - http://www.debian.org/doc/debian-policy/footnotes.html
+3 - https://plus.google.com/111049168280159033135/posts/2nnvNVmAPRV
+
+Just my two cents,
+-- 
+Piotr 'aniou' Meyer
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 09:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sjoerd Simons <sjoerd@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 09:00:05 GMT) (full text, mbox, link).

+ +

Message #2685 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sjoerd Simons <sjoerd@debian.org>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Cc: Bdale Garbee <bdale@gag.com>, Josselin Mouette <joss@debian.org>, Ian + Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Fri, 03 Jan 2014 09:48:39 +0100
+
+
On Thu, 2014-01-02 at 14:27 -0800, Steve Langasek wrote:
+> On Thu, Jan 02, 2014 at 09:50:58AM -0700, Bdale Garbee wrote:
+> > Josselin Mouette <joss@debian.org> writes:
+> 
+> > > It shouldn’t come as a surprise that it is hard for developers to
+> > > respect the TC’s decisions when we see disrespectful sentences like the
+> > > one above from some of its members.
+> 
+> > I agree.
+> 
+> > We are of course each entitled to hold opinions about such things, but I
+> > would strongly prefer if we could all try *very* hard to keep such
+> > assertions out of TC discussion.  They have no place here.
+> 
+> I recognize that we as TC members have a moral duty to not gratuitously
+> demotivate Debian contributors.  However, the duty to not alienate
+> contributors is secondary to our duty of defending the technical integrity
+> of Debian, and so I stand behind that comment and am going to elaborate with
+> reference to an example so that the other members of the TC, and the GNOME
+> team, understand exactly where I'm coming from.  (The example is from a
+> question that was referred to the TC in July 2012 - bug #681687 - so it may
+> ring a bell for some here.)
+
+I fail to see how further digging into this topic is relevant to the
+discussion at hand. 
+
+I would however like to state that as a member of the gnome, I've
+personally repeatedly been very demotivated by these lines of
+discussions both as part of the TC process and outside. And, again,
+personally, I simply tend to stay out of public discussion in Debian
+around gnome/systemd/pulseaudio etc as they tend to filled or at least
+overshadowed with assumptions of bad faith and mistrust that it takes a
+disproportionate amount of energy to get to any constructive conclusion
+if such a conclusion is at all possible. Instead i prefer to spent the
+little time i have for Debian on constructive things that actually
+benefit our users.
+
+However, again, none of this is relevant for the init system discussion.
+So if there is a need to continue on this  topic in a constructive
+manner, please feel free to but lets move it out of the TC discussion.
+
+-- 
+Sjoerd Simons <sjoerd@debian.org>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 09:57:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Raphael Hertzog <hertzog@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 09:57:08 GMT) (full text, mbox, link).

+ +

Message #2690 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Raphael Hertzog <hertzog@debian.org>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Fri, 3 Jan 2014 10:53:29 +0100
+
+
On Thu, 02 Jan 2014, Steve Langasek wrote:
+> our users.  If we decide for systemd, what do you think is the right way to
+> mitigate such problems for jessie?  Some of these issues are only going to
+> be seen once people start making use of systemd in anger with their existing
+> server configs (e.g., an ec2 VM with a simple disk and network config is not
+> going to expose these problems), and I don't really think we want to do this
+> by way of switching the default in unstable and waiting for the bugs to roll
+> in.
+
+Why not?
+
+I have been happily using systemd on my laptops for multiple months now
+and while this probably doesn't cover some of the problems you expect in
+complex server environment, I fail to see why unstable integration would
+not be the right path forward.
+
+> Perhaps you're right that there is such a night and day difference between
+> systemd and upstart that it warrants us redoing the integration work on top
+> of systemd that has already been done on top of upstart in Ubuntu.  But in
+> that case I would still want to know that, while redoing that integration,
+> we aren't leaving our users in the lurch.
+
+What users? It seems to me that the desktop case is not so problematic as
+to warrant special measure. The server case is not really concerned with
+unstable (most servers run stable). The real question is how to discover
+those potential bugs affecting servers precisely when those users
+are not using unstable?
+
+Cheers,
+-- 
+Raphaël Hertzog ◈ Debian Developer
+
+Discover the Debian Administrator's Handbook:
+→ http://debian-handbook.info/get/
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 10:30:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sune Vuorela <sune@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 10:30:19 GMT) (full text, mbox, link).

+ +

Message #2695 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sune Vuorela <sune@debian.org>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Cc: Josselin Mouette <joss@debian.org>, Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Fri, 03 Jan 2014 11:29:24 +0100
+
+
On Thursday 02 January 2014 14:27:14 Steve Langasek wrote:
+> For several years the GNOME Team ignored section 9.7 of Policy, concerning
+> integration with the MIME handling system.  They did this in favor of
+> implementing the related freedesktop.org on the grounds that the fd.o
+> standard is technically superior (and less work, since it was already
+> implemented upstream).
+
+Normally my interactions with the GNOME Team is friendly mockery. But 
+sometimes one has to stand up next to them.
+
+I've ignored the mime handling system as a part of the KDE Team.
+I've ignored the menu system as a part of the KDE Team. And I have a plan to 
+even more aggressively ignore it (as in, hide it from the menu).
+
+Both things are ancient relics that should have been dealt with by removal. 
+
+I tried bring the latter thru the policy process, but given one of the few 
+people who cares strongly about the debian menu is also a policy delegate, it 
+is just a uphill battle and much easier to just move on.
+
+>  But if the members of the TC do
+> *not* think this is true - if, indeed, our collective preference is for
+> upstart rather than for systemd - then I don't think we should be swayed by
+> assertions that GNOME upstream is tethering itself to a specific init system
+
+It is not only GNOME upstream that is heading towards systemd as the way to do 
+things. It is also where stuff is heading in KDE land.
+
+/Sune
+-- 
+Genius, I'm not able to cancel the mousepad of a SIMM, how does it work?
+
+The point is that you neither can ever explore the analogic program, nor have 
+to ping a printer for saving the SCSI gadget on a proxy over a parallel 
+button.
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 12:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 12:27:04 GMT) (full text, mbox, link).

+ +

Message #2700 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Sune Vuorela <sune@debian.org>, + 727708@bugs.debian.org
+
Cc: Steve Langasek <vorlon@debian.org>, + Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Fri, 3 Jan 2014 12:22:44 +0000
+
+
Sune Vuorela writes ("Bug#727708: init system other points, and conclusion"):
+> I've ignored the menu system as a part of the KDE Team. And I have a plan to 
+> even more aggressively ignore it (as in, hide it from the menu).
+> 
+> Both things are ancient relics that should have been dealt with by removal. 
+> 
+> I tried bring the latter thru the policy process, but given one of
+> the few people who cares strongly about the debian menu is also a
+> policy delegate, it is just a uphill battle and much easier to just
+> move on.
+
+That's a shame.
+
+The TC exists not just to contradict desktop software maintainers; our
+job includes contradicting policy maintainers too.  And indeed if you
+want us to contradict the policy delegates you only need a simple
+majority in the committee.
+
+Our menu arrangements have been unsatisfactory for some time and I for
+one would certainly be open to change.  Now is probably not the right
+time for this, but maybe after we've dealt with the init system
+question, you'd like to write up a summary of the situation, and
+propose a transition plan.  If the policy editors don't see it your
+way this is certainly something that the TC should be interested in.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 17:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thomas Goirand <zigo@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 17:39:04 GMT) (full text, mbox, link).

+ +

Message #2705 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thomas Goirand <zigo@debian.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: additional OpenRC information: OpenRC now in Debian + Experimental!
+
Date: Sat, 04 Jan 2014 01:35:47 +0800
+
+
On 01/03/2014 01:25 AM, Russ Allbery wrote:
+> As I mentioned in some of my previous notes, I was unable to evaluate
+> OpenRC in a meaningful way during my general experiments for a few
+> reasons.  My impression was formed based on previous discussion and what
+> documentation I could find, which was fairly minimal.
+> 
+> Thomas Goirand sent me considerably more information, including some
+> details about OpenRC project goals that corrects information in my
+> original writeup.  With his permission, I'm including that here for the
+> benefit of everyone else who is following this debate.
+> 
+> Thomas, please follow up with anything that I left out or anything else
+> that you think people should be aware of.
+
+Well, there's something that people should be aware of...
+
+OpenRC is now in Debian experimental! \o/
+
+Also:
+
+* I have solved the problem with reinstalling the initscript package (it
+was only a missing /etc/runlevels/single folder, which by the way is now
+populated with the correct symlinks so single user mode also works from
+now on).
+
+* The first reboot can be done using:
+
+for file in /etc/rc0.d/K*; do
+	s=`basename $(readlink "$file")`
+	/etc/init.d/$s stop
+done
+
+That fits on a single line, so the postinst script of OpenRC just warns
+that this command should be performed by the user when migrating from
+sysv-rc to OpenRC. When doing this, the first shutdown is kind of clean.
+While not perfect (yet), that's a workaround. Unfortunately, with
+sysv-rc, there's no way to know which daemon is started, so it's also
+impossible to stop them cleanly. Though probably attempting to stop them
+all should work. I'm open to any suggestion to make this better, and
+maybe have a way to build a script that users could call directly. Note
+that when migrating back from OpenRC to sysv-rc, there's no such a
+problem, it just works (since sysv-rc is stateless).
+
+I of course welcome anyone to try OpenRC and report bugs.
+
+Cheers,
+
+Thomas Goirand (zigo)
+
+P.S: I'd like to publicly thank Patrick Lauer, Benda (李明宇), Bill
+Wang, Roger Leigh, WilliamH & qnikst (sorry, I only know the IRC nicks
+of these last 2 persons) for their help and support when porting OpenRC
+to Debian.
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 17:45:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 17:45:14 GMT) (full text, mbox, link).

+ +

Message #2710 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Thomas Goirand <zigo@debian.org>, + 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: additional OpenRC information: OpenRC now in Debian Experimental!
+
Date: Fri, 3 Jan 2014 17:42:09 +0000
+
+
Thomas Goirand writes ("Bug#727708: additional OpenRC information: OpenRC now in Debian Experimental!"):
+> OpenRC is now in Debian experimental! \o/
+
+Good, thanks.
+
+> I of course welcome anyone to try OpenRC and report bugs.
+
+Can you point me to the relevant reference documentation ?
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 18:09:48 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 18:09:48 GMT) (full text, mbox, link).

+ +

Message #2715 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Fri, 03 Jan 2014 10:02:01 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> | Choice of init system:
+> | 
+> | 1. The default init(1) in jessie will be upstart.
+> |
+> | 2. Architectures which do not currently support upstart should try to
+> |    port it.  If this is not achieved in time, those architectures may
+> |    continue to use sysvinit.  [ Non-use of upstart should not be a
+> |    criterion for architecture qualification status in jessie. ]
+> | 
+> | 3. At least in jessie, unless a satisfactory compatibility approach is
+> |    developed and deployed (see paragraph 10), packages must continue
+> |    to provide sysvinit scripts.  Lack of a sysvinit script (for a
+> |    daemon which contains integration with at least one other init
+> |    system) is an RC bug in jessie.
+
+
+As said elsewhere, I think there should be a paragraph about packages
+that depend on a specific init system for reasons other than service
+startup, e.g.
+
+4. The above criterium also extends to dependencies that are not related
+   to service startup. In jessie, no package may depend on a single
+   initsystem other than sysvinit. After jessie, no package may depend
+   on a single init system other than the default init.
+
+or alternatively   
+
+4. Packages may, however, depend on a specific init system (which may
+   not be the default init) for features that are not related to daemon
+   startup. Such packages will only be installable on systems running a
+   non-default init, but are permitted in the archive.
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 19:00:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 19:00:07 GMT) (full text, mbox, link).

+ +

Message #2720 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Fri, 03 Jan 2014 20:57:56 +0200
+
+
On Fri, 2014-01-03 at 10:02 -0800, Nikolaus Rath wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > | 3. At least in jessie, unless a satisfactory compatibility approach is
+> > |    developed and deployed (see paragraph 10), packages must continue
+> > |    to provide sysvinit scripts.  Lack of a sysvinit script (for a
+> > |    daemon which contains integration with at least one other init
+> > |    system) is an RC bug in jessie.
+> 
+> 
+> As said elsewhere, I think there should be a paragraph about packages
+> that depend on a specific init system for reasons other than service
+> startup, e.g.
+
+Even restricted to just service startup, I think that's a rather strict
+limitation. Suppose an upstream releases a new daemon that is intended
+to be used with systemd using socket activation, and as such does not
+contain any code to do double-forking or open listening sockets. Would
+it be forbidden to package this daemon in Debian unless the maintainers
+are willing to add forking, other startup and socket code as Debian-
+specific patches? If it would, how much functionality would the
+maintainers need to add for a minimal accepted version - for example
+would they need to add new options to specify which port to listen on,
+or is opening a hard-coded default port enough for the added socket
+code? Adding support for everything that systemd socket activation
+automatically supports would not be realistic.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 19:09:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 19:09:05 GMT) (full text, mbox, link).

+ +

Message #2725 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Nikolaus Rath <Nikolaus@rath.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Fri, 3 Jan 2014 19:07:10 +0000
+
+
Nikolaus Rath writes ("Bug#727708: init system discussion status"):
+> As said elsewhere, I think there should be a paragraph about packages
+> that depend on a specific init system for reasons other than service
+> startup, e.g.
+
+I agree with this.
+
+> 4. The above criterium also extends to dependencies that are not related
+>    to service startup. In jessie, no package may depend on a single
+>    initsystem other than sysvinit. After jessie, no package may depend
+>    on a single init system other than the default init.
+
+I don't think the default init should have an exception.  The
+alternative is that installing such a package might switch your init
+system to satisfy the dependencies!
+
+And I think all these bugs should be RC.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 20:06:25 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Alexander E. Patrakov" <patrakov@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 20:06:25 GMT) (full text, mbox, link).

+ +

Message #2730 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Alexander E. Patrakov" <patrakov@gmail.com>
+
To: 727708@bugs.debian.org, Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 02:04:58 +0600
+
+
Uoti Urpala wrote:
+
+> Suppose an upstream releases a new daemon that is intended
+> to be used with systemd using socket activation, and as such does not
+> contain any code to do double-forking or open listening sockets. Would
+> it be forbidden to package this daemon in Debian unless the maintainers
+> are willing to add forking, other startup and socket code as Debian-
+> specific patches?
+
+Wrong question. As an author of one closed-source daemon that indeed
+does not implement double-forking, I made my unofficial Debian package
+depend on the "daemon" package. Result: the "daemon" utility performs
+that double-forking dance for me and restarts my daemon if it crashes.
+If the restart-on-crash functionality is not wanted, then the regular
+start-stop-daemon should be sufficient.
+
+So I'd say: Debian should support daemons that don't contain
+double-forking or socket-opening code, and should do so without
+patching such daemons. Patching or providing one Debian-specific
+utility (e.g. start-stop-daemon) should be enough.
+
+Or in other words: it is technically possible to write a
+Debian-specific "universal readiness protocol translator" that wraps a
+program that provides one readiness protocol and thus makes it
+compatible with the init system that expects another protocol.
+
+-- 
+Alexander E. Patrakov
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 20:12:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 20:12:15 GMT) (full text, mbox, link).

+ +

Message #2735 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: "Alexander E. Patrakov" <patrakov@gmail.com>
+
Cc: 727708@bugs.debian.org, Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Fri, 03 Jan 2014 12:11:39 -0800
+
+
"Alexander E. Patrakov" <patrakov@gmail.com> writes:
+> Uoti Urpala wrote:
+
+>> Suppose an upstream releases a new daemon that is intended to be used
+>> with systemd using socket activation, and as such does not contain any
+>> code to do double-forking or open listening sockets. Would it be
+>> forbidden to package this daemon in Debian unless the maintainers are
+>> willing to add forking, other startup and socket code as Debian-
+>> specific patches?
+
+> Wrong question. As an author of one closed-source daemon that indeed
+> does not implement double-forking, I made my unofficial Debian package
+> depend on the "daemon" package. Result: the "daemon" utility performs
+> that double-forking dance for me and restarts my daemon if it crashes.
+> If the restart-on-crash functionality is not wanted, then the regular
+> start-stop-daemon should be sufficient.
+
+This is fine for daemons that don't fork (as you say, start-stop-daemon is
+probably adequate), but less appealing for daemons that are written to
+require socket activation.  You would basically have to write the socket
+binding code that systemd provides.
+
+That being said, this problem seems fairly theoretical.  I'm not aware of
+any upstream code that *requires* socket activation and that people want
+to package for Debian for jessie, so I'm inclined to err on the side of
+supporting interoperability with sysvinit for the next stable.  If the
+problem later comes up, we can always take a look.
+
+If we select either upstart or systemd, we're going to be taking a rather
+dramatic step forward.  I don't think there's a need to rush it too much,
+and there are some major advantages in allowing users to switch back to
+sysvinit in jessie if they need to.  (More on that in a later message.)
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 20:18:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 20:18:05 GMT) (full text, mbox, link).

+ +

Message #2740 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Fri, 3 Jan 2014 20:15:49 +0000
+
+
Russ Allbery writes ("Bug#727708: init system discussion status"):
+> The thrust of this seems right, but I dislike telling people what to do.
+> Can we recast this in a way that avoids that problem?  Maybe something
+> like:
+
+Sure.  I borrowed your text and edited it slightly for clarity.  I
+also changed "upstart/systemd" to "upstart", for two reasons: one is
+that at this stage I'd prefer to try to maintain only one version of
+this text.
+
+And the other is that IMO the proposed prescription for non-Linux
+ports doesn't make sense for systemd.  There is little prospect of
+systemd being "ported" to those systems.
+
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > | 3. At least in jessie, unless a satisfactory compatibility approach is
+> > |    developed and deployed (see paragraph 10), packages must continue
+> > |    to provide sysvinit scripts.  Lack of a sysvinit script (for a
+> > |    daemon which contains integration with at least one other init
+> > |    system) is an RC bug in jessie.
+> 
+> This needs the same exception as is currently in Policy 9.11, namely:
+> 
+>     An exception to this rule is scripts or jobs provided by the init
+>     implementation itself; such jobs may be required for an
+>     implementation-specific equivalent of the /etc/rcS.d/ scripts and may
+>     not have a one-to-one correspondence with the init scripts.
+
+I've written a version of Niklaus's rule about dependencies:
+
+   Likewise, packages must not Depend on or Recommend (directly or
+   indirectly) a specific init(1).  Violations of this are also an RC
+   bug in jessie.
+
+And:
+
+   Theses rules do not apply to machinery which itself forms part of
+   the implementation of one or more init systems.
+
+That seems to be the clearest way to put the matter.
+
+> "Should delay" is a bit strong given that we have many packages in the
+> archive that already provide native support for upstart, and several
+> (including ones maintained by both Colin and myself) that have native
+> support for systemd.  Maybe something more like:
+> 
+>     Contributors who have not already added native support for upstart,
+>     systemd, or OpenRC may wish to wait until the relevant Debian Policy
+>     is declared, by the Policy editors, to be ready.  Early adopters
+>     should be aware that the requirements may change and their packages
+>     may require updates.
+
+I like this and have included it.
+
+> > |    (b) Use facilities documented in the reference manuals for the init
+> > |        system in question (as found in sid).  [ This requirement
+> > |        cannot be met until the init system has a suitable reference
+> > |        manual. ]
+> > | 
+> > |    (c) Require that environment variables and fds involved in the
+> > |        daemon startup protocol should not in general be inherited by
+> > |        the daemon's descendants.
+> > | 
+> > |    (d) Forbid the introduction of embedded copies of library code
+> > |        (or the use of any embedded copies included by upstream).
+> 
+> I'm not sure what the point of (b) is.  I think (d) is too strong.  Policy
+> 4.13 currently says:
+
+(b) is probably irrelevant given the rest of the resolution.  I have
+deleted it but not (for now) renumbered the rest.
+
+If (d) is removed from here then I think it needs to be included in 6C.
+
+> I think Policy 4.13 already covers this adequately and we don't need to
+> say anything further in the decision.
+
+I would like to be clear that maintainers don't need to take patches
+that introduce embedded copies of sd_notify.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 23:42:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 23:42:05 GMT) (full text, mbox, link).

+ +

Message #2745 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Fri, 03 Jan 2014 15:38:26 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> The purpose of failsafe.conf is to ensure that services which have not
+> been converted to the native format, but instead provide initscripts
+> that are called upon reaching runlevel 2, are started at the right time
+> - so that they aren't unreliable due to racing the network stack.  This
+> is an existing bug on sysvinit systems, but the race is hit much less
+> frequently there because sysvinit is slower.
+
+Okay, thanks, that's pretty much what I'd thought.  Yes, that's what in
+systemd one should address via network-online.target and some sort of
+local integration that implements whatever "network is up" policy that you
+want to enforce.
+
+Given that ifupdown is still by far the best way to manage networks on
+servers, and most of these init issues are most likely to happen on
+servers, I think we should add some sort of ifupdown integration with the
+network-online.target in the Debian systemd package that matches Debian's
+current definition of the LSB $network target.
+
+systemd's upstream is entirely correct that $network is rather
+underspecified from an LSB perspective, but Debian *does* have a
+definition, and the principle of least surprise says that we should
+duplicate that definition in a new init system.  I assume that's what
+failsafe.conf is effectively doing for upstart.
+
+> I am left with the concern that I seem to be the first person to ask
+> this question, in discussions with the TC, six months after AIUI the
+> systemd maintainers considered systemd ready to be made the default.
+
+Well, one, that's why we have these discussions.  More eyes on things like
+this are going to find issues that we need to deal with.  And your
+expertise in the sorts of issues Ubuntu encountered is very helpful.
+
+And, second, we're talking about problems that will happen with badly
+written local init scripts and are less likely to happen with packages in
+the archive (which are more likely to be well-written).  I'm not
+particularly surprised that systemd early adopters don't have a lot of
+badly-written local init scripts that they continue to use.
+
+> So I fear that switching to systemd by default is going to result in
+> easier package maintenance for early adopters, but a much buggier
+> experience for our users.  If we decide for systemd, what do you think
+> is the right way to mitigate such problems for jessie?  Some of these
+> issues are only going to be seen once people start making use of systemd
+> in anger with their existing server configs (e.g., an ec2 VM with a
+> simple disk and network config is not going to expose these problems),
+> and I don't really think we want to do this by way of switching the
+> default in unstable and waiting for the bugs to roll in.
+
+I think there are multiple tiers of answers to this question.
+
+Changing init systems is going to be disruptive.  There's simply no way
+around that.  It was disruptive when we switched to dependency-based boot,
+which also surfaced tons of problems with local init scripts and caused a
+lot of users to complain.  It's going to be disruptive when we switch to
+any other new init system.  That's just the nature of the beast.
+
+This is one of the reasons why I think we should support booting jessie
+with sysvinit.  This parallels the migration path that we took for
+dependency-based boot.  We make it clear what the new default is, but if
+people run into trouble, they can always fall back to sysvinit to get
+their stuff working again.  It gives people a release cycle of leeway
+before they *have* to make sure their systems work with the new init
+system since, indeed, problems with local hacks are unlikely to start
+showing up until we release the new init system in stable.
+
+I therefore think we should use a very similar approach to what we did
+with dependency-based boot.  We're already in the first stage of that:
+systemd is available as an option in unstable.  A bunch of people are
+using it, and have been using it for a while, and are reporting problems.
+The next step will be to start pushing for broader adoption, and possibly,
+if we can figure out a good way to do it so that people can switch back,
+have dist-upgrade switch systems to systemd.  (Of course, we would do this
+after we've hammered out the Policy work.)
+
+Then, when we release, there will obviously need to be a discussion of
+this in the release notes, as well as instructions on how to fall back to
+sysvinit, and possibly additional notes about common problems based on
+what we uncover from early upgrade reports.
+
+So, in other words, I do think a large component of the solution is to,
+indeed, switch in unstable and let the bugs roll in, which is how Debian
+tests everything.  We can stage things somewhat more (for example, I think
+we should actively encourage Debian developers to switch to the new
+default in advance and report problems), but at the end of the day that's
+going to be a large part of the testing process, just like it was with
+dependency-based boot.
+
+Now, you are entirely correct that integration with upstart would probably
+be easier and moderately less disruptive than integration with systemd
+simply because Ubuntu has already done a large portion of that work.  Red
+Hat and SuSE are also doing systemd conversions, and we will be able to
+share experiences with them and do some amount of mutual testing, but that
+isn't the same as doing a conversion based on the packages that we share
+with Ubuntu.  upstart certainly has a head start there.
+
+However, that said, I believe the integration of systemd will actually be
+easier in the long run because upstart is rather... weird.  Once we get to
+the point where we're not just trying to get legacy init scripts working
+the same way and Debian developers are writing native configurations, I
+think systemd will do much better.  As discussed at some length in the
+other branch about upstart's event model, I think upstart's way of
+handling dependencies is very strange and difficult to wrap one's mind
+around.  There are a range of weird gotchas that are inobvious if you've
+not used it extensively and if you've not wrapped your mind around the way
+it's supposed to work.
+
+See, for example, the other thread about how one should declare a
+dependency in an upstart configuration such that the service won't be
+started (including by manual administrator action) unless the dependency
+has been made available.  This is straightforward in systemd and appears
+to be surprisingly confusing in upstart.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 03 Jan 2014 23:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 03 Jan 2014 23:51:05 GMT) (full text, mbox, link).

+ +

Message #2750 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Fri, 03 Jan 2014 15:46:34 -0800
+
+
Russ Allbery <rra@debian.org> writes:
+
+> However, that said, I believe the integration of systemd will actually
+> be easier in the long run because upstart is rather... weird.
+
+On that front, I also wanted to ask about:
+
+    https://bugs.launchpad.net/upstart/+bug/447654
+
+If I'm understanding this bug correctly, it's another case where upstart's
+dependencies work (at least currently) in rather surprising ways that you
+have to understand fairly well to work around.  But I wasn't sure if this
+was just a stray left-over bug for an issue that hadn't yet been resolved,
+so I wanted to keep it separate from the broader argument.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 00:36:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 00:36:05 GMT) (full text, mbox, link).

+ +

Message #2755 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Fri, 03 Jan 2014 16:33:02 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Russ Allbery writes ("Bug#727708: init system discussion status"):
+
+>> Another issue, which I did not address here but which we should
+>> probably say something about, is that the init process 1 implementation
+>> and the system used to run daemon configuration and startup jobs is
+>> separable, and in fact is separated in OpenRC.  We should be clear
+>> about what we're talking about, particularly when it comes to non-Linux
+>> ports.
+
+> I'm not sure what kind of things you are proposing should be in the
+> resolution text (or, what in my proposal is wrong).  Is it not
+> sufficient to say that people should accept openrc patches as and when
+> the openrc policy is done ?
+
+Thinking about it some more, I think the only other place where this
+affects the decision is if we want to say something about requesting that
+the non-Linux ports adopt the same init system if they both can't use the
+default.  We presumably wouldn't want one of them using sysvinit and the
+other one using OpenRC, since then we're potentially supporting three
+different default init systems from the perspective of what init system
+means to packagers (what syntax the configuration files are in).
+
+>> One possibilty is to explicitly say that we'll make it ourselves after
+>> the jessie release.
+
+> I don't want to do this in case it turns out to be uncontroversial.
+
+Good point.  I think we can just drop the mention.
+
+>> I'm not at all fond of this approach.  Neither the upstart nor the
+>> systemd notification processes are so unreasonable as to warrant the TC
+>> explicitly asking the projects to change their designs.
+
+> I think that's not the right the question.  The real question is this:
+
+> Are the protocols offered by systemd and upstart each so plainly
+> reasonable, that we are willing to overrule a maintainer who feels they
+> protocol they are asked to support is too ugly or burdensome ?  Are such
+> a maintainer's objections so unreasonable ?
+
+Ah, okay, I see what you're getting at.
+
+I think they are.  Furthermore, I don't think there's any likely prospect
+that either will adopt a socket-based synchronization protocol other than
+systemd's, so saying that these aren't patches maintainers are required to
+take pretty much says that maintainers aren't required to integrate with
+the synchronization protocols.
+
+We could do that.  In general, I'd really prefer to defer to maintainers
+on what they're willing to integrate with.  I was somewhat leaning in that
+direction earlier, in that I'm worried pre-deciding that we're going to
+force maintainers to do something that might never happen just raises the
+discomfort level to possibly no purpose.  But you're correct that it's
+setting up a situation where some maintainers could make life difficult
+for projects that people care about, and result in further arguments
+appealed to the TC, which is uncomfortable for everyone involved.
+
+My inclination would be to give maintainers technical advice to accept
+integrations with either existing synchronization protocols, but leave it
+as technical advice rather than the binding part of the decision.
+
+>>> |    Failure to apply reasonable patches, including failure to explain
+>>> |    promptly and constructively why a patch is not reasonable, is
+>>> |    likely to lead to the maintainer being overruled. ]
+
+>> I think we already covered this with "should" in the first sentence of
+>> this section without needing to make an explicit threat.
+
+> I would like to include this because it will stiffen our resolve.
+
+I must admit I'm not particularly interested in having my resolve
+stiffened.
+
+> It also includes the important point that it is up to the maintainer to
+> justify non-inclusion, not the other way around.
+
+I guess the question here is how many conflicts we anticipate and whether
+it's worth being somewhat confrontational ourselves to head it off.  If
+there aren't conflicts in practice, we're just creating conflict without a
+need.  I don't think it matters a tremendous amount, though.
+
+> The main practical reason for ruling this out, and converting existing
+> packages, is that not all the ports of upstart can be expected to
+> implement the underlying strace mechanism used by upstart to implement
+> these.
+
+Oh, good point.  I forgot about that.
+
+>>> | Cross-init-system compatibility:
+>>> | 
+>>> | 10. Debian contributors are encouraged to explore and develop ways in
+>>> |    which a package can provide support for non-forking startup in
+>>> |    multiple different init systems without having to have separate
+>>> |    support for each init system in the source package; and, ideally,
+>>> |    without having to have separate support for each init system in the
+>>> |    binary package.
+
+>> I don't see anything objectionable about this, but I also don't really
+>> understand why it's important for us to say it.  But regardless, I
+>> think this should be in brackets?  It sounds like technical advice per
+>> the preamble.
+
+> Yes, I just failed to bracket it.
+
+> I want to put this in because I'd like to be able to drop sysvinit in
+> (its current form at least) in jessie+1, without duplicating or
+> triplicating all the init system integration work.
+
+> Putting this in here sends a signal that we would look favourably on
+> some kind of compatibility layers.  I don't think it's essential if
+> people object to it.
+
+Okay, that seems fine to me.  It certainly seems harmless, and it would be
+nice if we could get there.
+
+>> This all seems nice in theory but rather problematic in practice.
+
+>> [...]  In other words, I don't think this should apply to, for
+>> instance, use of FDO desktop files for menus instead of the Debian menu
+>> system, since both can continue to work in parallel and neither takes
+>> over from the other in a way that prevents the other from working.
+
+> I don't agree.  Unless we either have a compatibility shim, or a policy
+> decision to transition, every package ought to be required to provide
+> something in the Debian menus.  Isn't this situation analogous to the
+> mime-support argument where we required a package to reinstate a mime
+> entry ?
+
+Sorry, I didn't state my objection very well.  I wasn't talking about
+packages removing menu files.
+
+Rather, your original wording to me sounds like introducing support for
+desktop files in Debian would violate this guidance unless the one
+introducing that support went through the Policy process first, even if
+the new support did not conflict with menus and did not break anything
+about menus.  That seems wrong.
+
+In other words, just introducing something that is intended as a
+replacement for some existing Debian functionality should not require
+coordinating with anyone.  What requires coordination is the point at
+which the new functionality starts breaking the old functionality, so that
+the project as a whole can decide that either we need to do something else
+or that the old functionality isn't important and it's fine to break it.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 00:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 00:45:04 GMT) (full text, mbox, link).

+ +

Message #2760 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Fri, 03 Jan 2014 16:40:54 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> Sure.  I borrowed your text and edited it slightly for clarity.  I also
+> changed "upstart/systemd" to "upstart", for two reasons: one is that at
+> this stage I'd prefer to try to maintain only one version of this text.
+
+Yeah, that's fine.  We can hammer out the details of one path, and then
+figure out whether it makes sense to have the systemd path be a completely
+separate writeup or whether it should be presented in the form of an
+amendment.
+
+> And the other is that IMO the proposed prescription for non-Linux ports
+> doesn't make sense for systemd.  There is little prospect of systemd
+> being "ported" to those systems.
+
+I'd prefer to leave it in.  Upstream's opinions aside, systemd is free
+software and if someone wants to try to port it (or, possibly more likely,
+"port" it by writing something native that provides the same interfaces),
+they can.  Maybe upstream is right and it's untenable; maybe they're wrong
+and it's not as hard as they think.  I realize it's horribly unlikely for
+jessie, but still, as a matter of principle, I'd rather encourage the same
+software or at least the same interfaces across all of our ports.
+
+But, anyway, we can focus on the upstart position first and deal with that
+later.
+
+> I've written a version of Niklaus's rule about dependencies:
+
+>    Likewise, packages must not Depend on or Recommend (directly or
+>    indirectly) a specific init(1).  Violations of this are also an RC
+>    bug in jessie.
+
+> And:
+
+>    Theses rules do not apply to machinery which itself forms part of
+>    the implementation of one or more init systems.
+
+> That seems to be the clearest way to put the matter.
+
+This seems fine to me, at least for right now.  I'm doing a bit of
+additional research right now to be sure that I understand the
+implications of this and may end up asking for any problems that anyone is
+aware of with this approach, just to be sure we're not missing something.
+
+>> I think Policy 4.13 already covers this adequately and we don't need to
+>> say anything further in the decision.
+
+> I would like to be clear that maintainers don't need to take patches
+> that introduce embedded copies of sd_notify.
+
+Oh, okay.  I had missed that aspect of things.  I think it's fine to be
+clear about that as long as we're not prohibiting via non-advice TC
+decision using an embedded copy (which feels like bug severity inflation
+to me).
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 02:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 02:33:04 GMT) (full text, mbox, link).

+ +

Message #2765 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 04:31:33 +0200
+
+
On Fri, 2014-01-03 at 16:40 -0800, Russ Allbery wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > I've written a version of Niklaus's rule about dependencies:
+> 
+> >    Likewise, packages must not Depend on or Recommend (directly or
+> >    indirectly) a specific init(1).  Violations of this are also an RC
+> >    bug in jessie.
+> 
+> > And:
+> 
+> >    Theses rules do not apply to machinery which itself forms part of
+> >    the implementation of one or more init systems.
+> 
+> > That seems to be the clearest way to put the matter.
+> 
+> This seems fine to me, at least for right now.  I'm doing a bit of
+> additional research right now to be sure that I understand the
+> implications of this and may end up asking for any problems that anyone is
+> aware of with this approach, just to be sure we're not missing something.
+
+Packages could functionally depend on systemd - one example would be
+systemd-ui (though it seems to be mostly abandoned, and comes from the
+same source; it's not really "part of the machinery forming the
+implementation" though). OTOH this doesn't have to be a package-level
+dependency; probably programs from such packages could just fail with an
+error if you try to run them after booting with sysvinit, and this would
+probably be the best option as switching init as a "side effect" of
+installing such a package would be questionable.
+
+One case to consider is what should happen with GNOME if it requires
+interfaces that nobody has implemented for sysvinit. Is it OK to show a
+screen saying "you need to boot with systemd to use GNOME" and expect
+GNOME users to manually install systemd? Or should there be more
+user-friendly automation for installing it? Or would you expect to find
+someone to create GNOME packages without such dependencies?
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 02:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 02:45:04 GMT) (full text, mbox, link).

+ +

Message #2770 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Fri, 03 Jan 2014 18:41:02 -0800
+
+
Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
+
+> One case to consider is what should happen with GNOME if it requires
+> interfaces that nobody has implemented for sysvinit.
+
+The likelihood of this and possible impact is one of the things that I'm
+checking on.  I'd rather not have the argument if it turns out not to be
+something we have to worry about for the jessie release.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 03:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Clint Adams <clint@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 03:09:04 GMT) (full text, mbox, link).

+ +

Message #2775 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Clint Adams <clint@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 03:06:51 +0000
+
+
On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
+> As said elsewhere, I think there should be a paragraph about packages
+> that depend on a specific init system for reasons other than service
+> startup, e.g.
+> 
+> 4. The above criterium also extends to dependencies that are not related
+>    to service startup. In jessie, no package may depend on a single
+>    initsystem other than sysvinit. After jessie, no package may depend
+>    on a single init system other than the default init.
+> 
+> or alternatively   
+> 
+> 4. Packages may, however, depend on a specific init system (which may
+>    not be the default init) for features that are not related to daemon
+>    startup. Such packages will only be installable on systems running a
+>    non-default init, but are permitted in the archive.
+
+As loath as I am to participate in this discussion, I have to ask
+if your intent is to suddenly outlaw all the packages which depend
+on runit.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 03:21:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 03:21:10 GMT) (full text, mbox, link).

+ +

Message #2780 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Clint Adams <clint@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Fri, 03 Jan 2014 19:17:27 -0800
+
+
Clint Adams <clint@debian.org> writes:
+
+> As loath as I am to participate in this discussion, I have to ask if
+> your intent is to suddenly outlaw all the packages which depend on
+> runit.
+
+I don't think runit (or daemontools) are init systems.  If you feel like
+that may be ambiguous, we should say that explicitly.  (This is one of the
+problems with how to word matters around OpenRC, since in a way it's
+actually closer to daemontools or runit.  The latter just never attempted
+to deal with *all* the startup scripts.)
+
+Regardless, yes, we definitely should not outlaw packages that depend on
+runit as part of this decision.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 03:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 03:36:04 GMT) (full text, mbox, link).

+ +

Message #2785 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: Clint Adams <clint@debian.org>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Fri, 3 Jan 2014 19:34:09 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Jan 3, 2014 at 7:17 PM, Russ Allbery <rra@debian.org> wrote:
+
+> Clint Adams <clint@debian.org> writes:
+>
+> > As loath as I am to participate in this discussion, I have to ask if
+> > your intent is to suddenly outlaw all the packages which depend on
+> > runit.
+>
+> I don't think runit (or daemontools) are init systems.  If you feel like
+> that may be ambiguous, we should say that explicitly.  (This is one of the
+> problems with how to word matters around OpenRC, since in a way it's
+> actually closer to daemontools or runit.  The latter just never attempted
+> to deal with *all* the startup scripts.)
+>
+
+Upstart running as a session init is not really an init system either,
+then, under that definition. Perhaps we should ban packages that depend on
+a certain init system being PID 1. Upstart, runit, daemontools, Circus, God
+etc. can run as session inits on top of any other init system, and
+therefore will have a small, confined effect when doing so and should be
+allowed.
+
+Regards,
+Cameron
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 04:15:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 04:15:09 GMT) (full text, mbox, link).

+ +

Message #2790 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Fri, 03 Jan 2014 20:10:19 -0800
+
+
Josh Triplett <josh@joshtriplett.org> writes:
+
+> I think it'd be appropriate to allow dependencies on runit (or another
+> package that contains an implementation of /sbin/init), as long as
+> either the depending package doesn't depend on having /sbin/init be that
+> init (which holds true for runit), *or* if an alternative package exists
+> to integrate with the default init system.  For instance, git-daemon-run
+> versus git-daemon-sysvinit versus a hypothetical git-daemon-systemd, or
+> a future gnome-session-systemd or gnome-session-upstart package (for
+> whichever init system isn't the default).  (Note that the latter would
+> work better if upstart stopped conflicting with sysvinit, similar to how
+> systemd can be installed without being init.)
+
+Yes, this sounds right to me too.  It's not the package dependency that we
+care about, it's whether it forces a particular init system to be PID 1.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 04:27:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 04:27:09 GMT) (full text, mbox, link).

+ +

Message #2795 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Clint Adams <clint@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Fri, 03 Jan 2014 20:26:04 -0800
+
+
Clint Adams <clint@debian.org> writes:
+> On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
+>> As said elsewhere, I think there should be a paragraph about packages
+>> that depend on a specific init system for reasons other than service
+>> startup, e.g.
+>> 
+>> 4. The above criterium also extends to dependencies that are not related
+>>    to service startup. In jessie, no package may depend on a single
+>>    initsystem other than sysvinit. After jessie, no package may depend
+>>    on a single init system other than the default init.
+>> 
+>> or alternatively   
+>> 
+>> 4. Packages may, however, depend on a specific init system (which may
+>>    not be the default init) for features that are not related to daemon
+>>    startup. Such packages will only be installable on systems running a
+>>    non-default init, but are permitted in the archive.
+>
+> As loath as I am to participate in this discussion, I have to ask
+> if your intent is to suddenly outlaw all the packages which depend
+> on runit.
+
+Are you asking me personally? No, that's not my intent. I merely think
+that a CTTE solution should spell out precisely to what extent a package
+must be compatible with the default init (i.e., if it must be fully
+working with the default init, or if it only has to provide daemon
+startup/supervision/shutdown for the default init). This is why I
+explicitly listed two conflicting, alternative wordings.
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 04:36:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 04:36:05 GMT) (full text, mbox, link).

+ +

Message #2800 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Fri, 03 Jan 2014 20:32:22 -0800
+
+
Russ Allbery <rra@debian.org> writes:
+>> I've written a version of Niklaus's rule about dependencies:
+
+Just for the record, my suggestion was to include language that
+regulates dependencies on the init system, but I do not have any
+preferences whether they should be allowed or forbidden.
+
+>>    Likewise, packages must not Depend on or Recommend (directly or
+>>    indirectly) a specific init(1).  Violations of this are also an RC
+>>    bug in jessie.
+>
+>> And:
+>
+>>    Theses rules do not apply to machinery which itself forms part of
+>>    the implementation of one or more init systems.
+>
+>> That seems to be the clearest way to put the matter.
+>
+> This seems fine to me, at least for right now.  I'm doing a bit of
+> additional research right now to be sure that I understand the
+> implications of this and may end up asking for any problems that anyone is
+> aware of with this approach, just to be sure we're not missing
+> something.
+
+Well, we may end up in a somewhat paradoxical situation where Debian
+comes with packages for alternate init systems, but at the same time
+cannot package any utilities specifically designed for them -- unless
+they are included in the alternate init package itself.
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 05:03:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 05:03:05 GMT) (full text, mbox, link).

+ +

Message #2805 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 06:58:56 +0200
+
+
On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote:
+> Clint Adams <clint@debian.org> writes:
+> > On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
+> >> or alternatively   
+> >> 
+> >> 4. Packages may, however, depend on a specific init system (which may
+> >>    not be the default init) for features that are not related to daemon
+> >>    startup. Such packages will only be installable on systems running a
+> >>    non-default init, but are permitted in the archive.
+> >
+> > As loath as I am to participate in this discussion, I have to ask
+> > if your intent is to suddenly outlaw all the packages which depend
+> > on runit.
+> 
+> Are you asking me personally? No, that's not my intent. I merely think
+> that a CTTE solution should spell out precisely to what extent a package
+> must be compatible with the default init (i.e., if it must be fully
+> working with the default init, or if it only has to provide daemon
+> startup/supervision/shutdown for the default init). This is why I
+> explicitly listed two conflicting, alternative wordings.
+
+There are two different kinds of dependencies: dependencies expressed in
+package metadata, and functional dependencies (as in whether the package
+does anything useful with another init). Your earlier wording sounds
+like it was talking about the former ("installable") and Ian's proposal
+definitely was (explicitly mentioning package fields), but the "fully
+working" you use now sounds like it's about the latter.
+
+As the systemd-ui example shows, there could be packages which in no way
+can be reasonably expected to work with another init. So I think a
+blanket ban on functional dependencies would be wrong (which you also
+seem to be saying). I don't see such obvious problems with banning
+package-level dependencies (requiring the packages to just fail at
+runtime instead), and such dependencies could cause problems such a
+unexpectedly switching init as a side effect of installing/upgrading an
+"unrelated" package or forcing uninstall of packages if you even
+temporarily try booting with another init.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 06:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 06:24:04 GMT) (full text, mbox, link).

+ +

Message #2810 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Sat, 4 Jan 2014 14:09:57 +0800
+
+
On 31 December 2013 12:32, Steve Langasek <vorlon@debian.org> wrote:
+> I agree that maintaining a systemd unit plus an upstart job is better than
+> maintaining an init script.  I just can't see any way through to a world
+> where these will both actually be maintained (the testing problem),
+> particularly if upstart use is relegated to the non-Linux ports.
+
+I wonder if folks could clarify what status they expect secondary init
+systems to have in Debian?
+
+To me, the above seems similar to saying "I just can't see any way
+through to a world where both exim and postfix, or apache and nginx
+will both actually be well supported in Debian" -- choosing an MTA or
+web server is something we leave up to the sysadmin, even if we choose
+defaults at install time, and packages that use their services are
+generally expected to work well with whatever the sysadmin chooses.
+That's obviously not the case for every package, some provide modules
+for apache but not nginx say (libapache2-mod-*), and others are
+specifically for postfix and won't work with exim (pmailq, postfwd,
+postgrey eg), but packages that just want to call sendmail or provide
+a cgi script are expected not to care. Similarly, choosing Gnome as
+the default desktop for Debian doesn't mean you can't reasonably use
+KDE or XFCE on your Debian system. For postifx/exim and apache/nginx I
+don't think you have to have any elements of the other system
+installed to run your preferred system; I'm not sure that's so true
+for KDE or XFCE though -- certainly I use packages that pull in libgtk
+(groff, gnuplot, emacs, evince) and libgnome (inkscape?) on my XFCE
+system, for instance.
+
+Maybe this should be different for systemd/upstart -- maybe they're
+more like dpkg/rpm or apt/yum -- you can certainly install all four on
+your Debian system, but two of them aren't so useful for actually
+managing it.
+
+That /seems/ like an undesirable situation though -- certainly it
+seems like there are a bunch of people who'd like to run systemd on
+Debian, a bunch who'd like to run upstart on Debian (Canonical if no
+one else), and at least a few that might like to run something else
+(OpenRC users, kfreebsd/Hurd folks). Are the obstacles to supporting
+that really infeasible/insurmountable? Wouldn't it be reasonable to do
+something like piuparts in EC2 to test packages under different
+/sbin/init providers to see if they behave roughly as expected?
+
+(Is it really harder to have upstart and systemd support in Debian
+than it is to support running Debian on either a Linux, FreeBSD or
+Hurd kernel? All those things are already possible anyway, aren't
+they?)
+
+> It's hard
+> for me to view "Ubuntu, Debian GNU, and Debian GNU/kFreeBSD use upstart; Red
+> Hat, Fedora, SuSE, and Debian GNU/Linux use systemd" as anything but a loss
+> for upstart.  With only non-Linux ports of Debian on upstart's side and all
+> the other potential collaborators among the traditional distros opting for
+> systemd, I think that would leave Canonical confronting some hard questions
+> about whether to continue investing in upstart development.
+
+(So, uh, that would mean that a Canonical-employed maintainer of
+upstart would have a fairly challenging conflict of interest in this
+decision, right?)
+
+> My answer to this is that, as things stand today, this argument does *not*
+> apply, because Debian hasn't made a choice for either systemd or upstart
+> yet.  Whichever option Debian chooses, that is the option that is going to
+> carry the day, because Debian does integration better, and across a wider
+> range of software, than any other distro out there.
+
+So that's not true of apache/nginx, exim/postfix, or Gnome/KDE. I've
+seen some argue recently that it's true for dpkg/rpm, but only
+post-Ubuntu -- prior to that I think I only saw that claim in reverse.
+It doesn't really strike me as a great argument as a consequence.
+
+> So I don't think I would vote "systemd on linux, upstart on non-linux" above
+> "systemd, non-linux ports to figure out how to be compatible", because I
+> fear that would be leading the non-Linux ports on.
+
+I would vote "Gnome on Linux, XFCE/fvwm on non-Linux" over "Gnome on
+Linux, non-Linux ports have no desktop until they figure something
+out" quite happily. That only works because XFCE/fvwm are entirely
+plausible options on Debian with a Linux kernel, though, and only
+works well because there are standards for packages to tell desktops
+how to add them to their menus.
+
+> (As a personal aside, whichever of upstart and systemd is chosen by the TC
+> as the default, I intend to wholeheartedly adopt it for my own use in
+> Debian.  I love the upstart codebase, for all the same reasons that you
+> found when you looked at it, but I'm not on a quixotic quest here.  If
+> Debian chooses systemd, then any time I spend on debugging init system bugs
+> in Debian is best spent debugging them on systemd, where it will bring the
+> most benefit to our users.)
+
+For comparison:
+
+1771  task-gnome-desktop             35102     0     0     0 35102
+(Debian Install System Team)
+2460  xfce4                          16800     0     0     0 16800
+(Debian Xfce Maintainers)
+
+Personally, I run xfce because it works best for me; I wouldn't give
+even a moments thought to running Gnome because by doing so I might
+find and fix some bugs that would help other folks. I'd apply the same
+argument to systemd/upstart, personally. To me, that seems like the
+best way to let the most beneficial technology win out.
+
+It seems to me like "what should the default init system be?" is a
+very different question depending on whether other init systems are
+also well supported. I get the impression that you think there's not
+much chance of other init systems working well, while what I've read
+from Russ and Ian seems to indicate that it ought to at least be
+feasible. I can certainly understand that multiple init systems isn't
+a winning idea from the point of view Ubuntu (or Red Hat) would take
+when putting together a distribution, but I would have thought it was
+something Debian could/should/would manage.
+
+Forced to make a choice, should Debian go for smoother/tighter
+integration between apps, or more choice for users/sysadmins? I'd
+expect Debian to choose the latter; though Ubuntu, Red Hat and
+possibly Fedora might choose the former.
+
+Cheers,
+a "por que no los dos?" j
+
+-- 
+Anthony Towns <aj@erisian.com.au>
+Not speaking for my employer...
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 06:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 06:54:04 GMT) (full text, mbox, link).

+ +

Message #2815 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Anthony Towns <aj@erisian.com.au>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Fri, 03 Jan 2014 22:50:18 -0800
+
+
Anthony Towns <aj@erisian.com.au> writes:
+
+> I wonder if folks could clarify what status they expect secondary init
+> systems to have in Debian?
+
+My personal answer to this is that I truly don't know.
+
+On one hand, we have four different init systems in Debian right now, plus
+a fifth in experimental, and several of them have been in Debian for a
+number of years.  So clearly it's currently possible to have multiple,
+working init systems.  At least three of them (upstart, systemd, and
+sysvinit) work reliably well in Debian right now.  Some, although not very
+many, packages have been converted to support upstart, systemd, or both
+already.
+
+On the other hand, much of why those init systems work is that we have the
+lowest-common-denominator of init scripts in all packages.  I suspect,
+although am not sure, that a noticable amount of the long-tail software in
+Debian will only work with the default init system.  In any case where the
+packager primarily cares about getting the software into Debian, not about
+broader Debian project goals for the sake of doing things for Debian, I'm
+not sure there's going to be much incentive to add support for the other
+init systems, and I'm not sure there's going to be the resources to submit
+them as patches.
+
+Left to itself, I think the best case that we'll get for support for
+alternative init systems will be at the level of our manpage coverage: we
+never achieve it, but we don't do a horrible job.  It's not clear to me
+that would be a bad outcome.  I think with a concerted effort on the part
+of porters (most likely the non-Linux porters), we could do better than
+that for one alternative init system, but it would involve a lot of
+pestering people, which is generally not that fun and rather demotivating.
+
+I think we have a substantially higher chance of effectively supporting
+multiple init systems if none of them are sysvinit, because init scripts
+are awful from a package maintainer's perspective.
+
+But all of this is pure speculation.
+
+I really hate making people unhappy, and I really hate seeing people's
+work left behind, so I love the vision of a world in which we can actually
+support a multitude of init systems.  But I'm not sure how realistic it is
+to expect enough package maintainers to care.
+
+Personally, as much as time permits, I intend to support all init systems
+that anyone in Debian is interested in, at least to the extent of
+providing untested configurations for those init systems.  I don't know if
+I'll be able to follow through on that.  Certainly, for simple daemons, I
+can throw something together and be pretty sure it will work even though I
+didn't test it.  The real test will be supporting something like
+openafs-client on an init system that I don't use.  I would like to do
+that, but I'm not sure that I will find the time in practice.  But
+certainly if someone else provides the patches, I'll apply them.
+
+There are also some packages that have very complex initialization
+requirements or that tie heavily into the early boot.  Those are going to
+be a harder challenge than the average daemon, since they're likely to
+have specialized startup code that will have to be rewritten in multiple
+ways for different init systems.  For example, if we choose systemd, I
+expect and hope that many of our hardest and most complex cases will
+migrate to socket activation, which should make them far more robust and
+much simpler to maintain.  Once one has converted a complex and racy
+startup to race-free and simple socket activation, I know it's going to be
+hard to find the mental effort required to maintain the sysvinit scripts
+or fix corner-case ordering bugs that socket activation just make
+disappear.
+
+> Forced to make a choice, should Debian go for smoother/tighter
+> integration between apps, or more choice for users/sysadmins? I'd expect
+> Debian to choose the latter; though Ubuntu, Red Hat and possibly Fedora
+> might choose the former.
+
+Well, here again, all of the above is the most attractive answer to me.
+But my background, experience, and day-to-day work with Debian leads me to
+choose an option that isn't on that list: more power, simpler
+configuration, simpler management, and more directly useful features for
+sysadmins.  A world in which all services provided by Debian are started
+with socket activation via configuration with a simple local override
+mechanism is hugely attractive from an enterprise systems administration
+perspective.
+
+Socket activation is, I think, the biggest place where less capable init
+systems are in danger of getting left behind.  Once you have that feature
+available, it solves so many problems that it's annoying to have to work
+without it.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 09:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 09:00:05 GMT) (full text, mbox, link).

+ +

Message #2820 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 00:56:17 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Russ Allbery <rra@debian.org> writes:
+
+> My inclination would be to give maintainers technical advice to accept
+> integrations with either existing synchronization protocols, but leave it
+> as technical advice rather than the binding part of the decision.
+
+I strongly agree.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 10:03:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thomas Goirand <zigo@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 10:03:11 GMT) (full text, mbox, link).

+ +

Message #2825 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thomas Goirand <zigo@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: additional OpenRC information: OpenRC now in Debian + Experimental!
+
Date: Sat, 04 Jan 2014 17:59:34 +0800
+
+
On 01/04/2014 01:42 AM, Ian Jackson wrote:
+> Thomas Goirand writes ("Bug#727708: additional OpenRC information: OpenRC now in Debian Experimental!"):
+>> OpenRC is now in Debian experimental! \o/
+> 
+> Good, thanks.
+> 
+>> I of course welcome anyone to try OpenRC and report bugs.
+> 
+> Can you point me to the relevant reference documentation ?
+> 
+> Thanks,
+> Ian.
+
+Hi Ian,
+
+I'm not sure what kind of doc you are looking for. If you want to know
+how to install it, well, it's just an "apt-get install openrc" plus a
+tricky first reboot. Otherwise, read further.
+
+You can first have a look over here:
+https://wiki.debian.org/OpenRC
+
+Though I just have made some edits to make it up-to-date, that page is
+still a work in progress, and would need much improvements, like how to
+write runscripts and so on.
+
+There's also this from Gentoo upstream:
+http://wiki.gentoo.org/wiki/OpenRC
+
+As much as I know, most of the available documentation is available from
+the set of man pages from the OpenRC project. Here's a list of available
+manpages:
+einfo.3 openrc.8 rc_config.3 rc_find_pids.3 rc_runlevel.3  rc-service.8
+rc_stringlist.3 service.8 openrc-run.8 rc_deptree.3 rc_plugin_hook.3
+rc_service.3 rc-status.8 rc-update.8 start-stop-daemon.8
+
+They are not all installed by the Debian package yet, so you may want to
+have a look in the man folder of the source package.
+
+You can to start reading the man page for openrc-run, which describe how
+to write OpenRC "runscripts". A runscript is what can replace init
+scripts, eg you would replace #!/bin/sh  by #!/sbin/openrc-run. FYI,
+openrc-run is the new name of /sbin/runscript. It was renamed because of
+the clash with the command line from minicom. I guess we'll keep the
+therm "runscript" for a while still, even if it's really referring to
+"openrc-run" now.
+
+But probably, the most easy way to learn how to make runscripts is to
+read what's been done in Gentoo. Inside the openrc source package, under
+the init.d script, there's a bunch of runscripts which you can read as
+examples. When reading them, keep in mind that these are rather complex,
+and most of the daemons in Debian will not need that complexity.
+
+If you need to know more, let me know.
+
+Cheers,
+
+Thomas Goirand (zigo)
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 12:39:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sjoerd Simons <sjoerd@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 12:39:10 GMT) (full text, mbox, link).

+ +

Message #2830 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sjoerd Simons <sjoerd@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 13:36:02 +0100
+
+
On Fri, 2014-01-03 at 18:41 -0800, Russ Allbery wrote:
+> Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
+> 
+> > One case to consider is what should happen with GNOME if it requires
+> > interfaces that nobody has implemented for sysvinit.
+> 
+> The likelihood of this and possible impact is one of the things that I'm
+> checking on.  I'd rather not have the argument if it turns out not to be
+> something we have to worry about for the jessie release.
+
+Essentially this boils down to whether the logind interfaces will be
+available when using sysvinit. Most of the other interfaces (at least
+for current gnome as in experimental) would cause some functionality to
+either be missing or not work, but wouldn't yield a completely unusable
+system.
+
+Not having the logind interface is a lot harder to cope with and
+something that will not only impact Gnome. So essentially the most
+likely impact of using sysvinit _without_ a provider of the logind
+interface would be a non-usable Gnome desktop (and potentially even GDM
+to be unusable) on Jessie systems.
+
+
+-- 
+Sjoerd Simons <sjoerd@debian.org>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 12:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 12:45:04 GMT) (full text, mbox, link).

+ +

Message #2835 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Bdale Garbee <bdale@gag.com>, + 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 12:43:43 +0000
+
+
Bdale Garbee writes ("Bug#727708: init system discussion status"):
+> Russ Allbery <rra@debian.org> writes:
+> > My inclination would be to give maintainers technical advice to accept
+> > integrations with either existing synchronization protocols, but leave it
+> > as technical advice rather than the binding part of the decision.
+> 
+> I strongly agree.
+
+OK, I would be quite happy to say that we would like each daemon
+package to implement at least one non-forking startup protocol, but
+that we won't force this on maintainers.
+
+Would that suit you both ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 12:48:16 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 12:48:16 GMT) (full text, mbox, link).

+ +

Message #2840 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Uoti Urpala <uoti.urpala@pp1.inet.fi>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 12:47:57 +0000
+
+
Uoti Urpala writes ("Bug#727708: init system discussion status"):
+> There are two different kinds of dependencies: dependencies expressed in
+> package metadata, and functional dependencies (as in whether the package
+> does anything useful with another init). Your earlier wording sounds
+> like it was talking about the former ("installable") and Ian's proposal
+> definitely was (explicitly mentioning package fields), but the "fully
+> working" you use now sounds like it's about the latter.
+
+Thanks for pointing this out.  My proposal is too weak in this
+respect.  I intended to make the stronger statement.
+
+> As the systemd-ui example shows, [...]
+
+I think systemd-ui is part of the systemd init system so falls into
+the exception.  Of course that means that nothing else should depend
+(functionally or in package dependencies) on it.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 15:51:16 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 15:51:16 GMT) (full text, mbox, link).

+ +

Message #2845 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 16:46:28 +0100
+
+
Le samedi 04 janvier 2014 à 12:47 +0000, Ian Jackson a écrit :
+> Uoti Urpala writes ("Bug#727708: init system discussion status"):
+> > Your earlier wording sounds
+> > like it was talking about the former ("installable") and Ian's proposal
+> > definitely was (explicitly mentioning package fields), but the "fully
+> > working" you use now sounds like it's about the latter.
+> 
+> Thanks for pointing this out.  My proposal is too weak in this
+> respect.  I intended to make the stronger statement.
+
+> I think systemd-ui is part of the systemd init system so falls into
+> the exception.  Of course that means that nothing else should depend
+> (functionally or in package dependencies) on it.
+
+There is no way that, for example, some of the GNOME control center
+applets will work at all without systemd.
+
+It is already hard enough to imagine that we would have to ship packages
+without the appropriate dependencies on systemd; expecting them to have
+the same functional coverage without it is simply insane.
+
+-- 
+.''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 17:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 17:09:04 GMT) (full text, mbox, link).

+ +

Message #2850 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 09:07:30 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Bdale Garbee writes ("Bug#727708: init system discussion status"):
+>> Russ Allbery <rra@debian.org> writes:
+
+>>> My inclination would be to give maintainers technical advice to accept
+>>> integrations with either existing synchronization protocols, but leave
+>>> it as technical advice rather than the binding part of the decision.
+
+>> I strongly agree.
+
+> OK, I would be quite happy to say that we would like each daemon package
+> to implement at least one non-forking startup protocol, but that we
+> won't force this on maintainers.
+
+> Would that suit you both ?
+
+I may have lost the thread here, but that doesn't sound quite right.
+Wouldn't we want to say that each daemon package should implement the
+native non-forking startup protocol for the default init system, and we
+would like the maintainer to merge patches for other startup protocols if
+active maintainers of other init systems ask for this?
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 17:24:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 17:24:05 GMT) (full text, mbox, link).

+ +

Message #2855 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: aj@erisian.com.au
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Sat, 04 Jan 2014 17:21:52 +0000
+
+
[Message part 1 (text/plain, inline)]
+
Commenting as a porter, the decision on default init system might affect
+me something like this:
+
+If GNU/Linux defaults to Upstart, it's likely in porters' interest to
+get that working as well as possible so we can keep consistency with
+Linux arches.  I'm really grateful of Dimitri's work on this already.
+
+But if GNU/Linux defaults to systemd, I'd say that's far too big, too
+specialised around Linux, and likely to be a moving target to either
+port it or maintain something compatible.
+
+In that case, we may have to do the best we can with one of the other
+init systems.  I'd wonder if it's still worth porting Upstart if few
+systems would be using it, or packages having Upstart jobs.  I have good
+feelings about OpenRC (which Gentoo already uses as an alternative
+alongside systemd), or keeping plain sysvinit might even be still viable
+for jessie only.
+
+On Sat, 4 Jan 2014 14:09:57 +0800 Anthony Towns wrote:
+> I wonder if folks could clarify what status they expect secondary init
+> systems to have in Debian?
+
+This aspect is most crucial to the ports.  At the very least, we'd need
+to be able to get patches applied to fix startup issues on our init
+system, even if the maintainer doesn't test or want to support this.  In
+the worst case, we might have to give up on getting something like GNOME
+working usefully without systemd, and thus not be able to ship it on
+non-Linux ports.
+
+Policy may need to explain whether hard systemd requirement is
+permissible, if it should be expressed in package dependencies, or what
+it should do otherwise (e.g. refuse to start, fail with error message,
+fall back to something with reduced functionality).
+
+If policy requires keeping functional sysvinit scripts around for
+jessie, and/or (more controversially) can discourage the use of specific
+non-portable functionality - which I think would be things like "expect
+fork" or socket activation - I'm not necessarily saying this is a good
+idea, but it would obviously work in our favour.
+
+If non-Linux ports end up running and testing daemons on an alternate
+init system *anyway*, I'd love for that work to benefit GNU/Linux users
+who dislike the chosen default init system and want to use what we're
+using instead.  And vice-versa, anyone running such a system and
+finding/fixing startup issues, would likely be helping the ports.
+
+[please keep me in Cc if responding directly to anything I said here]
+
+Thanks,
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 17:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cory <opensourcesoftwaredeveloper@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 17:36:04 GMT) (full text, mbox, link).

+ +

Message #2860 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cory <opensourcesoftwaredeveloper@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Sat, 04 Jan 2014 11:33:02 -0600
+
+
On 01/04/2014 11:21 AM, Steven Chamberlain wrote:
+> Commenting as a porter, the decision on default init system might affect
+> me something like this:
+>
+> If GNU/Linux defaults to Upstart, it's likely in porters' interest to
+> get that working as well as possible so we can keep consistency with
+> Linux arches.  I'm really grateful of Dimitri's work on this already.
+>
+> But if GNU/Linux defaults to systemd, I'd say that's far too big, too
+> specialised around Linux, and likely to be a moving target to either
+> port it or maintain something compatible.
+>
+> In that case, we may have to do the best we can with one of the other
+> init systems.  I'd wonder if it's still worth porting Upstart if few
+> systems would be using it, or packages having Upstart jobs.  I have good
+> feelings about OpenRC (which Gentoo already uses as an alternative
+> alongside systemd), or keeping plain sysvinit might even be still viable
+> for jessie only.
+>
+> On Sat, 4 Jan 2014 14:09:57 +0800 Anthony Towns wrote:
+>> I wonder if folks could clarify what status they expect secondary init
+>> systems to have in Debian?
+> This aspect is most crucial to the ports.  At the very least, we'd need
+> to be able to get patches applied to fix startup issues on our init
+> system, even if the maintainer doesn't test or want to support this.  In
+> the worst case, we might have to give up on getting something like GNOME
+> working usefully without systemd, and thus not be able to ship it on
+> non-Linux ports.
+>
+> Policy may need to explain whether hard systemd requirement is
+> permissible, if it should be expressed in package dependencies, or what
+> it should do otherwise (e.g. refuse to start, fail with error message,
+> fall back to something with reduced functionality).
+>
+> If policy requires keeping functional sysvinit scripts around for
+> jessie, and/or (more controversially) can discourage the use of specific
+> non-portable functionality - which I think would be things like "expect
+> fork" or socket activation - I'm not necessarily saying this is a good
+> idea, but it would obviously work in our favour.
+>
+> If non-Linux ports end up running and testing daemons on an alternate
+> init system *anyway*, I'd love for that work to benefit GNU/Linux users
+> who dislike the chosen default init system and want to use what we're
+> using instead.  And vice-versa, anyone running such a system and
+> finding/fixing startup issues, would likely be helping the ports.
+>
+> [please keep me in Cc if responding directly to anything I said here]
+>
+> Thanks,
+> Regards,
+If Debian go's with systemd they need to use systemd 207 as its 
+supported in RHEL 7 so we know it's going to be supported for around 10 
+years also why does Debian have systemd 204 in it's repos?? systemd 207 
+is way better
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 17:42:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 17:42:05 GMT) (full text, mbox, link).

+ +

Message #2865 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Anthony Towns <aj@erisian.com.au>, + 727708@bugs.debian.org
+
Cc: Steve Langasek <vorlon@debian.org>, + Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Sat, 4 Jan 2014 17:39:20 +0000
+
+
Anthony Towns writes ("Bug#727708: init system other points, and conclusion"):
+> I wonder if folks could clarify what status they expect secondary init
+> systems to have in Debian?
+
+Thanks for bringing up this point so very clearly.
+
+I agree entirely with the thrust of your argument.  I would very much
+like to support multiple init systems.  Because you can only have one
+init system at once (unlike databases, but like MTAs and webservers),
+I think it's reasonable that our goal should be that pretty much every
+program should at least basically work with every init system, and
+that most programs will work well with all of them.
+
+For non-forking startup protocols, I think we should (for jessie+1
+perhaps) define a supported set of protocols.  Every daemon package
+should implement one of the supported set, and every init system
+(including sysvinit if anyone cares to continue to maintain it) should
+implement all of them (whether via some kind of compatibility shim or
+otherwise).
+
+For the per-init-system job/unit/whatever files, if we can't come up
+with some kind of meta format or compatibility converter(s), I would
+actually prefer to require every daemon maintainer to supply two or
+perhaps three such task specification files.
+
+For admin tools and the like (eg systemd-ui or the gnome control
+panel) I think it's OK for some of the functionality not to be fully
+available with every init system.  This is particularly true if the
+functionality is for manipulating features that aren't available in
+the unsupported systems.
+
+If it's just a case that the admin tool doesn't know how to talk to
+the relevant feature, or the admin tool's model makes assumptions
+about the underlying init system, then Debian should welcome
+contributions of the missing pieces, in whatever is the appropriate
+form for those pieces.  That might be (for example) simply glue code,
+or it might be replacement UI elements which appear when the other
+init system is in use.  Those pieces might be in the same or separate
+packages, however is most technically and socially convenient.
+
+> Forced to make a choice, should Debian go for smoother/tighter
+> integration between apps, or more choice for users/sysadmins? I'd
+> expect Debian to choose the latter; though Ubuntu, Red Hat and
+> possibly Fedora might choose the former.
+
+For the wellbeing of the whole free software community, and
+particularly for our downstreams, we should be aiming for flexibility.
+
+Ia.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 17:42:18 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 17:42:18 GMT) (full text, mbox, link).

+ +

Message #2870 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 17:41:19 +0000
+
+
Russ Allbery writes ("Bug#727708: init system discussion status"):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > Would that suit you both ?
+> 
+> I may have lost the thread here, but that doesn't sound quite right.
+> Wouldn't we want to say that each daemon package should implement the
+> native non-forking startup protocol for the default init system, and we
+> would like the maintainer to merge patches for other startup protocols if
+> active maintainers of other init systems ask for this?
+
+It seems daft to go around making two (or perhaps three or more)
+patches to every daemon when one patch to each daemon, and a couple of
+compatibility modes in the init systems, would suffice.
+
+There is no technical reason why systemd can't support raise(SIGSTOP)
+and no technical reason why upstart can't support sd_notify.  I hereby
+volunteer to implement support for sd_notify in upstart if it's
+chosen.  It looks like it should take about an afternoon.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 17:51:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 17:51:10 GMT) (full text, mbox, link).

+ +

Message #2875 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steven Chamberlain <steven@pyro.eu.org>, + 727708@bugs.debian.org
+
Cc: aj@erisian.com.au
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Sat, 4 Jan 2014 17:46:41 +0000
+
+
Steven Chamberlain writes ("Bug#727708: init system other points, and conclusion"):
+> Policy may need to explain whether hard systemd requirement is
+> permissible, if it should be expressed in package dependencies, or what
+> it should do otherwise (e.g. refuse to start, fail with error message,
+> fall back to something with reduced functionality).
+
+Right.  In general I would prefer to see as good a support as is
+feasible, in the particular case.
+
+> If policy requires keeping functional sysvinit scripts around for
+> jessie,
+
+I think the TC is very likely to require this.  We haven't
+specifically heard from everyone on this point but both Russ and I
+(who disagree on several other important points) agree on it and none
+of the other TC members have disagreed.
+
+> and/or (more controversially) can discourage the use of specific
+> non-portable functionality - which I think would be things like "expect
+> fork" or socket activation - I'm not necessarily saying this is a good
+> idea, but it would obviously work in our favour.
+
+You are right that "expect fork" is nonportable in that sense.
+
+I don't think socket activation is non-portable.  It would be
+straightforward to write a wrapper program which set up the relevant
+sockets and passed them to the daemon via either the systemd or
+upstart socket activation protocols.  Such a wrapper could be used for
+any daemon which needed it.  I guess the work involved would be a day
+or two to produce something fully tested and documented.
+
+The same is true for dbus activation, if I'm not mistaken, but I
+haven't looked into this in any detail.
+
+> If non-Linux ports end up running and testing daemons on an alternate
+> init system *anyway*, I'd love for that work to benefit GNU/Linux users
+> who dislike the chosen default init system and want to use what we're
+> using instead.  And vice-versa, anyone running such a system and
+> finding/fixing startup issues, would likely be helping the ports.
+
+Yes, absolutely.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 18:00:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 18:00:11 GMT) (full text, mbox, link).

+ +

Message #2880 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Sjoerd Simons <sjoerd@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 09:56:44 -0800
+
+
Sjoerd Simons <sjoerd@debian.org> writes:
+
+> Essentially this boils down to whether the logind interfaces will be
+> available when using sysvinit. Most of the other interfaces (at least
+> for current gnome as in experimental) would cause some functionality to
+> either be missing or not work, but wouldn't yield a completely unusable
+> system.
+
+Thanks for that.  That's one of the key pieces of information that I was
+wondering about, and I was just told I should probably talk to you since
+you'd know.  :)
+
+> Not having the logind interface is a lot harder to cope with and
+> something that will not only impact Gnome. So essentially the most
+> likely impact of using sysvinit _without_ a provider of the logind
+> interface would be a non-usable Gnome desktop (and potentially even GDM
+> to be unusable) on Jessie systems.
+
+If we go with systemd, I think we have three options:
+
+1. Allow packages that require logind to depend on systemd and require
+   that it be used as the init system.  This is certainly the simplest for
+   packaging applications that want to depend on logind, as well as for
+   the systemd maintainers.  However, it means we lose the ability for
+   users of at least those packages to be able to fall back on sysvinit if
+   something goes wrong with systemd on their systems.  In the past, we've
+   tried pretty hard to provide that capability when making a disruptive
+   change of this kind.
+
+2. Package logind separately from systemd, get it working with sysvinit.
+   The problems with doing this, as I understand it, is that we'd not be
+   able to upgrade such a separately-packaged logind beyond 204 for
+   jessie.  I'm not sure how much impact that would have.  Also, it
+   sounded to me like we would need to figure out who was going to do that
+   work and maintain that package, including in the stable release.  If
+   the current systemd maintainers are not interested in doing this, we
+   absolutely shouldn't try to force them to do so.  Someone else would
+   need to step forward to do this and figure out the right package
+   relationships.  (Also, it would be good to maintain this separately so
+   that the systemd maintainers could move forward with newer versions of
+   systemd, including the logind built from its source.)
+
+3. Get GNOME working at some level without logind.  I think it would be
+   entirely acceptable for there to be some loss of functionality when
+   GNOME is started in this way, such as no user switching and some
+   configuration and control panels that rely on logind functionality not
+   working.  But it would need to at least start and be basically
+   functional for this to be a meaningful option.
+
+None of these options are very appealing, but I think we have to pick one
+of them.  I'm not seeing other options at the moment.
+
+I think option 3 would be the most appealing for the project as a whole,
+but I realize that's also the option that puts the most burden on GNOME
+maintainers.  The only upside I can offer for that is that this would be
+in the context of moving forward with systemd and would be a one-release
+issue.  Post jessie, you'd be able to move forward with a standard
+integration.
+
+It's worth noting that option 3 is also what would be required if we
+wanted to support GNOME on kFreeBSD.  I'm not sure if anyone is working on
+that port or sufficiently interested in it to try to make it work, but
+there may be some additional resources there.
+
+Do you think there's a way that we could make option 3 work that the GNOME
+maintainers would be comfortable with?
+
+The systemd maintainers should definitely feel free to tell me if I'm
+misunderstanding their feelings on option 2.
+
+Do you think I should ask more generally on debian-devel if there are any
+other maintainers in Debian that anticipate any problem with either
+requiring sysvinit be supported as PID 1 for jessie, or with logind being
+an optional component for jessie?
+
+If we go with upstart as the default, obviously the situation is much
+different, possibly including multiple different maintenance teams, and
+would require packaging a broken-up version of systemd and building a
+maintenance team around that.  It's basically option 2 with a bunch of
+added disruption.  There are enough variables involved in that situation
+that I hesitate to guess what it would look like.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 18:06:22 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 18:06:22 GMT) (full text, mbox, link).

+ +

Message #2885 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 10:05:36 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Russ Allbery writes ("Bug#727708: init system discussion status"):
+
+>> I may have lost the thread here, but that doesn't sound quite right.
+>> Wouldn't we want to say that each daemon package should implement the
+>> native non-forking startup protocol for the default init system, and we
+>> would like the maintainer to merge patches for other startup protocols
+>> if active maintainers of other init systems ask for this?
+
+> It seems daft to go around making two (or perhaps three or more) patches
+> to every daemon when one patch to each daemon, and a couple of
+> compatibility modes in the init systems, would suffice.
+
+Okay, it's possible that we just disagree here.  Having actually done it,
+I don't see any reason not to implement both the upstart and systemd
+readiness protocols in a typical daemon.  It's not at all hard, and in
+most cases one is going to want to implement socket activation on the
+systemd side anyway, which makes the readiness protocol mostly irrelevant.
+
+Whether systemd upstream should support the SIGSTOP protocol is certainly
+debatable, but I'm very reluctant to support an option that tries to force
+the systemd maintainers to support the protocol indefinitely as a
+Debian-specific fork.  This protocol is not widely used in Debian at the
+moment, nor is it widely used upstream, and I think it would be a far
+better use of our time to add support for the systemd protocol to upstart.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 18:09:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 18:09:08 GMT) (full text, mbox, link).

+ +

Message #2890 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Cory <opensourcesoftwaredeveloper@gmail.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Sat, 04 Jan 2014 10:07:52 -0800
+
+
Cory <opensourcesoftwaredeveloper@gmail.com> writes:
+
+> If Debian go's with systemd they need to use systemd 207 as its
+> supported in RHEL 7 so we know it's going to be supported for around 10
+> years also why does Debian have systemd 204 in it's repos?? systemd 207
+> is way better
+
+Because it's the last version before cgroup handling was changed, which
+has implications for supporting logind under different init systems than
+systemd.  So, in other words, moving systemd forward right now would force
+various incompatibilities in an excessively disruptive way before we've
+figured out how we want to handle them.
+
+Regardless of how we decide this, we'll be figuring out how systemd could
+move forward with newer versions, but it's wrapped up with the broader
+discussion.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 18:09:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 18:09:11 GMT) (full text, mbox, link).

+ +

Message #2895 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 18:08:02 +0000
+
+
Russ Allbery writes ("Bug#727708: init system discussion status"):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > Are the protocols offered by systemd and upstart each so plainly
+> > reasonable, that we are willing to overrule a maintainer who feels they
+> > protocol they are asked to support is too ugly or burdensome ?  Are such
+> > a maintainer's objections so unreasonable ?
+> 
+> Ah, okay, I see what you're getting at.
+> 
+> I think they are.  Furthermore, I don't think there's any likely prospect
+> that either will adopt a socket-based synchronization protocol other than
+> systemd's, so saying that these aren't patches maintainers are required to
+> take pretty much says that maintainers aren't required to integrate with
+> the synchronization protocols.
+
+In practice I think, given the political context, almost every daemon
+maintainer (or upstream) will be willing to provide at least _one_ of
+current the upstart and systemd protocols.
+
+I don't see any value in insisting that every daemon maintainer should
+support both, perhaps against their will, when supporting both
+protocols in each of the perhaps six init systems will be much less
+work overall.
+
+> We could do that.  In general, I'd really prefer to defer to maintainers
+> on what they're willing to integrate with.  [...]
+
+So in that case you're saying you wouldn't want to overrule a
+maintainer who declined to provide either of the currently available
+protocols.  Which seems to be the opposite of what you say above.
+
+> My inclination would be to give maintainers technical advice to
+> accept integrations with either existing synchronization protocols,
+> but leave it as technical advice rather than the binding part of the
+> decision.
+
+Of course formally all of this is just advisory, because no specific
+example is here yet.  But I take you to mean that you don't want to
+signal that we would overrule maintainers in particular circumstances.
+
+Let us suppose that we don't say anything in particular about what
+maintainers are expected to do.  (I'll also suppose WLOG that the TC
+collectively votes for upstart as default.)
+
+I would expect the following things to happen, then: upstart would get
+sd_notify support; an upstart contributor send a patch adding an
+upstart job for a daemon package which already supports systemd; the
+daemon maintainer rejects the patch; the upstart contributor refers
+the matter to us.
+
+If we signal now what we would think of such a situation then this
+will be less likely and if it does happen it will take much less long
+to resolve.
+
+(The same scenario might occur the other way round, although
+currently the systemd maintainers have rejected the proposal to
+support upstart's readiness protocol.)
+
+> > It also includes the important point that it is up to the maintainer to
+> > justify non-inclusion, not the other way around.
+> 
+> I guess the question here is how many conflicts we anticipate and whether
+> it's worth being somewhat confrontational ourselves to head it off.  If
+> there aren't conflicts in practice, we're just creating conflict without a
+> need.  I don't think it matters a tremendous amount, though.
+
+It is always easier and less personal to have these conversations in
+the abstract, before particular people have got upset about the
+specific question.
+
+I really think we should decide in advance some ground rules for what
+we would and would not be willing to force on a maintainer.
+
+> > I don't agree.  Unless we either have a compatibility shim, or a policy
+> > decision to transition, every package ought to be required to provide
+> > something in the Debian menus.  Isn't this situation analogous to the
+> > mime-support argument where we required a package to reinstate a mime
+> > entry ?
+> 
+> Sorry, I didn't state my objection very well.  I wasn't talking about
+> packages removing menu files.
+> 
+> Rather, your original wording to me sounds like introducing support for
+> desktop files in Debian would violate this guidance unless the one
+> introducing that support went through the Policy process first, even if
+> the new support did not conflict with menus and did not break anything
+> about menus.  That seems wrong.
+
+Perhaps my wording needs improving.  The problematic step is not the
+introduction of a parallel system.  The problematic steps are:
+
+ * Stopping providing menu files in existing menu entry providers
+
+ * Existing menu consumers stopping offering a way in the UI
+   to access the Debian menu system menu
+
+ * Justifying the above two steps on the grounds that menu is
+   "obsolete"
+
+All of these have happened, without a proper consideration of
+(a) the goals of _all_ the users and admins who rely on or use the
+Debian menu and how those goals can be met with the new arrangements
+and (b) a proper transition plan.
+
+No matter how creaky and obsolete the Debian menu system is (or is
+thought to be in some quarters), that's not the way to go about
+things.  It causes significant technical problems, and it's also very
+rude.
+
+We have unfortunately seen this same pattern more than once.  The
+evince mime entry is an example.  The bug report requesting that Colin
+disable binfmt-support when systemd is installed is another.
+
+> In other words, just introducing something that is intended as a
+> replacement for some existing Debian functionality should not require
+> coordinating with anyone.  What requires coordination is the point at
+> which the new functionality starts breaking the old functionality, so that
+> the project as a whole can decide that either we need to do something else
+> or that the old functionality isn't important and it's fine to break it.
+
+Yes.
+
+I shall try to reword this part to make this clear.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 18:12:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 18:12:04 GMT) (full text, mbox, link).

+ +

Message #2900 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 18:10:26 +0000
+
+
Russ Allbery writes ("Bug#727708: init system discussion status"):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > And the other is that IMO the proposed prescription for non-Linux ports
+> > doesn't make sense for systemd.  There is little prospect of systemd
+> > being "ported" to those systems.
+> 
+> I'd prefer to leave it in.  Upstream's opinions aside, systemd is free
+> software and if someone wants to try to port it (or, possibly more likely,
+> "port" it by writing something native that provides the same interfaces),
+> they can.  Maybe upstream is right and it's untenable; maybe they're wrong
+> and it's not as hard as they think.  I realize it's horribly unlikely for
+> jessie, but still, as a matter of principle, I'd rather encourage the same
+> software or at least the same interfaces across all of our ports.
+
+Personally I think leaving this in makes the resolution look surreal
+and out of touch.
+
+> But, anyway, we can focus on the upstart position first and deal with that
+> later.
+
+OK.
+
+> This seems fine to me, at least for right now.  I'm doing a bit of
+> additional research right now to be sure that I understand the
+> implications of this and may end up asking for any problems that anyone is
+> aware of with this approach, just to be sure we're not missing something.
+
+Right.  I looked at the reverse-dependencies of sysvinit in sid and
+didn't see anything untoward.
+
+> > I would like to be clear that maintainers don't need to take patches
+> > that introduce embedded copies of sd_notify.
+> 
+> Oh, okay.  I had missed that aspect of things.  I think it's fine to be
+> clear about that as long as we're not prohibiting via non-advice TC
+> decision using an embedded copy (which feels like bug severity inflation
+> to me).
+
+OK.  But I will hold off editing 6C for this as we seem to be moving
+in a different direction.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 18:18:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 18:18:09 GMT) (full text, mbox, link).

+ +

Message #2905 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Josh Triplett <josh@joshtriplett.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 18:14:30 +0000
+
+
(Josh, is there some reason why you replied to the TC list directly
+rather than the bug report ?  You should send your messages to the bug
+so they are filed, displayed and archived there.  Thanks.)
+
+Josh Triplett writes ("Re: Bug#727708: init system discussion status"):
+> Clint Adams wrote:
+> > As loath as I am to participate in this discussion, I have to ask
+> > if your intent is to suddenly outlaw all the packages which depend
+> > on runit.
+
+Thanks for your intervention which is helpful.
+
+> I think it'd be appropriate to allow dependencies on runit (or another
+> package that contains an implementation of /sbin/init), as long as
+> either the depending package doesn't depend on having /sbin/init be that
+> init (which holds true for runit),
+
+Right.
+
+> *or* if an alternative package exists to integrate with the default
+> init system.  For instance, git-daemon-run versus
+> git-daemon-sysvinit versus a hypothetical git-daemon-systemd,
+
+Personally I think this is a pretty nasty way for the git packages to
+have done things, although I understand why.  But, regardless, I think
+it's certainly fine from the init system compatibility point of view.
+
+> ...  (Note that the latter would work better if upstart stopped
+> conflicting with sysvinit, similar to how systemd can be installed
+> without being init.)
+
+There does seem to need to be some work there.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 18:36:27 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 18:36:27 GMT) (full text, mbox, link).

+ +

Message #2910 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 18:24:24 +0000
+
+
Russ Allbery writes ("Bug#727708: init system discussion status"):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > It seems daft to go around making two (or perhaps three or more) patches
+> > to every daemon when one patch to each daemon, and a couple of
+> > compatibility modes in the init systems, would suffice.
+> 
+> Okay, it's possible that we just disagree here.  Having actually done it,
+> I don't see any reason not to implement both the upstart and systemd
+> readiness protocols in a typical daemon.  It's not at all hard, and in
+> most cases one is going to want to implement socket activation on the
+> systemd side anyway, which makes the readiness protocol mostly irrelevant.
+
+The question isn't what you would prefer.  The question is this:
+
+Are you going to vote to overrule a maintainer who says 
+
+  I have already implemented non-forking readiness protocol X and I
+  think support for all init systems in my daemon should be done via
+  one protocol.  Please do send me a patch for your init system Y task
+  file (and correponding packaging support) when init system Y has
+  support for protocol X.
+
+?
+
+ISTM that if this situation arises it is due to a failure by the init
+system to be sufficiently accomodating.  I would vote to not overrule
+a maintainer in such a situation.
+
+> Whether systemd upstream should support the SIGSTOP protocol is certainly
+> debatable, but I'm very reluctant to support an option that tries to force
+> the systemd maintainers to support the protocol indefinitely as a
+> Debian-specific fork.
+
+We have endless Debian-specific patches which are precisely there to
+support additional protools which make packaging and integration
+easier.  OK, nowadays there is less need of this because our technical
+choices have been more widely recognised as good, but it is not
+something we should be afraid of.
+
+Support for raise(SIGSTOP) would be a small patch which Debian could
+easily carry indefinitely if need be.
+
+Consider for example the support for searching "whatever.d"
+directories for configuration of one kind or another, which has been
+added by many Debian maintainers first in their patches (and I bet
+there are packages where that's still not upstream).
+
+>  This protocol is not widely used in Debian at the
+> moment, nor is it widely used upstream, and I think it would be a far
+> better use of our time to add support for the systemd protocol to upstart.
+
+I think we need to add both protocols to both daemons.  This is
+because I want integration to be as easy and uncontroversial as
+possible.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 18:36:31 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 18:36:31 GMT) (full text, mbox, link).

+ +

Message #2915 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 18:28:26 +0000
+
+
Ian Jackson writes ("Re: Bug#727708: init system discussion status"):
+> Are you going to vote to overrule a maintainer who says 
+> 
+>   I have already implemented non-forking readiness protocol X and I
+>   think support for all init systems in my daemon should be done via
+>   one protocol.  Please do send me a patch for your init system Y task
+>   file (and correponding packaging support) when init system Y has
+>   support for protocol X.
+> 
+> ?
+> 
+> ISTM that if this situation arises it is due to a failure by the init
+> system to be sufficiently accomodating.  I would vote to not overrule
+> a maintainer in such a situation.
+
+This might prompt of course the question of whether I would vote to
+overrule the init system maintainer.
+
+If it were the default init system, certainly.  But I would not want
+to have the default init system be one where this was going to be
+necessary.  The response from the upstart maintainers to the request
+to support the systemd socket activation protocol convinces me this
+isn't a problem for upstart.  We know it is a problem with systemd.
+
+For a non-default init system it seems to me that this is a decision
+for that init system's community.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 18:36:33 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 18:36:34 GMT) (full text, mbox, link).

+ +

Message #2920 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 10:28:37 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Russ Allbery writes ("Bug#727708: init system discussion status"):
+
+>> I think they are.  Furthermore, I don't think there's any likely
+>> prospect that either will adopt a socket-based synchronization protocol
+>> other than systemd's, so saying that these aren't patches maintainers
+>> are required to take pretty much says that maintainers aren't required
+>> to integrate with the synchronization protocols.
+
+> In practice I think, given the political context, almost every daemon
+> maintainer (or upstream) will be willing to provide at least _one_ of
+> current the upstart and systemd protocols.
+
+> I don't see any value in insisting that every daemon maintainer should
+> support both, perhaps against their will, when supporting both protocols
+> in each of the perhaps six init systems will be much less work overall.
+
+>> We could do that.  In general, I'd really prefer to defer to
+>> maintainers on what they're willing to integrate with.  [...]
+
+> So in that case you're saying you wouldn't want to overrule a maintainer
+> who declined to provide either of the currently available protocols.
+> Which seems to be the opposite of what you say above.
+
+Yes, I know, I'm being confusing.  I'm sorry about that.  It's because I'm
+trying to balance two different goals, which are in conflict here.  One is
+that I prefer to defer to maintainers on how to maintain their own
+packages.  The other is that I think we all have some obligation to let
+other people work on things they care about if it doesn't cause disruptive
+impact on us.
+
+I think the wording path that you're going down right now requires us to
+take a firm stand one way or another, in advance, on what we're going to
+tell the whole project to do.  I consider telling people what to do to be
+an inherent problem, although sometimes an unavoidable one.  The more I
+think about this, the more I prefer to give maintainers the technical
+advice that they should integrate with any init system that is being
+actively developed, provided that it doesn't have a negative impact on
+their package, and leave it at that.
+
+If we have to decide whether to override a maintainer on whether to
+support a non-default init system, well, we'll have to decide that, and it
+will be unpleasant.  But I'm not sure we need to proactively dive into
+that unpleasantness.
+
+> Of course formally all of this is just advisory, because no specific
+> example is here yet.  But I take you to mean that you don't want to
+> signal that we would overrule maintainers in particular circumstances.
+
+Right.
+
+> Let us suppose that we don't say anything in particular about what
+> maintainers are expected to do.  (I'll also suppose WLOG that the TC
+> collectively votes for upstart as default.)
+
+> I would expect the following things to happen, then: upstart would get
+> sd_notify support; an upstart contributor send a patch adding an upstart
+> job for a daemon package which already supports systemd; the daemon
+> maintainer rejects the patch; the upstart contributor refers the matter
+> to us.
+
+I'm not sure why you think the "daemon maintainer rejects the patch" part
+of this is likely, particularly if upstart supports sd_notify, which makes
+the patch basically trivial.
+
+I don't think this is a likely conflict.  A much more likely conflict
+would be that upstart is adopted as the default init system, a daemon is
+patched to support raise(SIGSTOP), a systemd contributor submits a patch
+to support sd_notify (or socket activation), and the daemon maintainer
+rejects that patch.
+
+I personally think that such a patch should be accepted.  But I don't know
+that I'm willing to say in advance that we're going to try to force that
+patch to be accepted.  So I'm good with offering technical advice to
+accept such patches, but not with signaling that we're going to override
+people who don't.
+
+> It is always easier and less personal to have these conversations in the
+> abstract, before particular people have got upset about the specific
+> question.
+
+> I really think we should decide in advance some ground rules for what we
+> would and would not be willing to force on a maintainer.
+
+I consider the TC, when working properly, to be like a court, not an
+executive or legislature.  I therefore prefer focused and limited
+decisions for the same reasons that court decisions try to err on the side
+of being focused and limited.  That doesn't completely rule out your
+point, of course; courts, particularly high courts, set these sorts of
+guidelines for evaluating future cases all the time.  But I'm not seeing
+it as obviously necessary here.
+
+> No matter how creaky and obsolete the Debian menu system is (or is
+> thought to be in some quarters), that's not the way to go about things.
+> It causes significant technical problems, and it's also very rude.
+
+I would be more comfortable with this argument if we had a working Policy
+process that could reach these conclusions in a timely fashion.  It's been
+obvious to me that desktop files are a better (and, more importantly, more
+widely supported) representation of this information for over six years
+now, but given that I, as a Policy Editor, don't know how to effectively
+get there from here, I have a hard time blaming the GNOME and KDE
+maintainers for not knowing either.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 18:39:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 18:39:05 GMT) (full text, mbox, link).

+ +

Message #2925 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 10:37:25 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Russ Allbery writes ("Bug#727708: init system discussion status"):
+
+>> Whether systemd upstream should support the SIGSTOP protocol is
+>> certainly debatable, but I'm very reluctant to support an option that
+>> tries to force the systemd maintainers to support the protocol
+>> indefinitely as a Debian-specific fork.
+
+> We have endless Debian-specific patches which are precisely there to
+> support additional protools which make packaging and integration easier.
+> OK, nowadays there is less need of this because our technical choices
+> have been more widely recognised as good, but it is not something we
+> should be afraid of.
+
+I'm doubtful that either of us are going to convince the other on this
+point.  I don't consider it comparable to the other examples you're
+citing, and I think it's inobvious that raise(SIGSTOP) is a good technical
+choice.  Simple, yes, but that's not the same thing.
+
+Anyway, it's not at all clear to me that we need to argue about this here.
+If we adopt upstart, and a bunch of daemons are adapted to SIGSTOP, that's
+obviously going to increase the utility of supporting SIGSTOP in systemd.
+I would rather let the systemd maintainers discuss that situation with
+upstream and reach their own conclusions given the dynamics of that
+situation, which are difficult to predict in advance.  If we adopt
+systemd, then I think it's fairly uncontroversial to ask maintainers to
+adopt support for systemd's socket activation or, failing that,
+notification protocol.
+
+So, either way, I don't see the utility of making this kind of statement
+now.
+
+> I think we need to add both protocols to both daemons.  This is because
+> I want integration to be as easy and uncontroversial as possible.
+
+This is the sort of statement that carries one meaning when stated as a
+personal opinion as an individual Debian contributor, and a completely
+different meaning when included in a TC decision.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 18:45:20 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 18:45:20 GMT) (full text, mbox, link).

+ +

Message #2930 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 18:41:50 +0000
+
+
Russ Allbery writes ("Bug#727708: init system discussion status"):
+> I consider the TC, when working properly, to be like a court, not an
+> executive or legislature.
+
+One of our roles is to rule on the content of policy.  That's much
+more like a legislative role.
+
+I think we should see what the other TC members think.
+
+> > No matter how creaky and obsolete the Debian menu system is (or is
+> > thought to be in some quarters), that's not the way to go about things.
+> > It causes significant technical problems, and it's also very rude.
+> 
+> I would be more comfortable with this argument if we had a working Policy
+> process that could reach these conclusions in a timely fashion.  It's been
+> obvious to me that desktop files are a better (and, more importantly, more
+> widely supported) representation of this information for over six years
+> now, but given that I, as a Policy Editor, don't know how to effectively
+> get there from here, I have a hard time blaming the GNOME and KDE
+> maintainers for not knowing either.
+
+The TC has been more-or-less functional for some time.  If the policy
+process is not fit for purpose, or gets wedged due to lack of
+consensus, or whatever, then the TC is the place where that can be
+worked around.
+
+The old excuse that our governance processes don't work is, I think,
+no longer available in that case.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 18:45:23 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 18:45:23 GMT) (full text, mbox, link).

+ +

Message #2935 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 10:42:47 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> The question isn't what you would prefer.  The question is this:
+
+> Are you going to vote to overrule a maintainer who says 
+
+>   I have already implemented non-forking readiness protocol X and I
+>   think support for all init systems in my daemon should be done via
+>   one protocol.  Please do send me a patch for your init system Y task
+>   file (and correponding packaging support) when init system Y has
+>   support for protocol X.
+
+> ?
+
+> ISTM that if this situation arises it is due to a failure by the init
+> system to be sufficiently accomodating.  I would vote to not overrule
+> a maintainer in such a situation.
+
+I would rather not state an opinion on this at the moment, since I think
+it's a difficult decision and will depend on the exact situation in Debian
+at the time, the importance of the package, the disruption that might be
+caused by it not supporting a different init system, and so forth.  It's
+also going to matter quite a lot whether the one readiness protocol that
+they implemented is one that's supported by the default init system, and
+whether it's one supported by the init system used by the non-Linux ports.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 19:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Dimitri John Ledkov <xnox@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 19:03:05 GMT) (full text, mbox, link).

+ +

Message #2940 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Dimitri John Ledkov <xnox@debian.org>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 18:59:46 +0000
+
+
On 4 January 2014 15:46, Josselin Mouette <joss@debian.org> wrote:
+> Le samedi 04 janvier 2014 à 12:47 +0000, Ian Jackson a écrit :
+>> Uoti Urpala writes ("Bug#727708: init system discussion status"):
+>> > Your earlier wording sounds
+>> > like it was talking about the former ("installable") and Ian's proposal
+>> > definitely was (explicitly mentioning package fields), but the "fully
+>> > working" you use now sounds like it's about the latter.
+>>
+>> Thanks for pointing this out.  My proposal is too weak in this
+>> respect.  I intended to make the stronger statement.
+>
+>> I think systemd-ui is part of the systemd init system so falls into
+>> the exception.  Of course that means that nothing else should depend
+>> (functionally or in package dependencies) on it.
+>
+> There is no way that, for example, some of the GNOME control center
+> applets will work at all without systemd.
+>
+> It is already hard enough to imagine that we would have to ship packages
+> without the appropriate dependencies on systemd; expecting them to have
+> the same functional coverage without it is simply insane.
+>
+
+Can you please explain how a user-level application is dependent on
+the system (root) init daemon be systemd-init? Especially since it's
+expected to have sysvinit fully functional in Jessie.
+Or is this to do with other, inferior to those currently in debian,
+ways of e.g. setting up system-wide locales? Or does it depend on
+other APIs, which have multiple alternative providers, e.g.
+systemd-logind.
+
+With a decision for systemd, are we by transitive means[1] mandating
+usage of all other daemons present in the systemd source package and
+overruling maintainers of existing functionality with alternative or
+compatible APIs[2]?
+
+If we are choosing, non-standartised systemd APIs[3], surely it should
+be done as a runtime detection, rather than packaging level
+dependency. Because there are multiple providers of the same APIs,
+possible at different compatibility levels of systemd versioning and
+until upgraded system is rebooted, only some implementations can start
+and be already running. Although not supported officially, I do like
+that stable can typically be fully functional since the dist-upgrade.
+Also it is sad that systemd upstream is actively promoting for
+everyone to execute runtime checks of "is systemd-init pid1, and
+what's systemd version number", granted Martin Pitt did identify this
+problem and fixed majority of opensource projects to check for the
+requested/required functionality, instead of arbitrary transitive
+checks of pid1. This in part enables to run systemd-logind without
+systemd-init as pid 1.
+
+Also which upstream are staying with? systemd upstream git history[4]
+has only one branch, which is linear with linear version number
+increments, without any stable release branches or other indications
+of which patches are stable (or possibly security) bugfixes. Fedora 19
+appears to be packaging patches from v204-stable branch which I can't
+find anywhere public. Thankfully it's not a single giant patch as it's
+done by RedHat for their kernels, but actually git am formatted series
+of 116 patches[5].
+
+The diffstat between:
+- debian package and git v204 checkout is: 44 files, 246 +, 566 -
+- fedora 19-204 and v204 tarball: 102 files, 11368 +, 1366 -
+- rhel 7-beta-src-iso and v207 tarball: 133 files changed, 2364
+insertions(+), 1686 deletions(-)
+
+Which is a significant chunk of fixes. Looking at some of them, they
+are true gems like "don't truncate and loose multiline syslog
+messages" which is not fixed in Debian at the moment. Can we please
+not have journald by default in jessie, cause I don't want my syslog
+truncated?!
+
+In my opinion it is unwise to ship something into stable, ahead of
+upstream doing so for their support customers (RedHat Enterprise
+Linux). We've had a charming history of doing so with pulseaudio: with
+default in 2007 in Fedora, shipped in stable Ubuntu 8.04 LTS in 2008,
+where Lennart promote it as stable to Ubuntu Developers at first, and
+later claiming that "Ubuntu didn't exactly do a stellar job. They
+didn't do their homework." Redhat enterprice linux has shipped it
+version 6 - in 2011 it seems. Pulseaudio did turn out ok, although
+years later, after extensive usage by real customers base
+(unfortunately Ubuntu customers first, and later RedHat's).
+
+Fedora/RPM based distributions are significantly different, thus it is
+inevitable that we'll have to maintain a fork of systemd for best
+integration into Debian. This does not seem evident from the current
+systemd maintainers, which file bugs to disable/remove/override debian
+functionality and components with inferior systemd counterparts.
+
+Now the questions is, what will RHELv7 ship? is it v204, v204-stable
+(non-public git), v207-stable (non-public git), v208, v208-stable
+(non-public git)? And what level of systemd is targetted to be
+integrated into jessie?
+At the moment RHEL beta 7 has systemd-207 with 95 long patch series.
+This looks to me as in-flux state. How is systemd stable maintenance
+going to be handled in the future? with redhat subscription?
+
+It seems to me that init component has been extensively reviewed, but
+what about other components. Post 204/205, logind appears to require
+systemd's api for cgroup management, but the cgroup manager done in
+systemd is inferior to all other cgroup management implementations[7].
+Are we going to support systemd/logind with alternative (and superior)
+cgroups managers, and for example more portable logind with
+systemd-shim. Granted in debian we have pleora of Desktop
+Environments, Logind Managers, and container/virtualisations solutions
+that all work. Some have more or less dependencies. And it appears to
+me beneficial for even more things to be enabled, e.g. newer GNOME
+with it's dependcies on APIs from some of the bundled
+systemd-collection-of-daemons, provided with or without systemd-init
+as pid1, or those APIs provided by alternative implementations.
+Similarly I do not wish for server/container/virtualisations on Debian
+to be worsened by the default set of applications "for GNOME", and
+e.g. still allow to use and start containers of any linux
+distributions and fully exercise all resource allocations APIs exposed
+by the kernel (e.g. cgroupsfs, etc).
+
+Upstream stability guarantees, which are also quite loudly shouted
+here, do not appear to be kept. E.g. at the time consolekit -> logind
+migration was pitched to DEs, there was no hard cgroups requirement
+(it was an optional logind feature) which is now present with post-DEs
+migrating to logind. Whilst I partially understand the tarpit of
+pre-consolekit problems, how consolekit fixed some of those, and how
+logind improved on that; on the other hand, even after porting one of
+my upstream projects to logind, I still don't know and understand
+logind usefulness on headless/server deployments or the meanings of
+the missnamed logind specific variables XDG_VTNR, XDG_SESSION_ID,
+XDG_SESSION_PATH, XDG_SEAT[9]. Especially in the light of kdbus
+removing per-session dbus and leaving only a per-user dbus. If indeed
+systemd's cgroups API is as frozen, as argued by systemd proponents,
+I'm worried that debian will be stuck with inferior cgroups support.
+
+Contrasting with upstart, it is shipped in stable and commercially
+supported distributions by majority linux vendors [8] and large
+corporations (cisco, google, lg, etc.). It's codebase is highly
+stable, point-releases / stable branches are created when bug-fixes
+are cherrypicked, updates granularity matches 6-monthly ubuntu
+releases and there are two or more supported LTS releases for any
+given supported debian release. The diff between upstart as packaged
+and upstream is minimal, the largest difference is selinux patch
+(non-cla patch, carried for a long time and compile time option
+enabled by roughly half or more upstart deployments) and the rest are
+minor tweaks for integration with debian-like systems (e.g.
+initramfs-tools), grand total of less than 175 lines. Oh, and one is
+free to use any available cgroups managers and move any processes into
+respective cgroups resource group, use bundled systemd-noninit daemons
+APIs for the DE of your choice (and given the pleora of gnome2/3 forks
+it's evident that GNOME-latest is not a silver bullet for all), etc.
+
+
+[1] upstream unwilling to support multiple equivalent components &
+debian maintainers of systemd willing to keep packaging as close to
+upstream as possible: e.g. support for alternative & superior cgroups
+management/logind, our support for setting system-wide locales,
+integration with binfmt-support etc.
+[2] e.g. systemd-shim/logind, pam-xdg-support, etc.
+[3] by which i mean for example peer reviewed freedesktop spec of dbus
+verses all the ways systemd-kdbus is backwards incompatible &
+regressing feature-wise (no per-session dbus, new marshalling, no
+activation support, reduced policy support, etc.)
+[4] it appears that upstream git is used as packaging basis, instead
+of the tarball which has pre-generated documentation and loads of
+other files.
+[5] Which by the way mostly applies on top of debian packaging - all
+but 6 or 7ish.
+[6] recall, that redhat & fedora migrated from upstart, non sysvinit.
+[7] one is only offered limited resource allocation apis when compared
+to cgroupsfs (with or without multiple hierarchy), the Google's
+lmctfy, and the cgroupsmanager by hallyn (not sure about the official
+name)
+[8] and all of them are here to stay for extended periods of time from now
+[9] and their leakage to my sbuild logs
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729012
+
+-- 
+Regards,
+
+Dimitri.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 19:06:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 19:06:08 GMT) (full text, mbox, link).

+ +

Message #2945 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 11:02:44 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Jan 03, 2014 at 04:40:54PM -0800, Russ Allbery wrote:
+> > And the other is that IMO the proposed prescription for non-Linux ports
+> > doesn't make sense for systemd.  There is little prospect of systemd
+> > being "ported" to those systems.
+
+> I'd prefer to leave it in.  Upstream's opinions aside, systemd is free
+> software and if someone wants to try to port it (or, possibly more likely,
+> "port" it by writing something native that provides the same interfaces),
+> they can.  Maybe upstream is right and it's untenable; maybe they're wrong
+> and it's not as hard as they think.  I realize it's horribly unlikely for
+> jessie, but still, as a matter of principle, I'd rather encourage the same
+> software or at least the same interfaces across all of our ports.
+
+If it's "horribly unlikely for jessie", then it doesn't seem to me like
+something that the TC should be telling porters they "should" do.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 19:12:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 19:12:10 GMT) (full text, mbox, link).

+ +

Message #2950 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 11:08:36 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+> On Fri, Jan 03, 2014 at 04:40:54PM -0800, Russ Allbery wrote:
+
+>> I'd prefer to leave it in.  Upstream's opinions aside, systemd is free
+>> software and if someone wants to try to port it (or, possibly more
+>> likely, "port" it by writing something native that provides the same
+>> interfaces), they can.  Maybe upstream is right and it's untenable;
+>> maybe they're wrong and it's not as hard as they think.  I realize it's
+>> horribly unlikely for jessie, but still, as a matter of principle, I'd
+>> rather encourage the same software or at least the same interfaces
+>> across all of our ports.
+
+> If it's "horribly unlikely for jessie", then it doesn't seem to me like
+> something that the TC should be telling porters they "should" do.
+
+I thought that was already resolved?  I objected to the "should" in the
+original language regarldess of which init system we choose, and Ian said
+that he'd reworded it already to something akin to mine, which just says
+that ports will use the same default init system if it has been ported,
+otherwise yadda yadda.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 19:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 19:30:04 GMT) (full text, mbox, link).

+ +

Message #2955 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Cc: Josh Triplett <josh@joshtriplett.org>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 11:27:26 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Jan 04, 2014 at 06:14:30PM +0000, Ian Jackson wrote:
+> > ...  (Note that the latter would work better if upstart stopped
+> > conflicting with sysvinit, similar to how systemd can be installed
+> > without being init.)
+
+> There does seem to need to be some work there.
+
+That has already been resolved in unstable, with the split of sysvinit
+contents out of the Essential: yes sysvinit into sysvinit-core.  (A
+necessary precondition for switching to either systemd-sysv or upstart for
+jessie.)
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 19:33:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 19:33:10 GMT) (full text, mbox, link).

+ +

Message #2960 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 19:28:56 +0000
+
+
Russ Allbery writes ("Bug#727708: init system discussion status"):
+> I thought that was already resolved?  I objected to the "should" in the
+> original language regarldess of which init system we choose, and Ian said
+> that he'd reworded it already to something akin to mine, which just says
+> that ports will use the same default init system if it has been ported,
+> otherwise yadda yadda.
+
+I nicked your wording.  Mutatis mutandi, it would say:
+
+ 2. The default init(1) in jessie for non-Linux ports will be systemd
+    if it has been ported and confirmed by the porters to be working by
+    the time of the jessie release.  Failing this, the default init(1)
+    in jessie for non-Linux ports is left to the discretion of the
+    maintainers of that port.
+
+    [ However, the Technical Committee requests that, should systemd be
+    unavailable on both Hurd and kFreeBSD, the Hurd and kFreeBSD
+    porters agree on a single alternative init(1) implementation that
+    will be shared by both ports. ]
+
+    [ Non-use of systemd should not be a criterion for architecture
+    qualification status in jessie. ]
+
+I think this is a daft thing to say.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 19:33:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 19:33:13 GMT) (full text, mbox, link).

+ +

Message #2965 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 20:28:53 +0100
+
+
]] Russ Allbery 
+
+> 2. Package logind separately from systemd, get it working with sysvinit.
+>    The problems with doing this, as I understand it, is that we'd not be
+>    able to upgrade such a separately-packaged logind beyond 204 for
+>    jessie.  I'm not sure how much impact that would have.  Also, it
+>    sounded to me like we would need to figure out who was going to do that
+>    work and maintain that package, including in the stable release.  If
+>    the current systemd maintainers are not interested in doing this, we
+>    absolutely shouldn't try to force them to do so.  Someone else would
+>    need to step forward to do this and figure out the right package
+>    relationships.  (Also, it would be good to maintain this separately so
+>    that the systemd maintainers could move forward with newer versions of
+>    systemd, including the logind built from its source.)
+
+[...]
+
+> The systemd maintainers should definitely feel free to tell me if I'm
+> misunderstanding their feelings on option 2.
+
+You are not.
+
+I'd like to expand slightly that I'd be ok with having it part of the
+systemd package as long as somebody shows up and commits to maintaining
+that functionality long-term and with the explicit understanding of the
+TC that if the necessary manpower to do that work disappears we will not
+be holding to rest of the init system back.  It might be that packaging
+up logind completely separately by such a person (or team) might be a
+better approach (as you suggest).
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 19:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 19:45:04 GMT) (full text, mbox, link).

+ +

Message #2970 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 20:42:29 +0100
+
+
]] Dimitri John Ledkov 
+
+> Also which upstream are staying with? systemd upstream git history[4]
+> has only one branch, which is linear with linear version number
+> increments, without any stable release branches or other indications
+> of which patches are stable (or possibly security) bugfixes.
+
+That's generally communicated in the release announcements as well as on
+the systemd-devel mailing list.
+
+> Fedora 19 appears to be packaging patches from v204-stable branch
+> which I can't find anywhere public. Thankfully it's not a single giant
+> patch as it's done by RedHat for their kernels, but actually git am
+> formatted series of 116 patches[5].
+
+Were you unable to find
+http://pkgs.fedoraproject.org/cgit/systemd.git/log/?h=f19 ?  It's where
+Fedora has all of their packaging..
+
+> Fedora/RPM based distributions are significantly different, thus it is
+> inevitable that we'll have to maintain a fork of systemd for best
+> integration into Debian. This does not seem evident from the current
+> systemd maintainers, which file bugs to disable/remove/override debian
+> functionality and components with inferior systemd counterparts.
+
+Can you provide bug numbers for those allegations, please?
+
+> [4] it appears that upstream git is used as packaging basis, instead
+> of the tarball which has pre-generated documentation and loads of
+> other files.
+
+If you here are talking about the systemd packaging, it seems you've
+misunderstood something.  What are you missing in the source package?
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 19:45:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 19:45:07 GMT) (full text, mbox, link).

+ +

Message #2975 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org, + Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 11:43:05 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Jan 04, 2014 at 11:08:36AM -0800, Russ Allbery wrote:
+> Steve Langasek <vorlon@debian.org> writes:
+> > On Fri, Jan 03, 2014 at 04:40:54PM -0800, Russ Allbery wrote:
+
+> >> I'd prefer to leave it in.  Upstream's opinions aside, systemd is free
+> >> software and if someone wants to try to port it (or, possibly more
+> >> likely, "port" it by writing something native that provides the same
+> >> interfaces), they can.  Maybe upstream is right and it's untenable;
+> >> maybe they're wrong and it's not as hard as they think.  I realize it's
+> >> horribly unlikely for jessie, but still, as a matter of principle, I'd
+> >> rather encourage the same software or at least the same interfaces
+> >> across all of our ports.
+
+> > If it's "horribly unlikely for jessie", then it doesn't seem to me like
+> > something that the TC should be telling porters they "should" do.
+
+> I thought that was already resolved?  I objected to the "should" in the
+> original language regarldess of which init system we choose, and Ian said
+> that he'd reworded it already to something akin to mine, which just says
+> that ports will use the same default init system if it has been ported,
+> otherwise yadda yadda.
+
+Ah - sorry, I apparently missed that. 
+
+On Sat, Jan 04, 2014 at 07:28:56PM +0000, Ian Jackson wrote:
+> I nicked your wording.  Mutatis mutandi, it would say:
+
+>  2. The default init(1) in jessie for non-Linux ports will be systemd
+>     if it has been ported and confirmed by the porters to be working by
+>     the time of the jessie release.  Failing this, the default init(1)
+>     in jessie for non-Linux ports is left to the discretion of the
+>     maintainers of that port.
+
+>     [ However, the Technical Committee requests that, should systemd be
+>     unavailable on both Hurd and kFreeBSD, the Hurd and kFreeBSD
+>     porters agree on a single alternative init(1) implementation that
+>     will be shared by both ports. ]
+
+>     [ Non-use of systemd should not be a criterion for architecture
+>     qualification status in jessie. ]
+
+> I think this is a daft thing to say.
+
+I don't have a problem with this version of the wording, with the "should"
+removed.  While I think a systemd port is highly unlikely, I don't think it
+hurts anything for the TC to express a preference for all ports to be on the
+same page.
+
+The probability of this *happening* for a particular option will influence
+my vote, but I think it's a sound technical recommendation regardless.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 19:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 19:48:04 GMT) (full text, mbox, link).

+ +

Message #2980 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 11:45:52 -0800
+
+
On Sat, Jan 04, 2014 at 06:14:30PM +0000, Ian Jackson wrote:
+> (Josh, is there some reason why you replied to the TC list directly
+> rather than the bug report ?  You should send your messages to the bug
+> so they are filed, displayed and archived there.  Thanks.)
+
+I don't subscribe to debian-ctte@; I read it via the list archives.
+I've been replying using the "Reply to:" links at the bottom of mails,
+and then manually copying and quoting the responses.  Those links reply
+to debian-ctte@lists.debian.org, so unless I manually edit the
+destination (which I've done in a few cases where the destination was a
+bug report), it ends up going to the list.
+
+It'd be nice if those links paid attention to the
+To/Cc/Reply-To/Mail-Followup-To addresses, and otherwise acted like
+hitting the reply key in a mail client.  I'd also add my voice to the
+set of people who have requested mbox archives in the past.
+
+> Josh Triplett writes ("Re: Bug#727708: init system discussion status"):
+> > Clint Adams wrote:
+> > > As loath as I am to participate in this discussion, I have to ask
+> > > if your intent is to suddenly outlaw all the packages which depend
+> > > on runit.
+> 
+> Thanks for your intervention which is helpful.
+> 
+> > I think it'd be appropriate to allow dependencies on runit (or another
+> > package that contains an implementation of /sbin/init), as long as
+> > either the depending package doesn't depend on having /sbin/init be that
+> > init (which holds true for runit),
+> 
+> Right.
+> 
+> > *or* if an alternative package exists to integrate with the default
+> > init system.  For instance, git-daemon-run versus
+> > git-daemon-sysvinit versus a hypothetical git-daemon-systemd,
+> 
+> Personally I think this is a pretty nasty way for the git packages to
+> have done things, although I understand why.  But, regardless, I think
+> it's certainly fine from the init system compatibility point of view.
+
+I'm not a big fan of its long insistence on runit (git-daemon-sysvinit
+came much later), but I actually rather like the idea of putting init
+scripts and systemdiwde configuration in a separate package from
+daemons.  In the case of git, it makes sense because the daemon lives in
+the "git" package, which shouldn't start a daemon.  More generally,
+though, I wish more packages were split the way Apache is, with one
+package containing the daemon and all supporting files, and the other
+package containing the configuration for a systemwide daemon.  I've
+found that particularly useful on many occasions.
+
+> > ...  (Note that the latter would work better if upstart stopped
+> > conflicting with sysvinit, similar to how systemd can be installed
+> > without being init.)
+> 
+> There does seem to need to be some work there.
+
+As I understand it, conflicting with sysvinit and not offering a package
+that can be installed in parallel with it was an intentional decision on
+the upstart maintainers' parts.
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 19:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 19:51:05 GMT) (full text, mbox, link).

+ +

Message #2985 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 4 Jan 2014 11:48:23 -0800
+
+
On Sat, Jan 04, 2014 at 11:27:26AM -0800, Steve Langasek wrote:
+> On Sat, Jan 04, 2014 at 06:14:30PM +0000, Ian Jackson wrote:
+> > > ...  (Note that the latter would work better if upstart stopped
+> > > conflicting with sysvinit, similar to how systemd can be installed
+> > > without being init.)
+> 
+> > There does seem to need to be some work there.
+> 
+> That has already been resolved in unstable, with the split of sysvinit
+> contents out of the Essential: yes sysvinit into sysvinit-core.  (A
+> necessary precondition for switching to either systemd-sysv or upstart for
+> jessie.)
+
+That solves one part of the problem, in that the package upstart
+conflicts with is no longer Essential; however, that still doesn't allow
+installing upstart without making it /sbin/init.  A split similar to the
+one between systemd and systemd-sysv would make that possible, allowing
+users to try out upstart by setting init= on the kernel command line,
+and allowing packages to use upstart for purposes other than running it
+as init (for instance, for graphical session startup).
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 20:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 20:00:04 GMT) (full text, mbox, link).

+ +

Message #2990 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: 727708@bugs.debian.org, Tollef Fog Heen <tfheen@err.no>
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Sat, 4 Jan 2014 11:56:55 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Dec 31, 2013 at 09:09:52PM +0100, Tollef Fog Heen wrote:
+> ]] Ian Jackson 
+
+> > I think you have misunderstood.  Or perhaps I hae misunderstood you.
+> > The "work" that I'm saying needs to be done anyway is the work to
+> > disentange the parts of systemd which are required by (say) GNOME from
+> > the parts which are only relevant for systemd as init.
+
+> > This is work that would have to be done by the systemd maintainers in
+> > Debian.
+
+> I find it quite clear that this should be done and maintained by the
+> people who want to run such an configuration.  I am not running any
+> non-systemd desktop systems and would be in a very poor positition to be
+> able to do this work.  I also have no interest in it, which I think
+> should be pretty clear given my previous mails on the subject.
+
+> We've also said quite clearly that we'd gladly accept a co-maintainer
+> who wants to maintain this configuration, but nobody has shown up yet.
+
+I'm glad to hear that this is the case - though as for saying it "quite
+clearly", I believe this is the first time I've heard it said.
+
+If I volunteer to maintain this config, does that remove the concern about
+splitting the systemd binary package?  (Modulo the issue expressed in your
+latest mail, that you don't want this to hold back inclusion of newer
+upstream revisions of systemd in Debian, which I agree needs to be
+respected.)
+
+> (Martin Pitt has worked a bit with us on getting the patches from Ubuntu
+> integrated, but AIUI, he's not been able to offer a long-term commitment
+> to maintaining the patches, and I think it's a very bad idea to merge a
+> patchset that nobody in the team wants to maintain long-term.)
+
+Though the differences in the choice of packaging VCS make it awkward to do
+a per-patch comparison between the Debian and Ubuntu packages, from what I
+see there is only one outstanding Ubuntu patch required to make logind v204
+runnable without PID1 in Debian.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 20:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 20:18:05 GMT) (full text, mbox, link).

+ +

Message #2995 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Sat, 04 Jan 2014 21:16:14 +0100
+
+
]] Steve Langasek 
+
+> On Tue, Dec 31, 2013 at 09:09:52PM +0100, Tollef Fog Heen wrote:
+> > ]] Ian Jackson 
+> 
+> > > I think you have misunderstood.  Or perhaps I hae misunderstood you.
+> > > The "work" that I'm saying needs to be done anyway is the work to
+> > > disentange the parts of systemd which are required by (say) GNOME from
+> > > the parts which are only relevant for systemd as init.
+> 
+> > > This is work that would have to be done by the systemd maintainers in
+> > > Debian.
+> 
+> > I find it quite clear that this should be done and maintained by the
+> > people who want to run such an configuration.  I am not running any
+> > non-systemd desktop systems and would be in a very poor positition to be
+> > able to do this work.  I also have no interest in it, which I think
+> > should be pretty clear given my previous mails on the subject.
+> 
+> > We've also said quite clearly that we'd gladly accept a co-maintainer
+> > who wants to maintain this configuration, but nobody has shown up yet.
+> 
+> I'm glad to hear that this is the case - though as for saying it "quite
+> clearly", I believe this is the first time I've heard it said.
+
+I think I've said it twice already in this (quite long) bug mail thread.
+
+> If I volunteer to maintain this config, does that remove the concern about
+> splitting the systemd binary package?  (Modulo the issue expressed in your
+> latest mail, that you don't want this to hold back inclusion of newer
+> upstream revisions of systemd in Debian, which I agree needs to be
+> respected.)
+
+I believe so.  We should probably sit down and discuss exactly how this
+will look, which I haven't really got the time for right now.  (I'm on
+my way from holiday in Spain to LCA in, well, Australia.)  I'd be happy
+to talk about this in ten days time or so?
+
+> > (Martin Pitt has worked a bit with us on getting the patches from Ubuntu
+> > integrated, but AIUI, he's not been able to offer a long-term commitment
+> > to maintaining the patches, and I think it's a very bad idea to merge a
+> > patchset that nobody in the team wants to maintain long-term.)
+> 
+> Though the differences in the choice of packaging VCS make it awkward to do
+> a per-patch comparison between the Debian and Ubuntu packages, from what I
+> see there is only one outstanding Ubuntu patch required to make logind v204
+> runnable without PID1 in Debian.
+
+Martin had a small pile of patches he wanted to get in.  Their inclusion
+has mostly been blocked on me actually having the time to review and
+include them.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 21:21:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cory <opensourcesoftwaredeveloper@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 21:21:05 GMT) (full text, mbox, link).

+ +

Message #3000 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cory <opensourcesoftwaredeveloper@gmail.com>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system other points, and conclusion
+
Date: Sat, 04 Jan 2014 15:20:00 -0600
+
+
On 01/04/2014 12:07 PM, Russ Allbery wrote:
+> Cory <opensourcesoftwaredeveloper@gmail.com> writes:
+>
+>> If Debian go's with systemd they need to use systemd 207 as its
+>> supported in RHEL 7 so we know it's going to be supported for around 10
+>> years also why does Debian have systemd 204 in it's repos?? systemd 207
+>> is way better
+> Because it's the last version before cgroup handling was changed, which
+> has implications for supporting logind under different init systems than
+> systemd.  So, in other words, moving systemd forward right now would force
+> various incompatibilities in an excessively disruptive way before we've
+> figured out how we want to handle them.
+>
+> Regardless of how we decide this, we'll be figuring out how systemd could
+> move forward with newer versions, but it's wrapped up with the broader
+> discussion.
+>
+>
+
+logind under different init systems, is a hack job and, is not a real implantation and, should not be used, logind should only be used on systemd systems this is bad that people are trying to fork logind this way and we're soon going to have 4 DE's that use it and or even require logind KDE, Gnome, MATE, E18, all 4 use logind atm and E19 is going to be Wayland based so thats also going to require systemd down the road as systemd and wayland go's hand and hand, so most all of the main linux desktop environments will have systemd  integration andor require it
+
+i think theincompatibilities down the road on Linux will be not using systemd also BSD is working on there own init system like systemd
+
+a huge thing to think about we can openly send patches to the systemd maintainers as over 500 developers have been doing so far
+
+Gentoo also is now using systemd as a sysvinit and, RC replacement for Linux systems
+http://wiki.gentoo.org/wiki/Systemd
+
+if Debian end up using Upstart willCanonical force  alicense for Upstart?? Just like they're doing to Linux Mint and other Linux's based off from Ubuntu
+http://distrowatch.com/weekly.php?issue=20131209#qa
+
+to use Upstart in Ubuntu any ways you have to pullin systemd packages shim-systemd libsystemd-daemon systemd-services Etc i think Ubuntu 13.10 used even more IIRC so will Debian have to do the same? whats the point of not using systemd if you have to pull in the packages for it any ways??
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 23:15:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sjoerd Simons <sjoerd@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 23:15:07 GMT) (full text, mbox, link).

+ +

Message #3005 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sjoerd Simons <sjoerd@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 05 Jan 2014 00:13:34 +0100
+
+
On Sat, 2014-01-04 at 09:56 -0800, Russ Allbery wrote:
+> Sjoerd Simons <sjoerd@debian.org> writes:
+
+> > Not having the logind interface is a lot harder to cope with and
+> > something that will not only impact Gnome. So essentially the most
+> > likely impact of using sysvinit _without_ a provider of the logind
+> > interface would be a non-usable Gnome desktop (and potentially even GDM
+> > to be unusable) on Jessie systems.
+> 
+> If we go with systemd, I think we have three options:
+> 
+> 1. Allow packages that require logind to depend on systemd and require
+>    that it be used as the init system.  This is certainly the simplest for
+>    packaging applications that want to depend on logind, as well as for
+>    the systemd maintainers.  However, it means we lose the ability for
+>    users of at least those packages to be able to fall back on sysvinit if
+>    something goes wrong with systemd on their systems.  In the past, we've
+>    tried pretty hard to provide that capability when making a disruptive
+>    change of this kind.
+
+This one feels like a bit of a cost/benefit analysis to me. Is it worth
+it to force all packages to work properly (for some definition of
+properly) on a sysvinit system even in cases where this is a non-trivial
+amount of work?  For e.g. daemon packages where this typically is a
+matter of keeping/writing an  init script  the cost is obviously very
+low, so probably worth it.
+
+For something like Gnome, it's a lot less obvious in my opinion. 
+
+> 2. Package logind separately from systemd, get it working with sysvinit.
+>    The problems with doing this, as I understand it, is that we'd not be
+>    able to upgrade such a separately-packaged logind beyond 204 for
+>    jessie.  I'm not sure how much impact that would have.  Also, it
+>    sounded to me like we would need to figure out who was going to do that
+>    work and maintain that package, including in the stable release.  If
+>    the current systemd maintainers are not interested in doing this, we
+>    absolutely shouldn't try to force them to do so.  Someone else would
+>    need to step forward to do this and figure out the right package
+>    relationships.  (Also, it would be good to maintain this separately so
+>    that the systemd maintainers could move forward with newer versions of
+>    systemd, including the logind built from its source.)
+
+> 3. Get GNOME working at some level without logind.  I think it would be
+>    entirely acceptable for there to be some loss of functionality when
+>    GNOME is started in this way, such as no user switching and some
+>    configuration and control panels that rely on logind functionality not
+>    working.  But it would need to at least start and be basically
+>    functional for this to be a meaningful option.
+
+The problem with this option is how to define "some level" and
+"basically functional".. If it's enough to be able to login, launch some
+applications and have some basic window manager functionality that's
+probably possible.
+
+However some functionality which I would find pretty basic, e.g.
+configuring the network, suspending the machine, locking the screen
+might not be available. 
+
+Also, would "basic functionality" mean that if things fail they fail
+gracefully? Given modern Gnome essentially doesn't get tested in a
+non-systemd environment anymore I'm sure there a lots of rough edges
+around.
+
+> None of these options are very appealing, but I think we have to pick one
+> of them.  I'm not seeing other options at the moment.
+> 
+> I think option 3 would be the most appealing for the project as a whole,
+> but I realize that's also the option that puts the most burden on GNOME
+> maintainers.  The only upside I can offer for that is that this would be
+> in the context of moving forward with systemd and would be a one-release
+> issue.  Post jessie, you'd be able to move forward with a standard
+> integration.
+
+> It's worth noting that option 3 is also what would be required if we
+> wanted to support GNOME on kFreeBSD.  I'm not sure if anyone is working on
+> that port or sufficiently interested in it to try to make it work, but
+> there may be some additional resources there.
+
+Actually for the project as a whole and for porting to KFreeBSD i would
+find option 2 more appealing as a starting point. logind is not just
+used by GNOME, so doing so is more generally useful. Especially for
+KFreeBSD as it lowers the barrier for entry for all logind users. 
+
+> Do you think there's a way that we could make option 3 work that the GNOME
+> maintainers would be comfortable with?
+
+Do you think there is a way you can find someone willing to do the
+work? :).. 
+
+The problem with both 2 and 3 is that it's work that needs to be done
+and maintained at least until Jessie is released. Which is work that as
+far as I'm aware nobody in the current Gnome team is motivated to do. 
+
+So unless someone volunteers to take up the challenge to do the required
+work (and succeeds in doing so!), to me the options of what to do for
+Gnome in Jessie are:
+  0) Provide the user with a massively degraded Gnome 3 desktop
+     experience with no/bare minimal support from the gnome
+     maintainers when using sysvrc
+  1) Indicate to the user that Gnome 3 is only supported when using
+     the default init system as PID 1.
+
+From those I personally think option 1 is actually the better option and
+much more honest to our users then pretending Gnome 3 works with
+sysvinit. 
+
+
+> The systemd maintainers should definitely feel free to tell me if I'm
+> misunderstanding their feelings on option 2.
+> 
+> Do you think I should ask more generally on debian-devel if there are any
+> other maintainers in Debian that anticipate any problem with either
+> requiring sysvinit be supported as PID 1 for jessie, or with logind being
+> an optional component for jessie?
+
+It's probably worth asking the maintainer of the other desktop
+environments what the impact on their desktops environments is if any.
+I'm aware that some other desktops started using logind, not sure about
+the other systemd interfaces.
+
+
+-- 
+Sjoerd Simons <sjoerd@debian.org>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 04 Jan 2014 23:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 04 Jan 2014 23:21:04 GMT) (full text, mbox, link).

+ +

Message #3010 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: Dimitri John Ledkov <xnox@debian.org>
+
Cc: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org, + Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 5 Jan 2014 00:16:58 +0100
+
+
On Sat, Jan 04, 2014 at 06:59:46PM +0000, Dimitri John Ledkov wrote:
+> Also it is sad that systemd upstream is actively promoting for
+> everyone to execute runtime checks of is systemd-init pid1,...
+This is done public systemd libraries to become NOPs if not running on
+or not compiled for systemd, to make it easier to integrate
+systemd-related functionality in programs portable to other
+environments. Full original functionality can be always trivially
+restored.
+
+Built-in systemd components do no such checks, and generally are
+written with the assumption that they are using the same systemd
+versions. (What I'm saying is quite inprecise, but because it's not
+the main point, I don't want to go into details.)
+
+> what's systemd version number",
+I'm not aware of any such checks.
+
+> granted Martin Pitt did identify this
+> problem and fixed majority of opensource projects to check for the
+> requested/required functionality, instead of arbitrary transitive
+> checks of pid1. This in part enables to run systemd-logind without
+> systemd-init as pid 1.
+> 
+> Also which upstream are staying with? systemd upstream git history[4]
+> has only one branch, which is linear with linear version number
+> increments, without any stable release branches or other indications
+> of which patches are stable (or possibly security) bugfixes.
+git notes are used to mark backport-worthy commits. See
+http://lists.freedesktop.org/archives/systemd-devel/2013-September/013188.html.
+We currently mark patches as bugfixes (which includes fixes for bugs
+present in the latest release, but not those introduced later),
+or documentation and performance improvements.
+
+> Fedora 19 appears to be packaging patches from v204-stable branch
+> which I can't find anywhere public.
+It's my private branch I generate Fedora packages from [1]. It's the
+same content as in Fedora git repos [2], but in a more convenient form
+for me. I talked with other systemd maintainers in Fedora about making
+it more official and public, but we haven't found the time to do it
+yet. If it was to be useful to other people, it can certainly be done.
+
+[1] http://kawka.in.waw.pl/git/systemd/
+[2] http://cgit.freedesktop.org/systemd/systemd/
+
+> Thankfully it's not a single giant patch as it's
+> done by RedHat for their kernels, but actually git am formatted series
+> of 116 patches[5].
+>
+> The diffstat between:
+> - debian package and git v204 checkout is: 44 files, 246 +, 566 -
+> - fedora 19-204 and v204 tarball: 102 files, 11368 +, 1366 -
+> - rhel 7-beta-src-iso and v207 tarball: 133 files changed, 2364
+> insertions(+), 1686 deletions(-)
+> 
+> Which is a significant chunk of fixes. Looking at some of them, they
+> are true gems like "don't truncate and loose multiline syslog
+> messages" which is not fixed in Debian at the moment. Can we please
+> not have journald by default in jessie, cause I don't want my syslog
+> truncated?!
+> 
+> In my opinion it is unwise to ship something into stable, ahead of
+> upstream doing so for their support customers (RedHat Enterprise
+> Linux).
+I think you're overestimating the (direct) influence of Redhat on
+system upstream bug fixes. There are patches ("don't truncate and
+loose multiline..." being one of them) done as a result of a bug
+reported in RHEL, but their number is insignificant compared to the
+number of bugs reported and fixed in Fedora, the upstream bugtracker
+and other distro's bugtrackers. Actually Debian is suffering here
+becuase of the large version gap to current upstream. It makes it
+much harder to reproduce bugs, and if fixes are done, additional
+work is required in backporting. After various codebase cleanups
+and the the post-208 rewrite to use libsystemd-bus in systemd
+components, any patch which touch dbus codepaths has to be rewritten
+rather than cherry-picked to such old versions.
+
+Zbyszek
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 00:09:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 00:09:05 GMT) (full text, mbox, link).

+ +

Message #3015 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 16:07:57 -0800
+
+
Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
+> On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote:
+>> Clint Adams <clint@debian.org> writes:
+>> > On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
+>> >> or alternatively   
+>> >> 
+>> >> 4. Packages may, however, depend on a specific init system (which may
+>> >>    not be the default init) for features that are not related to daemon
+>> >>    startup. Such packages will only be installable on systems running a
+>> >>    non-default init, but are permitted in the archive.
+>> >
+>> > As loath as I am to participate in this discussion, I have to ask
+>> > if your intent is to suddenly outlaw all the packages which depend
+>> > on runit.
+>> 
+>> Are you asking me personally? No, that's not my intent. I merely think
+>> that a CTTE solution should spell out precisely to what extent a package
+>> must be compatible with the default init (i.e., if it must be fully
+>> working with the default init, or if it only has to provide daemon
+>> startup/supervision/shutdown for the default init). This is why I
+>> explicitly listed two conflicting, alternative wordings.
+>
+> There are two different kinds of dependencies: dependencies expressed in
+> package metadata, and functional dependencies (as in whether the package
+> does anything useful with another init). Your earlier wording sounds
+> like it was talking about the former ("installable") and Ian's proposal
+> definitely was (explicitly mentioning package fields), but the "fully
+> working" you use now sounds like it's about the latter.
+
+I think that if a program functionally depends on another, but the
+package does not declare this dependency, then it's a bug. So in this
+context I consider functional dependencies and package dependencies to
+be the same.
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 00:57:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Dimitri John Ledkov <xnox@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 00:57:08 GMT) (full text, mbox, link).

+ +

Message #3020 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Dimitri John Ledkov <xnox@debian.org>
+
To: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
Cc: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org, + Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 5 Jan 2014 00:54:04 +0000
+
+
On 4 January 2014 23:16, Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> wrote:
+> On Sat, Jan 04, 2014 at 06:59:46PM +0000, Dimitri John Ledkov wrote:
+>> Also it is sad that systemd upstream is actively promoting for
+>> everyone to execute runtime checks of is systemd-init pid1,...
+> This is done public systemd libraries to become NOPs if not running on
+> or not compiled for systemd, to make it easier to integrate
+> systemd-related functionality in programs portable to other
+> environments. Full original functionality can be always trivially
+> restored.
+>
+> Built-in systemd components do no such checks, and generally are
+> written with the assumption that they are using the same systemd
+> versions. (What I'm saying is quite inprecise, but because it's not
+> the main point, I don't want to go into details.)
+>
+
+So components inside systemd-source tree do not follow what's advised
+to all other projects: e.g. link or statically include sd_* helper
+files, and perform runtime checks?
+How much functionality / api is exported by libraries/dbus of systemd
+to move components out of the systemd tree and into separate projects.
+Or, what's more interesting, projects external to systemd integrating
+on the same level. E.g. in upstart, all common code is factored into
+stable-api/abi libnih, which is then free to use by anyone (e.g. event
+bridges, mount helpers, etc.) and all communication to/from upstart is
+exported via dbus IPC (on private socket or systemd dbus). If
+code-sharing is only happening by being part of the systemd codebase,
+that also increases barrier of entry. E.g. it would be benefitial for
+systemd to support hallyn's cgroupmanager (which can be used
+standalone or not).
+
+>> what's systemd version number",
+> I'm not aware of any such checks.
+>
+
+I'll find references, but I believe some components in KDE starting
+doing so upstream which has been reported to me from
+ProjectNeon/Kubuntu. I'll follow up more on that.
+Again, not sure if this is lack or shared library for logind support,
+but a lot of projects were using sd_booted() (pid1 init check) instead
+of checking for logind e.g. (access("/run/systemd/seats/", F_OK) >= 0)
+It would be easier if software that integrates with individual
+services was doing imperical checks of the services it uses, or better
+gracefully fail-over at runtime if those fail (e.g. over dbus). Also
+logind seat management seems to use "systemd" names instead of
+XDG-names (as done in other places) or like a generic name "logind".
+Looks untidy, and making DEs claim they "support or require"
+systemd-init, when infact they mean logind.
+
+
+>> granted Martin Pitt did identify this
+>> problem and fixed majority of opensource projects to check for the
+>> requested/required functionality, instead of arbitrary transitive
+>> checks of pid1. This in part enables to run systemd-logind without
+>> systemd-init as pid 1.
+>>
+>> Also which upstream are staying with? systemd upstream git history[4]
+>> has only one branch, which is linear with linear version number
+>> increments, without any stable release branches or other indications
+>> of which patches are stable (or possibly security) bugfixes.
+> git notes are used to mark backport-worthy commits. See
+> http://lists.freedesktop.org/archives/systemd-devel/2013-September/013188.html.
+> We currently mark patches as bugfixes (which includes fixes for bugs
+> present in the latest release, but not those introduced later),
+> or documentation and performance improvements.
+>
+
+Thank you for this link, I was not aware of this policy. This is the
+first time i see git-notes used for tracking bugs needed for
+stable/security/documentation, and it was hard for me to find.
+Does also mean such stable maintenance only started in September 2013?
+Or some other scheme used before that? Current debian version of
+systemd is v204, tagged in May 2013.
+
+
+>> Fedora 19 appears to be packaging patches from v204-stable branch
+>> which I can't find anywhere public.
+> It's my private branch I generate Fedora packages from [1]. It's the
+> same content as in Fedora git repos [2], but in a more convenient form
+> for me. I talked with other systemd maintainers in Fedora about making
+> it more official and public, but we haven't found the time to do it
+> yet. If it was to be useful to other people, it can certainly be done.
+>
+
+Thank you for pointing out where it is. Maybe add a URL in the spec
+file pointing to where it is? Cause I've search hard and didn't manage
+to find where it's maintained.
+(or push a mirror to github systemd projects or some other place if
+you require team commit access)
+I guess that also makes the RHEL patch series based on yours/fedora
+releases. Are there changes that are in RHEL7 and not in fedora, your
+fork, and upstream?
+
+Debian SytemD maintainers, has the ~116 fedora's stable fixes patch
+series been reviewed and decided to not be applied? What about stable
+branches from other distributions, have those been investigated?
+
+> [1] http://kawka.in.waw.pl/git/systemd/
+> [2] http://cgit.freedesktop.org/systemd/systemd/
+>
+>> Thankfully it's not a single giant patch as it's
+>> done by RedHat for their kernels, but actually git am formatted series
+>> of 116 patches[5].
+>>
+>> The diffstat between:
+>> - debian package and git v204 checkout is: 44 files, 246 +, 566 -
+>> - fedora 19-204 and v204 tarball: 102 files, 11368 +, 1366 -
+>> - rhel 7-beta-src-iso and v207 tarball: 133 files changed, 2364
+>> insertions(+), 1686 deletions(-)
+>>
+>> Which is a significant chunk of fixes. Looking at some of them, they
+>> are true gems like "don't truncate and loose multiline syslog
+>> messages" which is not fixed in Debian at the moment. Can we please
+>> not have journald by default in jessie, cause I don't want my syslog
+>> truncated?!
+>>
+>> In my opinion it is unwise to ship something into stable, ahead of
+>> upstream doing so for their support customers (RedHat Enterprise
+>> Linux).
+> I think you're overestimating the (direct) influence of Redhat on
+> system upstream bug fixes. There are patches ("don't truncate and
+> loose multiline..." being one of them) done as a result of a bug
+> reported in RHEL, but their number is insignificant compared to the
+> number of bugs reported and fixed in Fedora, the upstream bugtracker
+> and other distro's bugtrackers. Actually Debian is suffering here
+> becuase of the large version gap to current upstream. It makes it
+> much harder to reproduce bugs, and if fixes are done, additional
+> work is required in backporting. After various codebase cleanups
+> and the the post-208 rewrite to use libsystemd-bus in systemd
+> components, any patch which touch dbus codepaths has to be rewritten
+> rather than cherry-picked to such old versions.
+>
+
+This confirms that systemd is not generic across all upstreams and all
+distributions, and everyone is maintaining their own (in part
+influenced by release cadence, and well distro-specific integration)
+Having git repos, or even distro specific branches on Freedesktop.org
+would help. Since well, it's suppose to be a cross distro
+collaboration projects. I see little point in each distribution
+redoing it's own stable maintainance. A lot of debian-specific patches
+would be gone, if systemd did look up daemons based on path instead of
+hardcoded paths, but alas that has been rejected upstream. I don't see
+why we should be pointlessly moving our binaries around, or spend time
+patching all unit files (which i guess would then also be claimed as
+"not supported" by lennart). This diminishes in my view that systemd
+is a coherent / all-unifying cathedral, suitable as-is to all
+distributions.
+
+I am sorry for overestimation, my biggest worry is RHEL customer bugs
+and their fixes that are yet to come once systemd is used by those
+deployments.
+
+post-208 rewrite, is interesting, burning bridges with dbus? no
+freedesktop spec, making a dbus-like implementation which is entirely
+unportable to other operating systems (BSD, Mac OS X, Windows) makes
+it entirely unattractive to a lot of cross-platform toolkits like Qt
+or projects that currently do support those platforms. Standardizing
+on a toolkit/ecosystem marshaling (GVariant), despite not being
+political, looks odd from cross-platform point of view. Does that also
+mean that projects linking against libdbus1 cannot talk to systemd
+components native, without compat translator running on the systemd
+side?
+
+I guess I have to now study kdbus more, since once again it's pulled
+into systemd software collection without real need to do so. There I
+was to think it will just be a bi-directional async IPC method to talk
+to the kernel, instead of e.g. using syscalls / uevents.
+
+-- 
+Regards,
+
+Dimitri.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 01:21:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Dimitri John Ledkov <xnox@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 01:21:05 GMT) (full text, mbox, link).

+ +

Message #3025 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Dimitri John Ledkov <xnox@debian.org>
+
To: Nikolaus Rath <Nikolaus@rath.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 5 Jan 2014 01:16:43 +0000
+
+
On 5 January 2014 00:07, Nikolaus Rath <Nikolaus@rath.org> wrote:
+> Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
+>> On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote:
+>>> Clint Adams <clint@debian.org> writes:
+>>> > On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
+>>> >> or alternatively
+>>> >>
+>>> >> 4. Packages may, however, depend on a specific init system (which may
+>>> >>    not be the default init) for features that are not related to daemon
+>>> >>    startup. Such packages will only be installable on systems running a
+>>> >>    non-default init, but are permitted in the archive.
+>>> >
+>>> > As loath as I am to participate in this discussion, I have to ask
+>>> > if your intent is to suddenly outlaw all the packages which depend
+>>> > on runit.
+>>>
+>>> Are you asking me personally? No, that's not my intent. I merely think
+>>> that a CTTE solution should spell out precisely to what extent a package
+>>> must be compatible with the default init (i.e., if it must be fully
+>>> working with the default init, or if it only has to provide daemon
+>>> startup/supervision/shutdown for the default init). This is why I
+>>> explicitly listed two conflicting, alternative wordings.
+>>
+>> There are two different kinds of dependencies: dependencies expressed in
+>> package metadata, and functional dependencies (as in whether the package
+>> does anything useful with another init). Your earlier wording sounds
+>> like it was talking about the former ("installable") and Ian's proposal
+>> definitely was (explicitly mentioning package fields), but the "fully
+>> working" you use now sounds like it's about the latter.
+>
+> I think that if a program functionally depends on another, but the
+> package does not declare this dependency, then it's a bug. So in this
+> context I consider functional dependencies and package dependencies to
+> be the same.
+>
+
+Whilst generally a good position to hold, it would mean e.g. for
+lightdm to have "Depends: logind | consolekit" even if
+systemd-activation is used and sysv-init files are provided it
+shouldn't have Depends: sysvinit-core | systemd-sysv, since no
+packages should declare explicit dependency on an init-system, it's
+expected to have one generally. Even for systemd-ui, i'd expect it to
+show an error dialog "can't do much here".
+
+Stepping away to a satirical case, here is how gtk+3.10 looks like
+with Client Side Decorations and the new-style designed GtkHeaderBar
+in XFCE:
+https://plus.google.com/106778988568562417860/posts/TFYPgcfmj9N
+
+I don't think gnome-calculator should gain Depends:gnome-shell in this
+case when it clearly has "functional dependency" =)))
+
+-- 
+Regards,
+
+Dimitri.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 01:30:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 01:30:05 GMT) (full text, mbox, link).

+ +

Message #3030 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Dimitri John Ledkov <xnox@debian.org>
+
Cc: 727708@bugs.debian.org, Zbigniew Jędrzejewski-Szmek + <zbyszek@in.waw.pl>, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 17:26:22 -0800
+
+
Dimitri John Ledkov <xnox@debian.org> writes:
+
+> This confirms that systemd is not generic across all upstreams and all
+> distributions, and everyone is maintaining their own (in part influenced
+> by release cadence, and well distro-specific integration) Having git
+> repos, or even distro specific branches on Freedesktop.org would
+> help. Since well, it's suppose to be a cross distro collaboration
+> projects. I see little point in each distribution redoing it's own
+> stable maintainance.
+
+I'm amused by this comment given that one of the points of criticism of
+systemd prior to this (by people other than yourself, to be clear) was
+that the systemd maintainers were unwilling to apply and carry necessary
+modifications and patch the source as necessary.
+
+It seems like the systemd maintainers are going to get criticized by
+someone no matter what course of action they take.
+
+It's also worth noting that upstart in both Ubuntu and Debian carries
+non-upstream patches or cherry-picks, for entirely reasonable reasons.
+This is just something that's likely to be necessary with this sort of
+package.
+
+> A lot of debian-specific patches would be gone, if systemd did look up
+> daemons based on path instead of hardcoded paths, but alas that has been
+> rejected upstream.
+
+Because it's a horrible idea that Debian has already rejected for init
+scripts (see /etc/init.d/skeleton), and that we certainly shouldn't
+introduce when switching to a new init system.
+
+Patching upstream unit files to change paths is trivial, but even better
+would be to convince upstream to substitute in the proper path when
+building the unit file.  See the lbcd source package for an example of how
+to do this properly.  As a bonus, this means that the unit files will also
+work if the upstream package is installed from source using ./configure,
+make, and make install.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 01:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Dimitri John Ledkov <xnox@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 01:33:04 GMT) (full text, mbox, link).

+ +

Message #3035 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Dimitri John Ledkov <xnox@debian.org>
+
To: Sjoerd Simons <sjoerd@debian.org>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 5 Jan 2014 01:28:59 +0000
+
+
On 4 January 2014 23:13, Sjoerd Simons <sjoerd@debian.org> wrote:
+> On Sat, 2014-01-04 at 09:56 -0800, Russ Allbery wrote:
+>> Sjoerd Simons <sjoerd@debian.org> writes:
+>
+>> > Not having the logind interface is a lot harder to cope with and
+>> > something that will not only impact Gnome. So essentially the most
+>> > likely impact of using sysvinit _without_ a provider of the logind
+>> > interface would be a non-usable Gnome desktop (and potentially even GDM
+>> > to be unusable) on Jessie systems.
+>>
+>> If we go with systemd, I think we have three options:
+>>
+>> 1. Allow packages that require logind to depend on systemd and require
+>>    that it be used as the init system.  This is certainly the simplest for
+>>    packaging applications that want to depend on logind, as well as for
+>>    the systemd maintainers.  However, it means we lose the ability for
+>>    users of at least those packages to be able to fall back on sysvinit if
+>>    something goes wrong with systemd on their systems.  In the past, we've
+>>    tried pretty hard to provide that capability when making a disruptive
+>>    change of this kind.
+>
+> This one feels like a bit of a cost/benefit analysis to me. Is it worth
+> it to force all packages to work properly (for some definition of
+> properly) on a sysvinit system even in cases where this is a non-trivial
+> amount of work?  For e.g. daemon packages where this typically is a
+> matter of keeping/writing an  init script  the cost is obviously very
+> low, so probably worth it.
+>
+> For something like Gnome, it's a lot less obvious in my opinion.
+>
+>> 2. Package logind separately from systemd, get it working with sysvinit.
+>>    The problems with doing this, as I understand it, is that we'd not be
+>>    able to upgrade such a separately-packaged logind beyond 204 for
+>>    jessie.  I'm not sure how much impact that would have.  Also, it
+>>    sounded to me like we would need to figure out who was going to do that
+>>    work and maintain that package, including in the stable release.  If
+>>    the current systemd maintainers are not interested in doing this, we
+>>    absolutely shouldn't try to force them to do so.  Someone else would
+>>    need to step forward to do this and figure out the right package
+>>    relationships.  (Also, it would be good to maintain this separately so
+>>    that the systemd maintainers could move forward with newer versions of
+>>    systemd, including the logind built from its source.)
+>
+>> 3. Get GNOME working at some level without logind.  I think it would be
+>>    entirely acceptable for there to be some loss of functionality when
+>>    GNOME is started in this way, such as no user switching and some
+>>    configuration and control panels that rely on logind functionality not
+>>    working.  But it would need to at least start and be basically
+>>    functional for this to be a meaningful option.
+>
+> The problem with this option is how to define "some level" and
+> "basically functional".. If it's enough to be able to login, launch some
+> applications and have some basic window manager functionality that's
+> probably possible.
+>
+> However some functionality which I would find pretty basic, e.g.
+> configuring the network, suspending the machine, locking the screen
+> might not be available.
+>
+> Also, would "basic functionality" mean that if things fail they fail
+> gracefully? Given modern Gnome essentially doesn't get tested in a
+> non-systemd environment anymore I'm sure there a lots of rough edges
+> around.
+>
+>> None of these options are very appealing, but I think we have to pick one
+>> of them.  I'm not seeing other options at the moment.
+>>
+>> I think option 3 would be the most appealing for the project as a whole,
+>> but I realize that's also the option that puts the most burden on GNOME
+>> maintainers.  The only upside I can offer for that is that this would be
+>> in the context of moving forward with systemd and would be a one-release
+>> issue.  Post jessie, you'd be able to move forward with a standard
+>> integration.
+>
+>> It's worth noting that option 3 is also what would be required if we
+>> wanted to support GNOME on kFreeBSD.  I'm not sure if anyone is working on
+>> that port or sufficiently interested in it to try to make it work, but
+>> there may be some additional resources there.
+>
+> Actually for the project as a whole and for porting to KFreeBSD i would
+> find option 2 more appealing as a starting point. logind is not just
+> used by GNOME, so doing so is more generally useful. Especially for
+> KFreeBSD as it lowers the barrier for entry for all logind users.
+>
+>> Do you think there's a way that we could make option 3 work that the GNOME
+>> maintainers would be comfortable with?
+>
+> Do you think there is a way you can find someone willing to do the
+> work? :)..
+>
+> The problem with both 2 and 3 is that it's work that needs to be done
+> and maintained at least until Jessie is released. Which is work that as
+> far as I'm aware nobody in the current Gnome team is motivated to do.
+>
+> So unless someone volunteers to take up the challenge to do the required
+> work (and succeeds in doing so!), to me the options of what to do for
+> Gnome in Jessie are:
+>   0) Provide the user with a massively degraded Gnome 3 desktop
+>      experience with no/bare minimal support from the gnome
+>      maintainers when using sysvrc
+>   1) Indicate to the user that Gnome 3 is only supported when using
+>      the default init system as PID 1.
+>
+
+Imho that's a gross overstatement. Over more than a year, an Ubuntu
+GNOME team was established and became official ubuntu flavour with so
+goal and purpose of shipping GNOME3 in it's full glory. If distro
+watch is any indication they are fast growing ubuntu flavour,
+outpacing the more established ones like e.g. Xubuntu. The demand for
+such flavour is growing, with highly positive reviews from critics and
+general public. There is a group of volunteers who contribute to
+making it work. I've personally used it, and it's quite wonderful and
+capable desktop environment. I think there is some degree of heresy to
+claim that GNOME3 is only supported with systemd-init pid1. That was
+the case intermittently, until majority of pid1 checks were replaced
+by more correct ones.
+
+Even if that was the case, why should one Desktop Environment dictate
+for all Debian users what the pid1 should be? We are debating this
+decision not only on behalf of Debian developers, maintainers of
+GNOME, but ultimately on behalf of all our users. Which significantly
+includes !gnome3 and/or headless deployments.
+
+> From those I personally think option 1 is actually the better option and
+> much more honest to our users then pretending Gnome 3 works with
+> sysvinit.
+>
+>
+>> The systemd maintainers should definitely feel free to tell me if I'm
+>> misunderstanding their feelings on option 2.
+>>
+>> Do you think I should ask more generally on debian-devel if there are any
+>> other maintainers in Debian that anticipate any problem with either
+>> requiring sysvinit be supported as PID 1 for jessie, or with logind being
+>> an optional component for jessie?
+>
+> It's probably worth asking the maintainer of the other desktop
+> environments what the impact on their desktops environments is if any.
+> I'm aware that some other desktops started using logind, not sure about
+> the other systemd interfaces.
+
+logind does not require systemd-init as pid1, and that is the case at
+least to the extent of how GNOME3 is using logind.
+
+-- 
+Regards,
+
+Dimitri.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 01:33:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 01:33:07 GMT) (full text, mbox, link).

+ +

Message #3040 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Dimitri John Ledkov <xnox@debian.org>
+
Cc: 727708@bugs.debian.org, Nikolaus Rath <Nikolaus@rath.org>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 17:31:37 -0800
+
+
Dimitri John Ledkov <xnox@debian.org> writes:
+> On 5 January 2014 00:07, Nikolaus Rath <Nikolaus@rath.org> wrote:
+
+>> I think that if a program functionally depends on another, but the
+>> package does not declare this dependency, then it's a bug. So in this
+>> context I consider functional dependencies and package dependencies to
+>> be the same.
+
+> Whilst generally a good position to hold, it would mean e.g. for lightdm
+> to have "Depends: logind | consolekit" even if systemd-activation is
+> used and sysv-init files are provided it shouldn't have Depends:
+> sysvinit-core | systemd-sysv, since no packages should declare explicit
+> dependency on an init-system, it's expected to have one generally. Even
+> for systemd-ui, i'd expect it to show an error dialog "can't do much
+> here".
+
+We already have a project definition of various types of dependencies that
+we can use, namely Policy 7.2.  My guess is that everyone is okay with
+packages declaring Recommends on an init system in the sense of that
+definition.  The current debate has been about a Depends relationship in
+the sense defined in Policy, or at least that's what I think it's about.
+
+(Note that nothing in the above paragraph should be taken to mean that I
+think packages should be free to declare a Recommands in such a way that
+would cause the system's init system to be changed during an upgrade
+without coordination with the rest of the project.  That's something we
+may want to do somewhere, carefully, as part of a transition, but it's
+something we would want to plan as a project, not something that I think
+it would make sense for individual maintainers to add in isolation.  But
+there are various reasonable ways of avoiding that or coordinating it.)
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 01:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Dimitri John Ledkov <xnox@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 01:39:04 GMT) (full text, mbox, link).

+ +

Message #3045 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Dimitri John Ledkov <xnox@debian.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org, Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>, + Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 5 Jan 2014 01:37:00 +0000
+
+
On 5 January 2014 01:26, Russ Allbery <rra@debian.org> wrote:
+> Dimitri John Ledkov <xnox@debian.org> writes:
+>
+>> This confirms that systemd is not generic across all upstreams and all
+>> distributions, and everyone is maintaining their own (in part influenced
+>> by release cadence, and well distro-specific integration) Having git
+>> repos, or even distro specific branches on Freedesktop.org would
+>> help. Since well, it's suppose to be a cross distro collaboration
+>> projects. I see little point in each distribution redoing it's own
+>> stable maintainance.
+>
+> I'm amused by this comment given that one of the points of criticism of
+> systemd prior to this (by people other than yourself, to be clear) was
+> that the systemd maintainers were unwilling to apply and carry necessary
+> modifications and patch the source as necessary.
+>
+
+Oh, that's interesting. I guess I have misunderstood your opinion
+email where you hail systemd as grand unifying interface. I shall
+re-read your that email, in light of all follow ups.
+
+> It seems like the systemd maintainers are going to get criticized by
+> someone no matter what course of action they take.
+>
+> It's also worth noting that upstart in both Ubuntu and Debian carries
+> non-upstream patches or cherry-picks, for entirely reasonable reasons.
+> This is just something that's likely to be necessary with this sort of
+> package.
+>
+
+Sure, the scope and size of the two, is however, greatly different.
+
+
+>> A lot of debian-specific patches would be gone, if systemd did look up
+>> daemons based on path instead of hardcoded paths, but alas that has been
+>> rejected upstream.
+>
+> Because it's a horrible idea that Debian has already rejected for init
+> scripts (see /etc/init.d/skeleton), and that we certainly shouldn't
+> introduce when switching to a new init system.
+>
+> Patching upstream unit files to change paths is trivial, but even better
+> would be to convince upstream to substitute in the proper path when
+> building the unit file.  See the lbcd source package for an example of how
+> to do this properly.  As a bonus, this means that the unit files will also
+> work if the upstream package is installed from source using ./configure,
+> make, and make install.
+>
+
+Oh that indeed would be wonderful, why did systemd upstream advocate
+for hardcoded paths in so many projects then, instead of atleast
+runtime detected?! How is this suppose to work with 3rd party
+recompiled packages and e.g. installed in opt? previously just adding
+opt to PATH, or droppings things into /usr/local/, enabled to use
+custom compiled ad-hoc replacements as desired by deployments.
+
+-- 
+Regards,
+
+Dimitri.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 01:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 01:51:05 GMT) (full text, mbox, link).

+ +

Message #3050 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Dimitri John Ledkov <xnox@debian.org>
+
Cc: Sjoerd Simons <sjoerd@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 17:46:34 -0800
+
+
Dimitri John Ledkov <xnox@debian.org> writes:
+
+> Imho that's a gross overstatement. Over more than a year, an Ubuntu
+> GNOME team was established and became official ubuntu flavour with so
+> goal and purpose of shipping GNOME3 in it's full glory. If distro watch
+> is any indication they are fast growing ubuntu flavour, outpacing the
+> more established ones like e.g. Xubuntu. The demand for such flavour is
+> growing, with highly positive reviews from critics and general
+> public. There is a group of volunteers who contribute to making it
+> work. I've personally used it, and it's quite wonderful and capable
+> desktop environment. I think there is some degree of heresy to claim
+> that GNOME3 is only supported with systemd-init pid1. That was the case
+> intermittently, until majority of pid1 checks were replaced by more
+> correct ones.
+
+Insofar as this is evidence that it's possible to make GNOME work with
+option 2 (run logind without systemd), this is certainly valid
+information, but I think this is information that we already have.  As I
+said in my original writeup, I believe the main challenge with option 2
+for jessie is not in figuring out *how* to do the work, but in identifying
+*who* is going to do the work.  (Beyond jessie, this will require ongoing
+resources to maintain if it's not purely a transitional issue, but that's
+a somewhat separate discussion.)  And I'll note that Sjoerd said exactly
+the same thing.
+
+Saying that it's easy is fine, particularly if you have details as to why
+it's easy.  What we're not going to do is say that therefore the existing
+GNOME maintainers in Debian must do it.  That is not how we work as a
+project, and that is not how we're going to work as a project.  If they
+don't want to do the work, no one is going to force them to do it.
+
+Please instead note Steve's comments on maintaining logind as a separate
+package, which is the productive way forward and is a way to get to the
+second solution in my original message.  Volunteering to do the work and
+finding a way to do it in a minimally intrusive fashion is the way to show
+that it's straightforward.
+
+> Even if that was the case, why should one Desktop Environment dictate
+> for all Debian users what the pid1 should be? We are debating this
+> decision not only on behalf of Debian developers, maintainers of GNOME,
+> but ultimately on behalf of all our users. Which significantly includes
+> !gnome3 and/or headless deployments.
+
+I think you have gotten confused as to which part of this thread that
+you're participating in (which is understandable, given that it's a
+giant).
+
+This discussion was prompted by my question to Sjoerd about what the
+impact to GNOME would be for supporting sysvinit in jessie, and for
+supporting a configuration without logind in jessie.  That's information
+that we need to have in the Technical Committee in order to decide what
+options are reasonable to include in a discussion.  Sjoerd was responding
+to that question in his role as a current Debian GNOME maintainer based on
+his experience with the packaging and with the current GNOME code
+requirements.
+
+In other words, this discussion is specifically about GNOME because I
+*asked* for it to be specifically about GNOME, because we have some reason
+to believe it might be particularly heavily impacted.
+
+If you have a separate analysis, I also very much appreciate your comments
+and analysis.  But getting upset at him for providing his opinion is
+directly counterproductive and just makes it harder for the Technical
+Committee to do its work.  Now it's less likely that someone else with
+relevant technical knowledge will be willing to volunteer it in public,
+for fear of having someone else jump on them.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 01:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 01:57:04 GMT) (full text, mbox, link).

+ +

Message #3055 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Dimitri John Ledkov <xnox@debian.org>
+
Cc: 727708@bugs.debian.org, Zbigniew Jędrzejewski-Szmek + <zbyszek@in.waw.pl>, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 17:53:30 -0800
+
+
Dimitri John Ledkov <xnox@debian.org> writes:
+> On 5 January 2014 01:26, Russ Allbery <rra@debian.org> wrote:
+
+>> I'm amused by this comment given that one of the points of criticism of
+>> systemd prior to this (by people other than yourself, to be clear) was
+>> that the systemd maintainers were unwilling to apply and carry
+>> necessary modifications and patch the source as necessary.
+
+> Oh, that's interesting. I guess I have misunderstood your opinion email
+> where you hail systemd as grand unifying interface. I shall re-read your
+> that email, in light of all follow ups.
+
+If you think that I said systemd is a grand unifying interface, you should
+definitely re-read my email.
+
+>> It seems like the systemd maintainers are going to get criticized by
+>> someone no matter what course of action they take.
+
+>> It's also worth noting that upstart in both Ubuntu and Debian carries
+>> non-upstream patches or cherry-picks, for entirely reasonable reasons.
+>> This is just something that's likely to be necessary with this sort of
+>> package.
+
+> Sure, the scope and size of the two, is however, greatly different.
+
+My position on this is that both the upstart maintenance team in Debian
+and the systemd maintenance team in Debian are competent, respected,
+capable Debian developers, and I trust them to know how to maintain their
+packages.
+
+The pace of systemd development compared to the pace of upstart
+development is certainly something to weigh as part of the overall
+decision.  Different people can arrive at different conclusions about
+that, and I definitely respect the opinion that it's moving too fast and
+is not stable enough to adopt, although I don't share it.  But when it
+comes to the exact details of how the maintainers are going to handle
+patches and bug fixes and a release process, I see no reason not to trust
+the maintainers of both packages to do their jobs.
+
+>> Patching upstream unit files to change paths is trivial, but even
+>> better would be to convince upstream to substitute in the proper path
+>> when building the unit file.  See the lbcd source package for an
+>> example of how to do this properly.  As a bonus, this means that the
+>> unit files will also work if the upstream package is installed from
+>> source using ./configure, make, and make install.
+
+> Oh that indeed would be wonderful, why did systemd upstream advocate
+> for hardcoded paths in so many projects then, instead of atleast
+> runtime detected?! How is this suppose to work with 3rd party
+> recompiled packages and e.g. installed in opt?
+
+The approach used in the lbcd package should work with cases like that.  I
+welcome feedback on any issues I might have missed.
+
+> previously just adding opt to PATH, or droppings things into
+> /usr/local/, enabled to use custom compiled ad-hoc replacements as
+> desired by deployments.
+
+Not with init scripts in Debian it doesn't.  Go look at the existing init
+scripts and count how many use relative paths for their daemons and don't
+reset PATH at the start of the script.  I'm not just making this up.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 02:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Dimitri John Ledkov <xnox@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 02:15:04 GMT) (full text, mbox, link).

+ +

Message #3060 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Dimitri John Ledkov <xnox@debian.org>
+
To: Tollef Fog Heen <tfheen@err.no>, 727708@bugs.debian.org, debian-ctte@lists.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 5 Jan 2014 02:11:41 +0000
+
+
On 4 January 2014 19:42, Tollef Fog Heen <tfheen@err.no> wrote:
+> ]] Dimitri John Ledkov
+>
+>> Also which upstream are staying with? systemd upstream git history[4]
+>> has only one branch, which is linear with linear version number
+>> increments, without any stable release branches or other indications
+>> of which patches are stable (or possibly security) bugfixes.
+>
+> That's generally communicated in the release announcements as well as on
+> the systemd-devel mailing list.
+>
+
+having a easily accessible stable branches, as e.g. by Zbigniew
+Jędrzejewski-Szmek, would help a wider range of developers and
+sysadmins to check for bugfixes of discovered bugs.
+
+>> Fedora 19 appears to be packaging patches from v204-stable branch
+>> which I can't find anywhere public. Thankfully it's not a single giant
+>> patch as it's done by RedHat for their kernels, but actually git am
+>> formatted series of 116 patches[5].
+>
+> Were you unable to find
+> http://pkgs.fedoraproject.org/cgit/systemd.git/log/?h=f19 ?  It's where
+> Fedora has all of their packaging..
+>
+
+As explained by Zbigniew Jędrzejewski-Szmek, that is not actually
+where that happens.
+
+that is a one to one mapping with src.rpms and builds dispatched to
+Koji. I am well aware of Fedora packaging practices, and although I am
+yet to have an update/package accepted into fedora, I frequently
+monitor and cherrypick patches from Fedora for packages that I
+maintain, or bugfixes I work on.
+
+My comments were raised on inspection of that repository (or src.rpm
+which are equivalent) and spec file, to notice that a static git patch
+series is maintained from non-identified location, which I have also
+failed to locate.
+
+>> Fedora/RPM based distributions are significantly different, thus it is
+>> inevitable that we'll have to maintain a fork of systemd for best
+>> integration into Debian. This does not seem evident from the current
+>> systemd maintainers, which file bugs to disable/remove/override debian
+>> functionality and components with inferior systemd counterparts.
+>
+> Can you provide bug numbers for those allegations, please?
+>
+
+http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=716812
+
+Rejections on mailinglists and else where to split:
+/lib/systemd/systemd-multi-seat-x
+/lib/systemd/systemd-timedated
+/lib/systemd/systemd-localed
+/lib/systemd/systemd-logind
+/lib/systemd/systemd-hostnamed
+
+from systemd package to individual packages binary packages, or at
+least together but separate from systemd-init.
+
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719738 - udev "follow
+upstream" change, granted, steps have later been taken back to
+preserve backwards compat.
+
+These are just some that I have been involved in.
+
+
+>> [4] it appears that upstream git is used as packaging basis, instead
+>> of the tarball which has pre-generated documentation and loads of
+>> other files.
+>
+> If you here are talking about the systemd packaging, it seems you've
+> misunderstood something.  What are you missing in the source package?
+>
+
+I've downloaded systemd_204.orig.tar.gz from debian mirror -
+3ba441b51a390c6afc21e9a8a4811698
+And i've downloaded systemd-204.tar.xz from systemd upstream -
+a07619bb19f48164fbf0761d12fd39a8
+
+The diff between the two is http://paste.debian.net/74333/ - 477 files
+changed, 566 insertions(+), 246 deletions(-). I don't believe i'm
+missing anything in the source package, but because packaging doesn't
+seem to use debian/patches directory, does not use upstream published
+tarball, and does not have recommended get-orig-source target, it's
+very hard to see and instepect how and why upstream tarball is
+repackaged and more importantly what's changed. Even further looking
+at the git history in the declared packaging: it mixes upstream
+commits with packaging, not-rebased and not-linear, with some
+git-buildpackage features - e.g. the pristine-tar branch and commits
+of the upstream 204.orig.tar.xz, which at the end is not the tarball
+uploaded into the archive. Does this answer what I am missing in the
+source package? apart from physical files, audit trail would be a good
+start or at least following any of the practices adviced by the debian
+policy - patch target, 3.0 (quilt) format, using upstream tarballs,
+get-orig-source target if upstream tarball is not used, or after all
+that README.source explaining things...
+
+-- 
+Regards,
+
+Dimitri.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 02:21:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Dimitri John Ledkov <xnox@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 02:21:05 GMT) (full text, mbox, link).

+ +

Message #3065 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Dimitri John Ledkov <xnox@debian.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: Sjoerd Simons <sjoerd@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 5 Jan 2014 02:18:00 +0000
+
+
On 5 January 2014 01:46, Russ Allbery <rra@debian.org> wrote:
+> Dimitri John Ledkov <xnox@debian.org> writes:
+>
+>> Imho that's a gross overstatement. Over more than a year, an Ubuntu
+>> GNOME team was established and became official ubuntu flavour with so
+>> goal and purpose of shipping GNOME3 in it's full glory. If distro watch
+>> is any indication they are fast growing ubuntu flavour, outpacing the
+>> more established ones like e.g. Xubuntu. The demand for such flavour is
+>> growing, with highly positive reviews from critics and general
+>> public. There is a group of volunteers who contribute to making it
+>> work. I've personally used it, and it's quite wonderful and capable
+>> desktop environment. I think there is some degree of heresy to claim
+>> that GNOME3 is only supported with systemd-init pid1. That was the case
+>> intermittently, until majority of pid1 checks were replaced by more
+>> correct ones.
+>
+> Insofar as this is evidence that it's possible to make GNOME work with
+> option 2 (run logind without systemd), this is certainly valid
+> information, but I think this is information that we already have.  As I
+> said in my original writeup, I believe the main challenge with option 2
+> for jessie is not in figuring out *how* to do the work, but in identifying
+> *who* is going to do the work.  (Beyond jessie, this will require ongoing
+> resources to maintain if it's not purely a transitional issue, but that's
+> a somewhat separate discussion.)  And I'll note that Sjoerd said exactly
+> the same thing.
+>
+> Saying that it's easy is fine, particularly if you have details as to why
+> it's easy.  What we're not going to do is say that therefore the existing
+> GNOME maintainers in Debian must do it.  That is not how we work as a
+> project, and that is not how we're going to work as a project.  If they
+> don't want to do the work, no one is going to force them to do it.
+>
+> Please instead note Steve's comments on maintaining logind as a separate
+> package, which is the productive way forward and is a way to get to the
+> second solution in my original message.  Volunteering to do the work and
+> finding a way to do it in a minimally intrusive fashion is the way to show
+> that it's straightforward.
+>
+
+I see thanks. I guess the only relevant addition, is that there is a
+pool of self-selected developers that are working on the similar type
+of integration issues: GNOME3 with logind without systemd-init. The
+Ubuntu GNOME team (packaging team is 18 people at the moment, there
+are more in users/qa/documentation teams ~250+ people)
+https://launchpad.net/~ubuntu-gnome-packaging
+
+
+>> Even if that was the case, why should one Desktop Environment dictate
+>> for all Debian users what the pid1 should be? We are debating this
+>> decision not only on behalf of Debian developers, maintainers of GNOME,
+>> but ultimately on behalf of all our users. Which significantly includes
+>> !gnome3 and/or headless deployments.
+>
+> I think you have gotten confused as to which part of this thread that
+> you're participating in (which is understandable, given that it's a
+> giant).
+>
+> This discussion was prompted by my question to Sjoerd about what the
+> impact to GNOME would be for supporting sysvinit in jessie, and for
+> supporting a configuration without logind in jessie.  That's information
+> that we need to have in the Technical Committee in order to decide what
+> options are reasonable to include in a discussion.  Sjoerd was responding
+> to that question in his role as a current Debian GNOME maintainer based on
+> his experience with the packaging and with the current GNOME code
+> requirements.
+>
+> In other words, this discussion is specifically about GNOME because I
+> *asked* for it to be specifically about GNOME, because we have some reason
+> to believe it might be particularly heavily impacted.
+>
+> If you have a separate analysis, I also very much appreciate your comments
+> and analysis.  But getting upset at him for providing his opinion is
+> directly counterproductive and just makes it harder for the Technical
+> Committee to do its work.  Now it's less likely that someone else with
+> relevant technical knowledge will be willing to volunteer it in public,
+> for fear of having someone else jump on them.
+>
+
+I think I am confused about the giant threads, their chapters,
+sub-threads, sections, and individual emails. Sorry about that.
+
+
+-- 
+Regards,
+
+Dimitri.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 02:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 02:27:04 GMT) (full text, mbox, link).

+ +

Message #3070 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 5 Jan 2014 10:25:44 +0800
+
+
[Message part 1 (text/plain, inline)]
+
On Jan 5, 2014 2:39 AM, "Russ Allbery" <rra@debian.org> wrote:
+> I'm doubtful that either of us are going to convince the other on this
+> point.  I don't consider it comparable to the other examples you're
+> citing, and I think it's inobvious that raise(SIGSTOP) is a good technical
+> choice.  Simple, yes, but that's not the same thing.
+
+How hard would it be to write an external wrapper that converts the systemd
+style socket activation to the SIGSTOP  protocol (for upstart invoking a
+systemd compatible daemon)? Or to add support to start-stop-daemon for both
+protocols so a reliable sysv style script is trivial for more modern
+daemons?
+
+Cheers,
+aj
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 02:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 02:33:04 GMT) (full text, mbox, link).

+ +

Message #3075 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Dimitri John Ledkov <xnox@debian.org>
+
Cc: 727708@bugs.debian.org, Sjoerd Simons <sjoerd@debian.org>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 18:28:46 -0800
+
+
Dimitri John Ledkov <xnox@debian.org> writes:
+
+> I see thanks. I guess the only relevant addition, is that there is a
+> pool of self-selected developers that are working on the similar type of
+> integration issues: GNOME3 with logind without systemd-init. The Ubuntu
+> GNOME team (packaging team is 18 people at the moment, there are more in
+> users/qa/documentation teams ~250+ people)
+> https://launchpad.net/~ubuntu-gnome-packaging
+
+I suspect the Debian GNOME team would love to have that many active
+developers doing anything.  :)
+
+> I think I am confused about the giant threads, their chapters,
+> sub-threads, sections, and individual emails. Sorry about that.
+
+That was very gracious.  Thank you.  And it's partly my fault.  I really
+should have changed the Subject header.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 02:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 02:45:04 GMT) (full text, mbox, link).

+ +

Message #3080 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Anthony Towns <aj@erisian.com.au>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 18:40:51 -0800
+
+
Anthony Towns <aj@erisian.com.au> writes:
+> On Jan 5, 2014 2:39 AM, "Russ Allbery" <rra@debian.org> wrote:
+
+>> I'm doubtful that either of us are going to convince the other on this
+>> point.  I don't consider it comparable to the other examples you're
+>> citing, and I think it's inobvious that raise(SIGSTOP) is a good
+>> technical choice.  Simple, yes, but that's not the same thing.
+
+> How hard would it be to write an external wrapper that converts the
+> systemd style socket activation to the SIGSTOP protocol (for upstart
+> invoking a systemd compatible daemon)?
+
+The wrapper would need to stay running for the life of the daemon, since
+it would be the PID that the init system would track.  That has some
+drawbacks.  For example, it would need to carefully pass signals along to
+its child process.  I've written code like that before, and it mostly
+works for me, but I've not hammered on it very hard.
+
+Although, hm... actually, maybe it wouldn't need to stay running for the
+life of the daemon if it's sufficiently devious.  The wrapper could fork
+and then exec the daemon in the *parent*, and have the *child* listen for
+the notification message and then kill(SIGSTOP) its parent and immediately
+exit.  I wonder if that would actually work....
+
+Apart from that, it would need some UNIX socket (or abstract namespace
+socket) code, but I don't think it's anything particularly complicated.
+
+> Or to add support to start-stop-daemon for both protocols so a reliable
+> sysv style script is trivial for more modern daemons?
+
+The hard part for more general support would be socket activation,
+particularly where you would put the configuration for how to create and
+bind the sockets.  See:
+
+    http://www.freedesktop.org/software/systemd/man/systemd.socket.html
+
+for an idea of what configuration parameters you'd need to support and
+that would need to be adjustable by the local systems administrator.  Some
+of those are not broadly useful or are addressing some specific edge
+cases, but at least with networking sockets it's useful to have control
+over a surprisingly large number of different parameters.
+
+For just the notification part, it would probably be something one would
+build on top of start-stop-daemon's -b support.  It should be possible to
+address the documented weakness of -b, and it should be doable, but it's a
+bit more complicated.  Essentially, start-stop-daemon would need to
+implement not only the server side of the notification protocols (the
+waitpid and kill(SIGCONT), plus the UNIX socket stuff), but also
+separately be able to do much of the stuff described in the first section
+of:
+
+    http://www.freedesktop.org/software/systemd/man/daemon.html
+
+I do disagree mildly with that documentation in a few places -- I'm
+dubious about changing umask, in particular -- but it's a pretty good
+summary of proper behavior for a fork and exit daemon.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 03:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Charles Plessy <plessy@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 03:09:04 GMT) (full text, mbox, link).

+ +

Message #3085 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Charles Plessy <plessy@debian.org>
+
To: Dimitri John Ledkov <xnox@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 5 Jan 2014 12:09:29 +0900
+
+
Le Sun, Jan 05, 2014 at 02:11:41AM +0000, Dimitri John Ledkov a écrit :
+> 
+> at least following any of the practices adviced by the debian policy - patch
+> target, 3.0 (quilt) format
+
+Dear Dimitri,
+
+the Debian Policy does not recommend one source format over another.
+
+Have a nice day,
+
+-- 
+Charles Plessy
+Tsurumi, Kanagawa, Japan
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 03:51:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 03:51:08 GMT) (full text, mbox, link).

+ +

Message #3090 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 5 Jan 2014 11:47:35 +0800
+
+
[Message part 1 (text/plain, inline)]
+
On Jan 5, 2014 10:40 AM, "Russ Allbery" <rra@debian.org> wrote:
+> Anthony Towns <aj@erisian.com.au> writes:
+> > How hard would it be to write an external wrapper that converts the
+> > systemd style socket activation to the SIGSTOP protocol (for upstart
+> > invoking a systemd compatible daemon)?
+
+On second thoughts, I think I meant this the other way around - systemd
+invoking an upstart compatible daemon, since it seems like upstart is more
+likely to support the systemd socket activation protocol than systemd is to
+support upstart's SIGSTOP  protocol.
+
+> The wrapper could fork
+> and then exec the daemon in the *parent*, and have the *child* listen for
+> the notification message and then kill(SIGSTOP) its parent and immediately
+> exit.  I wonder if that would actually work....
+
+Nice :)
+
+Cheers,
+aj
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 03:54:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 03:54:05 GMT) (full text, mbox, link).

+ +

Message #3095 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Anthony Towns <aj@erisian.com.au>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 19:50:45 -0800
+
+
Anthony Towns <aj@erisian.com.au> writes:
+> On Jan 5, 2014 10:40 AM, "Russ Allbery" <rra@debian.org> wrote:
+>> Anthony Towns <aj@erisian.com.au> writes:
+
+>>> How hard would it be to write an external wrapper that converts the
+>>> systemd style socket activation to the SIGSTOP protocol (for upstart
+>>> invoking a systemd compatible daemon)?
+
+> On second thoughts, I think I meant this the other way around - systemd
+> invoking an upstart compatible daemon, since it seems like upstart is
+> more likely to support the systemd socket activation protocol than
+> systemd is to support upstart's SIGSTOP protocol.
+
+This, sadly, is slightly harder, since you can't use this hack:
+
+>> The wrapper could fork and then exec the daemon in the *parent*, and
+>> have the *child* listen for the notification message and then
+>> kill(SIGSTOP) its parent and immediately exit.  I wonder if that would
+>> actually work....
+
+because the child can't waitpid its parent and get notified when the
+parent stops.  So the compatibility wrapper would have to stick around for
+the lifetime of the daemon and pass signals and the like, and I'm not sure
+what gotchas would be involved in that.  But it's probably doable.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 04:03:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 04:03:05 GMT) (full text, mbox, link).

+ +

Message #3100 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Cc: Anthony Towns <aj@erisian.com.au>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sat, 04 Jan 2014 19:58:35 -0800
+
+
Russ Allbery <rra@debian.org> writes:
+
+> This, sadly, is slightly harder, since you can't use this hack:
+
+>>> The wrapper could fork and then exec the daemon in the *parent*, and
+>>> have the *child* listen for the notification message and then
+>>> kill(SIGSTOP) its parent and immediately exit.  I wonder if that would
+>>> actually work....
+
+> because the child can't waitpid its parent and get notified when the
+> parent stops.  So the compatibility wrapper would have to stick around
+> for the lifetime of the daemon and pass signals and the like, and I'm
+> not sure what gotchas would be involved in that.  But it's probably
+> doable.
+
+(Why can't I have brainstorms *while* I'm writing mail instead of
+subjecting everyone to more mail?)
+
+Oh, hm, actually... the systemd notification protocol allows you to tell
+systemd what the actual PID of the process to manage is, using the MAINPID
+variable.  So I think you actually could write a wrapper that starts the
+actual daemon as a child, waits for it to stop using waitpid, sends it
+SIGCONT, tells systemd that it's ready along with passing MAINPID pointing
+to the child process, and then exits.
+
+I'd have to try that to see if it would actually work, but I bet it would,
+and it would be a fairly easy program to write since you can just use
+libsystemd-daemon and don't have to write any of the socket code.
+
+There are probably still some gotchas to sort out, such as signals
+received before the child process signals readiness and how to handle
+them, but I think that's all doable.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 04:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 04:12:05 GMT) (full text, mbox, link).

+ +

Message #3105 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: Dimitri John Ledkov <xnox@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 5 Jan 2014 05:09:39 +0100
+
+
On Sun, Jan 05, 2014 at 12:54:04AM +0000, Dimitri John Ledkov wrote:
+> So components inside systemd-source tree do not follow what's advised
+> to all other projects: e.g. link or statically include sd_* helper
+> files, and perform runtime checks?
+The advice for other projects assumes that systemd is
+optional. systemd components assume that they will be installed as
+part of systemd, so such compile time checks would make little sense.
+Various configure swithes can be used to disable components, but not
+the main "systemd" part.
+
+> How much functionality / api is exported by libraries/dbus of systemd
+> to move components out of the systemd tree and into separate projects.
+systemd components share the same codebase, and they all make
+extensive use of shared functionality (src/shared part in the source
+tree, but not only there) which has does not have any stable external
+API. So it's not possible to "move out" any of them in any practical
+sense. This is a bit like with the kernel.
+
+> Or, what's more interesting, projects external to systemd integrating
+> on the same level. E.g. in upstart, all common code is factored into
+> stable-api/abi libnih, which is then free to use by anyone (e.g. event
+> bridges, mount helpers, etc.) and all communication to/from upstart is
+> exported via dbus IPC (on private socket or systemd dbus). If
+> code-sharing is only happening by being part of the systemd codebase,
+> that also increases barrier of entry. 
+In systemd most of the D-Bus interface, share-library interface,
+and various other APIs are stable, but the internal C API is not. It
+simply changes too fast and it is not possible to make it public.
+
+> E.g. it would be benefitial for systemd to support hallyn's
+> cgroupmanager (which can be used standalone or not).
+I'm not really an expert in this area, so please don't take my words
+as authoritiative, but... No, it wouldn't. systemd (the binary running
+as PID 1) uses cgroup functionality extensively. If it was to become
+external (in a seperate process) some sort of of synchronous protocol
+would have to be used, complicating things immensly, for no gain. If
+it was to be used as a library, that is in theory possible, but we
+would replace working code with something external and not even
+working at this point. Also cgmanager is supposed to follow a
+different philosophy.
+
+> >> Also which upstream are staying with? systemd upstream git history[4]
+> >> has only one branch, which is linear with linear version number
+> >> increments, without any stable release branches or other indications
+> >> of which patches are stable (or possibly security) bugfixes.
+> > git notes are used to mark backport-worthy commits. See
+> > http://lists.freedesktop.org/archives/systemd-devel/2013-September/013188.html.
+> > We currently mark patches as bugfixes (which includes fixes for bugs
+> > present in the latest release, but not those introduced later),
+> > or documentation and performance improvements.
+> >
+> 
+> Thank you for this link, I was not aware of this policy. This is the
+> first time i see git-notes used for tracking bugs needed for
+> stable/security/documentation, and it was hard for me to find.
+> Does also mean such stable maintenance only started in September 2013?
+> Or some other scheme used before that? Current debian version of
+> systemd is v204, tagged in May 2013.
+In this form, yes.
+
+> >> Fedora 19 appears to be packaging patches from v204-stable branch
+> >> which I can't find anywhere public.
+> > It's my private branch I generate Fedora packages from [1]. It's the
+> > same content as in Fedora git repos [2], but in a more convenient form
+> > for me. I talked with other systemd maintainers in Fedora about making
+> > it more official and public, but we haven't found the time to do it
+> > yet. If it was to be useful to other people, it can certainly be done.
+> >
+> 
+> Thank you for pointing out where it is. Maybe add a URL in the spec
+> file pointing to where it is? Cause I've search hard and didn't manage
+> to find where it's maintained.
+> (or push a mirror to github systemd projects or some other place if
+> you require team commit access)
+Either that, or fedorahosted, or the upstream... We'll have to pick something,
+yes.
+
+> I guess that also makes the RHEL patch series based on yours/fedora
+> releases. Are there changes that are in RHEL7 and not in fedora, your
+> fork, and upstream?
+AFAIK, access to RHEL source code would require a subscription. I don't
+know what RHEL packages include, sorry.
+
+> Debian SytemD maintainers, has the ~116 fedora's stable fixes patch
+> series been reviewed and decided to not be applied? What about stable
+> branches from other distributions, have those been investigated?
+Normally maintainers from various distros (including Fedora and Debian)
+upstream all bugfix patches. So pulling from upstream is enough.
+
+> >> In my opinion it is unwise to ship something into stable, ahead of
+> >> upstream doing so for their support customers (RedHat Enterprise
+> >> Linux).
+> > I think you're overestimating the (direct) influence of Redhat on
+> > system upstream bug fixes. There are patches ("don't truncate and
+> > loose multiline..." being one of them) done as a result of a bug
+> > reported in RHEL, but their number is insignificant compared to the
+> > number of bugs reported and fixed in Fedora, the upstream bugtracker
+> > and other distro's bugtrackers. Actually Debian is suffering here
+> > becuase of the large version gap to current upstream. It makes it
+> > much harder to reproduce bugs, and if fixes are done, additional
+> > work is required in backporting. After various codebase cleanups
+> > and the the post-208 rewrite to use libsystemd-bus in systemd
+> > components, any patch which touch dbus codepaths has to be rewritten
+> > rather than cherry-picked to such old versions.
+> >
+> 
+> This confirms that systemd is not generic across all upstreams and all
+> distributions, and everyone is maintaining their own (in part
+> influenced by release cadence, and well distro-specific integration)
+> Having git repos, or even distro specific branches on Freedesktop.org
+> would help. Since well, it's suppose to be a cross distro
+> collaboration projects. I see little point in each distribution
+> redoing it's own stable maintainance.
+AFAIK, apart from patches which are non applicable for upstream, all
+distributions basically pick some release of systemd and cherry-pick a
+subset of bugfix and feature patches. This depends on the release
+cadence and stability policies of those distributions. E.g. Arch
+packages the latest git, Fedora usually the latest systemd release at
+the time that that Fedora version was released, etc. Nobody ever said
+that the same systemd version should be used everywhere. What is
+shared, are the unit files, systemd support in other software, and
+administrator knowledge. The fact that different distributions have
+different systemd versions (and also slightly different bugs), doesn't
+change that, it seems completely natural to me.
+
+That said, I'm all for improving cross-distro collaboration on
+systemd. I'm sure that if Debian picks systemd as the default, it will
+be beneficial to both sides.
+
+> A lot of debian-specific patches
+> would be gone, if systemd did look up daemons based on path instead of
+> hardcoded paths, but alas that has been rejected upstream. I don't see
+> why we should be pointlessly moving our binaries around, or spend time
+> patching all unit files (which i guess would then also be claimed as
+> "not supported" by lennart). This diminishes in my view that systemd
+> is a coherent / all-unifying cathedral, suitable as-is to all
+> distributions.
+>
+> I am sorry for overestimation, my biggest worry is RHEL customer bugs
+> and their fixes that are yet to come once systemd is used by those
+> deployments.
+"lennart", by which you mean Lennart Poettering I guess, does not
+provide support for Debian, Debian maintainers do. Even in Fedora,
+Lennart Poettering doesn't write unit files, individual packagers do.
+Anyway, the $PATH issue is rather minor, and you're trying to make
+it into something fundamental.
+
+I hope you don't want to limit Debian to things done by Redhat and
+well tested by their customers. The upstream git is where development
+and bugfixes happen (no CLA :), no fuss). 
+
+[Quoting Russ Albery:]
+> Patching upstream unit files to change paths is trivial, but even better
+> would be to convince upstream to substitute in the proper path when
+> building the unit file. 
+Exactly. This is what systemd does when with its own unit files.
+See [1] for an example.
+
+[1] http://cgit.freedesktop.org/systemd/systemd/tree/units/console-shell.service.m4.in?id=HEAD
+
+> post-208 rewrite, is interesting, burning bridges with dbus? no
+> freedesktop spec, making a dbus-like implementation which is entirely
+> unportable to other operating systems (BSD, Mac OS X, Windows) makes
+> it entirely unattractive to a lot of cross-platform toolkits like Qt
+> or projects that currently do support those platforms. Standardizing
+> on a toolkit/ecosystem marshaling (GVariant), despite not being
+> political, looks odd from cross-platform point of view. Does that also
+> mean that projects linking against libdbus1 cannot talk to systemd
+> components native, without compat translator running on the systemd
+> side?
+> 
+> I guess I have to now study kdbus more, since once again it's pulled
+> into systemd software collection without real need to do so. There I
+> was to think it will just be a bi-directional async IPC method to talk
+> to the kernel, instead of e.g. using syscalls / uevents.
+The fact that systemd switches D-Bus libraries internally should be
+mostly invisible fromt he outside. Bridges to D-Bus are not burned,
+even with kdbus, since existing D-Bus clients still work and a
+translator is provided. Other D-Bus libraries might implement native
+kdbus support, but this is not crucial for anything.
+kdbus is Linux specific, but as it was stated many times, systemd uses
+Linux specific functionality where it is useful. Contrary to what you
+write, there are good reasons for kdbus.
+
+Zbyszek
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 04:24:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 04:24:05 GMT) (full text, mbox, link).

+ +

Message #3110 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: Dimitri John Ledkov <xnox@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 5 Jan 2014 05:21:24 +0100
+
+
On Sun, Jan 05, 2014 at 02:11:41AM +0000, Dimitri John Ledkov wrote:
+> > Were you unable to find
+> > http://pkgs.fedoraproject.org/cgit/systemd.git/log/?h=f19 ?  It's where
+> > Fedora has all of their packaging..
+>
+> As explained by Zbigniew Jędrzejewski-Szmek, that is not actually
+> where that happens.
+Hm, I was trying to explain that it *is* where it happens.
+The only difference is that in the Fedora package those commits are
+serialized as diffs, and my git tree has them as a, well, git tree.
+
+That git repo is "undiclosed" only because it isn't particarly important.
+
+Zbyszek
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 09:30:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 09:30:05 GMT) (full text, mbox, link).

+ +

Message #3115 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 05 Jan 2014 10:27:38 +0100
+
+
]] Dimitri John Ledkov 
+
+> >> Fedora/RPM based distributions are significantly different, thus it is
+> >> inevitable that we'll have to maintain a fork of systemd for best
+> >> integration into Debian. This does not seem evident from the current
+> >> systemd maintainers, which file bugs to disable/remove/override debian
+> >> functionality and components with inferior systemd counterparts.
+> >
+> > Can you provide bug numbers for those allegations, please?
+> >
+> 
+> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=716812
+
+Not sure why you mention this.  It's filed by a user, not anybody who's
+maintaining systemd.
+
+> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719738 - udev "follow
+> upstream" change, granted, steps have later been taken back to
+> preserve backwards compat.
+
+Not sure how «please enable upstream functionality so lvm2 doesn't hold
+up the boot» becomes «disable/remove/override debian functionality with
+inferior systemd counterparts».  Josh explains this pretty adequately in
+his mail.
+
+> I've downloaded systemd_204.orig.tar.gz from debian mirror -
+> 3ba441b51a390c6afc21e9a8a4811698
+> And i've downloaded systemd-204.tar.xz from systemd upstream -
+> a07619bb19f48164fbf0761d12fd39a8
+
+Ah, it seems like the last upload was done wrongly somehow.  I'll see
+what we can do to fix that.  As you can see if you browse your local
+mirror, there's a .tar.xz there too with a hash that matches upstream.
+Thanks for noticing this.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 10:06:22 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sjoerd Simons <sjoerd@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 10:06:22 GMT) (full text, mbox, link).

+ +

Message #3120 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sjoerd Simons <sjoerd@debian.org>
+
To: Dimitri John Ledkov <xnox@debian.org>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 05 Jan 2014 11:05:08 +0100
+
+
On Sun, 2014-01-05 at 02:18 +0000, Dimitri John Ledkov wrote:
+> On 5 January 2014 01:46, Russ Allbery <rra@debian.org> wrote:
+> > Dimitri John Ledkov <xnox@debian.org> writes:
+> >
+> >> Imho that's a gross overstatement. Over more than a year, an Ubuntu
+> >> GNOME team was established and became official ubuntu flavour with so
+> >> goal and purpose of shipping GNOME3 in it's full glory. If distro watch
+> >> is any indication they are fast growing ubuntu flavour, outpacing the
+> >> more established ones like e.g. Xubuntu. The demand for such flavour is
+> >> growing, with highly positive reviews from critics and general
+> >> public. There is a group of volunteers who contribute to making it
+> >> work. I've personally used it, and it's quite wonderful and capable
+> >> desktop environment. I think there is some degree of heresy to claim
+> >> that GNOME3 is only supported with systemd-init pid1. That was the case
+> >> intermittently, until majority of pid1 checks were replaced by more
+> >> correct ones.
+> >
+> > Insofar as this is evidence that it's possible to make GNOME work with
+> > option 2 (run logind without systemd), this is certainly valid
+> > information, but I think this is information that we already have.  As I
+> > said in my original writeup, I believe the main challenge with option 2
+> > for jessie is not in figuring out *how* to do the work, but in identifying
+> > *who* is going to do the work.  (Beyond jessie, this will require ongoing
+> > resources to maintain if it's not purely a transitional issue, but that's
+> > a somewhat separate discussion.)  And I'll note that Sjoerd said exactly
+> > the same thing.
+> >
+> > Saying that it's easy is fine, particularly if you have details as to why
+> > it's easy.  What we're not going to do is say that therefore the existing
+> > GNOME maintainers in Debian must do it.  That is not how we work as a
+> > project, and that is not how we're going to work as a project.  If they
+> > don't want to do the work, no one is going to force them to do it.
+> >
+> > Please instead note Steve's comments on maintaining logind as a separate
+> > package, which is the productive way forward and is a way to get to the
+> > second solution in my original message.  Volunteering to do the work and
+> > finding a way to do it in a minimally intrusive fashion is the way to show
+> > that it's straightforward.
+> >
+> 
+> I see thanks. I guess the only relevant addition, is that there is a
+> pool of self-selected developers that are working on the similar type
+> of integration issues: GNOME3 with logind without systemd-init. The
+> Ubuntu GNOME team (packaging team is 18 people at the moment, there
+> are more in users/qa/documentation teams ~250+ people)
+> https://launchpad.net/~ubuntu-gnome-packaging
+
+I think as the Debian gnome team we've got a  pretty good working
+relationship with some developers in that team, (with some developers
+even contributing directly to both teams! Which is great). So I'm well
+aware of its existance.
+
+Maybe just to clarify a bit more, _most_ of my statement was about the
+case where we would _not_ have systemd-logind available at all unless
+the default init system is PID 1. If it is available in some form it's a
+quite different story from an integration point of view, which Ubuntu
+and the Ubuntu gnome team prove. That's why i started my earlier reply
+in this thread by saying that it boils down to whether we can rely on
+systemd-logind  being available :)
+
+
+However there is a second important difference here, which i think is
+worth highlighting. In the Ubuntu Gnome team, the system configuration
+that team supports may not be what upstream Gnome supports but it is the
+default Ubuntu configuration which is what all "Ubuntu Gnome" users
+actually use. So that team can focus on polishing purely that one setup.
+
+In this case the question is  not about supporting Debians defaults
+configuration, but _additionally_ supporting a fallback configuration
+which hopefully only a very very small amount of users are forced to
+use. In the case logind can be assumed, I'm reasonably confident we can
+provide an at least somewhat functionally Gnome 3 for these users.
+However, we most likely wouldn't go to the effort of making it fully
+functional simply because it's both a corner case and missing someone
+willing to do that job & test it & maintain it.
+
+
+-- 
+Sjoerd Simons <sjoerd@debian.org>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 11:21:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Didier 'OdyX' Raboud" <odyx@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 11:21:05 GMT) (full text, mbox, link).

+ +

Message #3125 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Didier 'OdyX' Raboud" <odyx@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 05 Jan 2014 12:19:54 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Le samedi, 4 janvier 2014, 19.10:21 Josh Triplett a écrit :
+> Dimitri John Ledkov wrote:
+> > Rejections on mailinglists and else where to split:
+> > /lib/systemd/systemd-multi-seat-x
+> > /lib/systemd/systemd-timedated
+> > /lib/systemd/systemd-localed
+> > /lib/systemd/systemd-logind
+> > /lib/systemd/systemd-hostnamed
+> > 
+> > from systemd package to individual packages binary packages, or at
+> > least together but separate from systemd-init.
+> 
+> Based on the most recent mailing list discussions, it sounds like the
+> concern there is not "whether to split" but "who will do the work of
+> maintaining the patches needed to make these run without systemd",
+> since there's no point in splitting them otherwise.
+
+I think splitting these in different binary packages would make some 
+sense anyway, even without them being ready to work without systemd 
+(given that the reverse is true; that systemd works without each of 
+them): it would allow packages (functionally) depending on a particular 
+systemd interface (such as -logind, or -hostnamed, etc) to (packaging-
+wise) depend on the exact packages providing these, bringing more 
+granularity and clarity to the "$package depends on systemd" by 
+expressing which interfaces are concretely needed for each package.
+
+( Then, until these are made to work without systemd, they would of
+  course depend on the systemd package. This would also only bring on
+  people's systems the systemd sub-parts that are actually needed for
+  their setup. )
+
+What I don't know is whether systemd is ready (or can easily be made 
+ready) to work without some of these services.
+
+Cheers,
+OdyX
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 13:51:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 13:51:09 GMT) (full text, mbox, link).

+ +

Message #3130 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Dimitri John Ledkov <xnox@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 05 Jan 2014 14:48:24 +0100
+
+
Le dimanche 05 janvier 2014 à 01:37 +0000, Dimitri John Ledkov a écrit :
+> > Patching upstream unit files to change paths is trivial, but even better
+> > would be to convince upstream to substitute in the proper path when
+> > building the unit file.
+
+> Oh that indeed would be wonderful, why did systemd upstream advocate
+> for hardcoded paths in so many projects then, instead of atleast
+> runtime detected?! How is this suppose to work with 3rd party
+> recompiled packages and e.g. installed in opt? previously just adding
+> opt to PATH, or droppings things into /usr/local/, enabled to use
+> custom compiled ad-hoc replacements as desired by deployments.
+
+blah.service.in:
+ExecStart=@bindir@/blah --no-fork
+
+How complicated is that?
+
+-- 
+.''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 15:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andrew Shadura <andrew@shadura.me>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 15:33:05 GMT) (full text, mbox, link).

+ +

Message #3135 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andrew Shadura <andrew@shadura.me>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 5 Jan 2014 16:31:44 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Hello,
+
+On Sat, 04 Jan 2014 16:46:28 +0100
+Josselin Mouette <joss@debian.org> wrote:
+
+> > I think systemd-ui is part of the systemd init system so falls into
+> > the exception.  Of course that means that nothing else should depend
+> > (functionally or in package dependencies) on it.
+
+> There is no way that, for example, some of the GNOME control center
+> applets will work at all without systemd.
+
+Last time I tried GNOME 3 it worked without any systemd components at
+all.
+
+> It is already hard enough to imagine that we would have to ship
+> packages without the appropriate dependencies on systemd; expecting
+> them to have the same functional coverage without it is simply insane.
+
+There's no bloody way it's true, claiming anything like that is
+actually insanity.
+
+-- 
+Cheers,
+  Andrew
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 16:12:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 16:12:04 GMT) (full text, mbox, link).

+ +

Message #3140 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 5 Jan 2014 16:09:02 +0000
+
+
Josh Triplett writes ("Bug#727708: init system discussion status"):
+> I don't subscribe to debian-ctte@; I read it via the list archives.
+> I've been replying using the "Reply to:" links at the bottom of mails,
+> and then manually copying and quoting the responses.  Those links reply
+> to debian-ctte@lists.debian.org, so unless I manually edit the
+> destination (which I've done in a few cases where the destination was a
+> bug report), it ends up going to the list.
+> 
+> It'd be nice if those links paid attention to the
+> To/Cc/Reply-To/Mail-Followup-To addresses, and otherwise acted like
+> hitting the reply key in a mail client.  I'd also add my voice to the
+> set of people who have requested mbox archives in the past.
+
+mbox archives of bugs are available, if that's any use.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 05 Jan 2014 18:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Simon McVittie <smcv@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 05 Jan 2014 18:12:05 GMT) (full text, mbox, link).

+ +

Message #3145 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Simon McVittie <smcv@debian.org>
+
To: Dimitri John Ledkov <xnox@debian.org>, 727708@bugs.debian.org
+
Cc: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>, + Josselin Mouette <joss@debian.org>, + Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 5 Jan 2014 18:09:46 +0000
+
+
On Sun, 05 Jan 2014 at 00:54:04 +0000, Dimitri John Ledkov wrote:
+> post-208 rewrite, is interesting, burning bridges with dbus?
+
+As in all emails I write about this, I'm trying to be consistent about
+spelling the abstract specification "D-Bus" and its oddly-licensed
+reference implementation "dbus". I am a D-Bus and dbus maintainer.
+
+libsystemd-bus is not, in itself, something that burns any bridges with
+traditional D-Bus. It's a reimplementation of dbus (D-Bus' reference
+implementation) under a less bizarre license[1] (and probably a nicer
+C API too), taking advantage of Linuxisms to be more concise and probably
+more correct (whereas dbus is portable, with all the usual costs of
+portability, like large chunks of #ifdef'd socket-wrangling code that haven't
+actually worked for several years).
+
+kdbus is a new, non-standardized, Linux-kernel-assisted transport for D-Bus,
+supported by libsystemd-bus and by unmerged branches of GDBus and dbus.
+I'm trying to make sure that it gets proper design/code review from
+experienced D-Bus (and dbus) developers, and is added to the D-Bus
+Specification. If you are interested in this, please join the D-Bus
+upstream mailing list/bug tracker (and if you see discussion elsewhere
+that should go to D-Bus' upstream locations, please direct it there).
+
+If I maintained systemd, I would personally not have merged any kdbus
+support into the master branch yet - I don't think it's ready for that -
+but systemd upstream have chosen to include it in a deactivated state.
+I'm not sure whether it's #ifdef'd out by default, or just not usable
+on unmodified kernels, but either way, systemd on current kernels
+(without either a patch or an out-of-tree module) doesn't and can't use it.
+
+> Standardizing
+> on a toolkit/ecosystem marshaling (GVariant), despite not being
+> political, looks odd from cross-platform point of view.
+
+D-Bus' marshalling is sufficiently weird that I can understand why
+the kdbus developers want to use traditional D-Bus -> kdbus as a "flag day"
+for switching to different marshalling - at the moment the plan seems
+to be to say "traditional D-Bus over a socket always uses
+D-Bus 1.0 marshalling, kdbus always uses GVariant marshalling" rather
+than making them orthogonal, to have fewer combinations that need to be
+tested. If GVariant's marshalling is better than D-Bus' (I haven't
+researched it myself, but I can well believe that it is), then it seems
+fine to use that, rather than inventing some third thing for the
+sake of neutrality.
+
+> Does that also
+> mean that projects linking against libdbus1 cannot talk to systemd
+> components native, without compat translator running on the systemd
+> side?
+
+At the moment: no, systemd still speaks the traditional D-Bus protocol
+via a socket to dbus-daemon.
+
+If/when kdbus is in the kernel and libsystemd-bus, but not dbus: yes,
+the plan seems to be that systemd will to provide a bridge that replaces
+dbus-daemon, for compatibility with current D-Bus implementations.
+
+If/when a kdbus transport is added to dbus too (one exists in a branch/fork,
+but has not been submitted upstream): no, libdbus1 (part of dbus) can use
+that transport.
+
+    S
+
+[1] dbus is dual GPL/AFL and cannot be relicensed to (say) MIT or LGPL,
+because one significant early copyright holder has gone out of business
+and it isn't clear who owns that part of the copyright now
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 10 Jan 2014 01:03:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 10 Jan 2014 01:03:10 GMT) (full text, mbox, link).

+ +

Message #3150 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: 727708@bugs.debian.org
+
Cc: Steve Langasek <vorlon@debian.org>, Colin Watson <cjwatson@debian.org>, Dimitri John Ledkov <xnox@debian.org>
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Thu, 09 Jan 2014 17:00:38 -0800
+
+
Hello,
+
+I am aware that this bug already has a lot of emails in it, but I think
+the issue below is important enough to warrant a
+
+*ping*
+
+to the upstart developers. It would be great if someone could comment on
+this.
+
+Best
+Nikolaus
+
+
+Nikolaus Rath <Nikolaus@rath.org> writes:
+> Cameron Norman <camerontnorman@gmail.com> writes:
+>> On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath <Nikolaus@rath.org> wrote:
+>>> Colin Watson <cjwatson@debian.org> writes:
+>>> > The criticisms of Upstart's event model in the systemd position
+>>> > statement simply do not make sense to me.  Events model how things
+>>> > actually happen in reality; dependencies are artificial constructions on
+>>> > top of them, and making them work requires the plethora of different
+>>> > directives in systemd (e.g. Wants, which is sort of a non-depending
+>>> > dependency) to avoid blocking the boot process on a single failing
+>>> > service.  Yes, there are some bugs possible in the Upstart design, but I
+>>> > don't agree that those are world-ending fundamental issues and I think
+>>> > they're generally incrementally fixable.  The systemd design appears to
+>>> > me to expose far more complexity to the user writing unit files, and I
+>>> > think it's important that their mental model be as straightforward as
+>>> > possible.
+>>> >
+>>> > (Now, I've been working with Upstart's model for years, and it's now a
+>>> > pretty fundamental way of how I think of system operation; so if people
+>>> > who are new to *both* models rather than partisans of one side or the
+>>> > other consistently tell me that the systemd model is easier to grasp,
+>>> > then I'll listen.)
+>>>
+>>> For what it's worth, I consider myself new to both the upstart and the
+>>> systemd model, and for me the upstart event model has been pretty much
+>>> the only reason to prefer systemd over upstart (though after reading
+>>> Russ' opinion, that has changed a bit).
+>>>
+>>> For me, upstart was actually the reason for me switching from Debian to
+>>> Ubuntu for a while. I am less familiar with systemd, so it may well be
+>>> that I underestimate the complexities of the systemd model. However, I
+>>> am very certain in my dislike for the upstart approach.
+>>>
+>>>
+>>> My first point of criticism has already been described by Russ, but
+>>> maybe I can make it clearer by giving an example. In my opinion, the
+>>> following job looks completely harmless, and should not result in an
+>>> unbootable system (but at least on Ubuntu 13.10 it does, you have to
+>>> reboot with init=/bin/sh and remove/fix the evilJob.conf file):
+>>>
+>>> $ cat evilJob.conf
+>>> start on (mounted MOUNTPOINT=/var and started lightdm)
+>>> stop on runleves [016]
+>>> respawn
+>>> script
+>>>    exec /bin/sleep 60
+>>> end script
+>>>
+>>> I believe that the equivalent systemd unit (where dependencies are
+>>> specified with Requires=) works just fine.  It is not clear to me how
+>>> this can be "incrementally fixed" in upstart without fundamentally
+>>> changing the design.
+>>>
+>>>
+>>> My second point is that by treating dependencies as events, upstart does
+>>> not seem to truly recognize dependencies as such and is then unable to
+>>> resolve them.  For example, with the following two job files (created
+>>> according to the upstart cookbook, 6.32.2):
+>>>
+>>> $ cat jobOne.conf
+>>> start on (starting jobTwo and runlevel stop on runlevel [016])
+>>> stop on runlevel [016]
+>>> respawn
+>>> script
+>>>     exec /bin/sleep 60
+>>> end script
+>>> 
+>>> $ cat jobTwo.conf
+>>> start on runlevel [2345]
+>>> stop on runlevel [016]
+>>> respawn
+>>> script
+>>>     exec /bin/sleep 60
+>>> end script
+>>> 
+>>> 
+>>> I can type "service start jobOne", and upstart will willingly start
+>>> jobOne without starting jobTwo, or doing anything about the unfulfilled
+>>> dependency (not even a warning):
+>>> 
+>>> root@ubuntu-kvm:/etc/init# service jobOne status
+>>> jobOne stop/waiting
+>>> root@ubuntu-kvm:/etc/init# service jobTwo status
+>>> jobTwo stop/waiting
+>>> root@ubuntu-kvm:/etc/init# service jobOne start
+>>> jobOne start/running, process 3177
+>>> root@ubuntu-kvm:/etc/init# service jobTwo status
+>>> jobTwo stop/waiting
+>>> 
+>>> (on Ubuntu 13.10).
+>>
+>> I think you raise a lot of good points in this email, but here you are
+>> saying something which may demonstrate your (understandable) confusion
+>> about the Upstart event model. Upstart does not treat dependencies as
+>> events. Often times, Upstart //jobs// treat dependencies as events (and the
+>> ones you wrote below do), but events do not signal a dependency. Just
+>> because you said that jobOne starts with jobTwo does not mean that jobOne
+>> needs jobTwo, just that during boot up jobOne will start with jobTwo. To
+>> express a dependency, jobTwo needs to have a "start on (event where I am
+>> needed)". If, for example, jobOne depends on a dbus interface of jobTwo,
+>> then jobTwo could have a "start on dbus ..." to show that dependency.
+>
+> I think I understand what you're saying, thanks for the explanations!
+>
+> However, I can't say that this improved understanding has improved my
+> opinion about upstart. If I understand correctly, this means that either
+>
+> a) every upstart job definition needs to explicitly list every possible
+>    way in which another service may depend on it (and, furthermore,
+>    every possible such dependency needs to have upstart integration so
+>    that it can actually be used as an event)
+>
+> or
+>
+> b) a package providing jobOne that depends on jobTwo from another
+>    package needs to patch the *other* package's configuration to add the
+>    dependency information to jobTwo's definition.
+>
+> Neither of this sounds appealing to me at all, especially compared to
+> systemd, where all you have to do is drop a Requires= line into jobOne's
+> configuration.
+>
+>> Basically, to express dependencies in Upstart you express all the ways
+>> a job is needed inside of that job, not inside others.  That said,
+>> Upstart developers and Ubuntu developers do not use Upstart this way
+>> and write jobs like you did below, so an Upstart system will most
+>> likely not act like I explained above (however this is not an inherent
+>> flaw in Upstart).
+>
+> Well, so what is the proper way to encode a dependency in an upstart job
+> for Ubuntu (and presumable Debian) then? Apparently the proper way is
+> extremly tedious and not used by anyone, and the other way isn't able to
+> satisfy dependencies.
+>
+>
+> Also, I would think that your statement above is a rather strong
+> indication that this is *not* the upstart is meant to be used. Could the
+> upstart developers comment on this?
+
+
+
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 13 Jan 2014 12:03:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Алексей Шилин <rootlexx@mail.ru>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 13 Jan 2014 12:03:14 GMT) (full text, mbox, link).

+ +

Message #3155 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Алексей Шилин <rootlexx@mail.ru>
+
To: 727708@bugs.debian.org
+
Subject: Bits from linux.conf.au
+
Date: Mon, 13 Jan 2014 15:57:18 +0400
+
+
There was a talk on January 08, 2014 at linux.conf.au Linux conference by Marc Merlin, Google server
+sysadmin and software engineer.
+
+Quoting the description [1]:
+
+> This talk will look at how we upgraded our ancient linux distribution on all the Google production
+> servers to a more modern one based on debian stripped down and built from source.
+
+In his talk [2] at 13:50 Marc briefly touched the init system choice question. Perhaps it's worth taking
+into account.
+
+[1] http://linux.conf.au/schedule/30014/view_talk?day=wednesday
+[2] http://mirror.linux.org.au/linux.conf.au/2014/Wednesday/71-Live_upgrading_many_thousands_of_servers_from_an_ancient_RedHat_7.1_to_a_10_year_newer_Debian_-_Marc_MERLIN.mp4
+
+-- 
+Алексей Шилин
+ +

+ + +Information stored +:
+Bug#727708; Package tech-ctte. + (Mon, 13 Jan 2014 12:21:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and filed, but not forwarded. + (Mon, 13 Jan 2014 12:21:15 GMT) (full text, mbox, link).

+ +

Message #3160 received at 727708-quiet@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: Алексей Шилин <rootlexx@mail.ru>, + 727708-quiet@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Mon, 13 Jan 2014 12:15:02 +0000 (UTC)
+
+
Алексей Шилин dixit:
+
+> In his talk [2] at 13:50 Marc briefly touched the init system choice question.
+
+Can you please provide a transcript, for those among us who
+do not watch any video?
+
+Thanks,
+//mirabilos
+-- 
+  "Using Lynx is like wearing a really good pair of shades: cuts out
+   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
+                                         -- Henry Nelson, March 1999
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 13 Jan 2014 12:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Dmitry Yu Okunev <dyokunev@ut.mephi.ru>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 13 Jan 2014 12:33:04 GMT) (full text, mbox, link).

+ +

Message #3165 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Dmitry Yu Okunev <dyokunev@ut.mephi.ru>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Mon, 13 Jan 2014 16:31:50 +0400
+
+
[Message part 1 (text/plain, inline)]
+
Hello.
+
+On 01/13/2014 03:57 PM, Алексей Шилин wrote:
+> In his talk [2] at 13:50 Marc briefly touched the init system choice question. Perhaps it's worth taking
+> into account.
+> 
+> [2] http://mirror.linux.org.au/linux.conf.au/2014/Wednesday/71-Live_upgrading_many_thousands_of_servers_from_an_ancient_RedHat_7.1_to_a_10_year_newer_Debian_-_Marc_MERLIN.mp4
+
+[2] is placed in Australia, so I've mirrored it to [3].
+
+[3]
+http://mirror.mephi.ru/other/2014/71-Live_upgrading_many_thousands_of_servers_from_an_ancient_RedHat_7.1_to_a_10_year_newer_Debian_-_Marc_MERLIN.mp4
+
+I hope this will be useful for somebody.
+
+-- 
+Best regards, Dmitry,
+head of UNIX-tech department NRNU MEPhI,
+tel. 8 (495) 788-56-99, add. 8255
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 13 Jan 2014 12:51:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to skirpichev@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 13 Jan 2014 12:51:08 GMT) (full text, mbox, link).

+ +

Message #3170 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sergey B Kirpichev <skirpichev@gmail.com>
+
To: 727708@bugs.debian.org
+
Cc: Thorsten Glaser <tg@mirbsd.de>
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Mon, 13 Jan 2014 16:43:50 +0400
+
+
On Mon, Jan 13, 2014 at 12:15:02PM +0000, Thorsten Glaser wrote:
+> Алексей Шилин dixit:
+> 
+> > In his talk [2] at 13:50 Marc briefly touched the init system choice question.
+> 
+> Can you please provide a transcript, for those among us who
+> do not watch any video?
+
+This talk in article format:
+http://marc.merlins.org/linux/talks/ProdNG-LCA2014/Paper/
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 13 Jan 2014 13:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 13 Jan 2014 13:18:04 GMT) (full text, mbox, link).

+ +

Message #3175 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: 727708@bugs.debian.org
+
Cc: Thorsten Glaser <tg@mirbsd.de>, Алексей Шилин <rootlexx@mail.ru>
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Mon, 13 Jan 2014 13:15:07 +0000
+
+
On 13/01/14 12:15, Thorsten Glaser wrote:
+> Алексей Шилин dixit:
+>> In his talk [2] at 13:50 Marc briefly touched the init system choice question.
+> 
+> Can you please provide a transcript, for those among us who
+> do not watch any video?
+
+In the slides[0] 13 to 15, he summarises init systems something like:
+* SysV - simple, familiar and deterministic
+* Upstart - fast boot, makes sense on laptops, but inherently racey
+* systemd - interesting concept, but too disruptive/complex to buy into
+
+Then he gives a preference for Debian's own insserv and startpar.  It
+allows for boot order to be fixed (after running insserv once, the same
+/etc/rc2.d/Sxx numbering may be rsync'd out to many machines).  startpar
+allows for some limited/controlled amount of concurrency to happen, for
+extra speed.
+
+For servers, their priority is in reliability/reproducibility of boot
+(especially for pre-deployment testing), as the machines are so rarely
+rebooted, and engineer time to debug any boot problem is so costly.
+
+It's worth mentioning their boot is customised already for their
+environment.  Before the root filesystem is mounted, there seems to be
+some centralised logging, and an sshd started in the initrd, for human
+or automated intervention in case the machine doesn't finish booting.
+That may have pushed them in favour of a simpler init system.
+
+[0]: http://marc.merlins.org/linux/talks/ProdNG-LCA2014/ProdNG.odp
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 13 Jan 2014 13:27:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 13 Jan 2014 13:27:09 GMT) (full text, mbox, link).

+ +

Message #3180 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steven Chamberlain <steven@pyro.eu.org>, + 727708@bugs.debian.org
+
Cc: Thorsten Glaser <tg@mirbsd.de>, + <rootlexx@mail.ru>
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Mon, 13 Jan 2014 13:25:16 +0000
+
+
Steven Chamberlain writes ("Bug#727708: Bits from linux.conf.au"):
+> Then he gives a preference for Debian's own insserv and startpar.  It
+> allows for boot order to be fixed (after running insserv once, the same
+> /etc/rc2.d/Sxx numbering may be rsync'd out to many machines).  startpar
+> allows for some limited/controlled amount of concurrency to happen, for
+> extra speed.
+
+I think that what this shows is how valuable it is for our downstreams
+that Debian is flexible and doesn't impose a particular approach.
+
+I'm coming round to the view that we should be planning to support
+multiple systems indefinitely.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 13 Jan 2014 13:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Vincent Lefevre <vincent@vinc17.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 13 Jan 2014 13:51:05 GMT) (full text, mbox, link).

+ +

Message #3185 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Vincent Lefevre <vincent@vinc17.net>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Mon, 13 Jan 2014 14:48:59 +0100
+
+
On 2014-01-13 13:15:07 +0000, Steven Chamberlain wrote:
+> In the slides[0] 13 to 15, he summarises init systems something like:
+> * SysV - simple, familiar and deterministic
+
+Deterministic?
+
+Well, the scripts may be started sequentially, but this doesn't mean
+that the daemons will be and always in the same order. And they don't,
+as shows in the following log:
+
+[...]
+Sat Dec 24 17:09:45 2011: Starting SpamAssassin Mail Filter Daemon: Starting Network connection manager: wicd.
+Sat Dec 24 17:09:50 2011: Starting OpenBSD Secure Shell server: sshd.
+Sat Dec 24 17:09:52 2011: spamd.
+[...]
+
+and still now (but less readable):
+
+(1)
+[...]
+Thu Aug  1 10:24:51 2013: Starting SpamAssassin Mail Filter Daemon: [....] Starting Network connection manager: wicd^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.
+Thu Aug  1 10:24:59 2013: [....] Starting OpenBSD Secure Shell server: sshd^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.
+Thu Aug  1 10:25:08 2013: spamd.
+Thu Aug  1 10:25:08 2013: [....] Starting Postfix Mail Transport Agent: postfix^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.
+[...]
+
+(2)
+[...]
+Sun Aug 18 12:18:21 2013: Starting SpamAssassin Mail Filter Daemon: [....] Starting OpenBSD Secure Shell server: sshd^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.
+Sun Aug 18 12:18:26 2013: [....] Starting Network connection manager: wicd^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.
+Sun Aug 18 12:18:34 2013: spamd.
+Sun Aug 18 12:18:34 2013: [....] Starting Postfix Mail Transport Agent: postfix^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.
+[...]
+
+In (1):
+  spamd start
+  wicd start/OK
+  sshd start/OK
+  spamd OK
+  postfix start/OK
+
+In (2):
+  spamd start
+  sshd start/OK
+  wicd start/OK
+  spamd OK
+  postfix start/OK
+
+This isn't deterministic at all.
+
+-- 
+Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
+100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
+Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 13 Jan 2014 14:06:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 13 Jan 2014 14:06:19 GMT) (full text, mbox, link).

+ +

Message #3190 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: 727708@bugs.debian.org
+
Cc: Vincent Lefevre <vincent@vinc17.net>
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Mon, 13 Jan 2014 14:05:12 +0000
+
+
On 13/01/14 13:48, Vincent Lefevre wrote:
+> On 2014-01-13 13:15:07 +0000, Steven Chamberlain wrote:
+>> In the slides[0] 13 to 15, he summarises init systems something like:
+>> * SysV - simple, familiar and deterministic
+> 
+> Deterministic?
+
+Only the traditional SysV.  Debian since squeeze uses startpar so will
+start *some* things concurrently (same Sxx number).  And where that
+happens, it's much simpler to see/control it as files in /etc/rc2.d,
+than e.g. events being triggered and such.
+
+> Well, the scripts may be started sequentially, but this doesn't mean
+> that the daemons will be and always in the same order.
+
+Actually, even if they forked in the same order every time, they might
+not be *ready* in the same order.  That would be the rationale for
+readiness protocols and other features of the more complex init systems.
+
+> In (1):
+>   spamd start
+>   wicd start/OK
+>   sshd start/OK
+>   spamd OK
+>   postfix start/OK
+> 
+> In (2):
+>   spamd start
+>   sshd start/OK
+>   wicd start/OK
+>   spamd OK
+>   postfix start/OK
+> 
+> This isn't deterministic at all.
+
+I think that's just because insserv+startpar was being used here, not
+the traditional SysV.
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 13 Jan 2014 14:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 13 Jan 2014 14:18:04 GMT) (full text, mbox, link).

+ +

Message #3195 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: Vincent Lefevre <vincent@vinc17.net>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Mon, 13 Jan 2014 14:13:06 +0000 (UTC)
+
+
Vincent Lefevre dixit:
+
+>Well, the scripts may be started sequentially, but this doesn't mean
+>that the daemons will be and always in the same order. And they don't,
+>as shows in the following log:
+
+That’s due to the (now default with sysv-rc) use of parallel boot
+in combination with insserv. It used to be possible to still use
+sequential boot even with insserv, and file-rc enabled that auto‐
+matically (which is why I kept using it even with insserv) but I
+don’t recall where the switch for sysv-rc is.
+
+If you disable “makefile-style concurrent whatever”, sysv-rc is
+deterministic even with insserv.
+
+bye,
+//mira“tys”bilos
+-- 
+<diogenese> Beware of ritual lest you forget the meaning behind it.
+<igli> yeah but it means if you really care about something, don't
+    ritualise it, or you will lose it. don't fetishise it, don't
+    obsess. or you'll forget why you love it in the first place.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 13 Jan 2014 14:30:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 13 Jan 2014 14:30:10 GMT) (full text, mbox, link).

+ +

Message #3200 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: Steven Chamberlain <steven@pyro.eu.org>, 727708@bugs.debian.org
+
Cc: Vincent Lefevre <vincent@vinc17.net>, debian-bugs-dist@lists.debian.org, + Technical Committee <debian-ctte@lists.debian.org>
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Mon, 13 Jan 2014 14:15:28 +0000 (UTC)
+
+
Steven Chamberlain dixit:
+
+>Actually, even if they forked in the same order every time, they might
+>not be *ready* in the same order.  That would be the rationale for
+>readiness protocols and other features of the more complex init systems.
+
+Strong disagree. This actually is a bug in the initscripts in question
+that they return before the service is operational. Fixing this does
+not require exchanging PID 1 at all. In fact, there was some posting on
+Planet Debian where someone used #!/path/to/some-initscriptwriting-helper
+instead of shell for them.
+
+bye,
+//mirabilos
+-- 
+Support mksh as /bin/sh and RoQA dash NOW!
+‣ src:bash (268 (291) bugs: 0 RC, 188 (204) I&N, 80 (87) M&W, 0 F&P)
+‣ src:dash (89 (106) bugs: 2 RC, 43 (49) I&N, 44 (55) M&W, 0 F&P)
+‣ src:mksh (2 bugs: 0 RC, 0 I&N, 2 M&W, 0 F&P, 1 gift)
+http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?
+
+
+
+ +

+ + +Information stored +:
+Bug#727708; Package tech-ctte. + (Mon, 13 Jan 2014 15:27:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Алексей Шилин <rootlexx@mail.ru>:
+Extra info received and filed, but not forwarded. + (Mon, 13 Jan 2014 15:27:07 GMT) (full text, mbox, link).

+ +

Message #3205 received at 727708-quiet@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Алексей Шилин <rootlexx@mail.ru>
+
To: Thorsten Glaser <tg@mirbsd.de>
+
Cc: 727708-quiet@bugs.debian.org
+
Subject: Re[2]: Bug#727708: Bits from linux.conf.au
+
Date: Mon, 13 Jan 2014 19:22:55 +0400
+
+
Понедельник, 13 января 2014, 12:15 UTC от Thorsten Glaser <tg@mirbsd.de>:
+>Алексей Шилин dixit:
+>
+>> In his talk [2] at 13:50 Marc briefly touched the init system choice question.
+>
+>Can you please provide a transcript, for those among us who
+>do not watch any video?
+>
+>Thanks,
+>//mirabilos
+
+Steven Chamberlain made a good summary and analysis in #3175 (thanks!). I'll
+just post the corresponding slides content in plain text and some key points
+from the commentary.
+
+--------------> Slide 1: SysV <---------------
+|                                            |
+| * Sequential booting with                  |
+|   /etc/rcX.d/Sxxdaemon is simple           |
+| * But it's slow                            |
+| * A single hanging script can stop         |
+|   other daemons like ssh from starting     |
+|                                            |
+----------------------------------------------
+
+What they like about SysV init is that it boots the same everywhere.
+
+------------> Slide 2: Upstart <--------------
+|                                            |
+| * Mostly used on Ubuntu (also ChromeOS)    |
+| * Requires a different syntax (ideally     |
+|   better than shell)                       |
+| * Does not guarantee any specific boot     |
+|   odrer                                    |
+| * Very dependant on proper dependencies    |
+|   being found and specified by the         |
+|   maintainers. This is hard                |
+| * It will deadlock and stop the boot if    |
+|   something is wrong, which can happen     |
+|   1 boot out of 3 for instance             |
+| * On occasion, upstart will enter states   |
+|   that require a reboot to clear           |
+| * Can be hard to debug, especially on      |
+|   headless servers                         |
+|                                            |
+----------------------------------------------
+
+The biggest problem for them is: upstart doesn't give a specific boot order. It
+becomes increasingly difficult to test: if they have a race condition, they may
+not catch it early before deployment.
+
+------------> Slide 3: Systemd <--------------
+|                                            |
+| * Originally went into Fedora for testing  |
+|   and tuning                               |
+| * Not yet included in server distributions |
+|   like RHEL                                |
+| * Very disruptive, big redesign of how     |
+|   Linux systems boot. Replaces many core   |
+|   parts of low level Linux                 |
+| * On the plus side, Lennart has done a     |
+|   very good job in explaining the          |
+|   rationale behind the required changes    |
+|   and the gains                            |
+| * Ideal design does not rely on            |
+|   dependencies being specified by the      |
+|   packagers, they are auto computed on     |
+|   demand. Real life is sometimes           |
+|   otherwise though, and requires manual    |
+|   dependencies                             |
+| * Like upstart, given boot order is not    |
+|   specified, could trigger race conditions |
+|   in our scripts or daemons, and only on   |
+|   1% of our machines                       |
+| * Systemd sounded simple, but the          |
+|   implementation and getting everything    |
+|   right is much more complex than we're    |
+|   comfortable with                         |
+|                                            |
+----------------------------------------------
+
+Systemd is believed to have mostly the same issues with boot consistency. It
+does and offers many things, which is kind of nice, and they may look at it
+eventually, but it's not worth switching yet.
+
+------------> Slide 4: Insserv <--------------
+|                                            |
+| * Debian had an upstart like dependency    |
+|   specified boot, before everyone else     |
+|   with insserv and startpar                |
+| * Before reboot, insserv will analyze      |
+|   specified dependencies between scripts,  |
+|   and rename init scripts as S10, some as  |
+|   S20, and so forth                        |
+| * Everything under S10 is started at the   |
+|   same time, and things in S20 won't start |
+|   until all of S10xx has started           |
+| * It's easy to visualize and review        |
+|   dependencies before reboot               |
+| * We can freeze them in our image, and     |
+|   deploy everywhere                        |
+| * Simple, and everything is the same =>    |
+|   winner for us                            |
+|                                            |
+----------------------------------------------
+
+They can easily review the order, while with upstart and systemd you just never
+know.
+
+
+-- 
+Алексей Шилин
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 13 Jan 2014 19:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 13 Jan 2014 19:03:04 GMT) (full text, mbox, link).

+ +

Message #3210 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Thorsten Glaser <tg@mirbsd.de>
+
Cc: Steven Chamberlain <steven@pyro.eu.org>, 727708@bugs.debian.org, Vincent Lefevre <vincent@vinc17.net>
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Mon, 13 Jan 2014 10:59:11 -0800
+
+
Thorsten Glaser <tg@mirbsd.de> writes:
+> Steven Chamberlain dixit:
+
+>> Actually, even if they forked in the same order every time, they might
+>> not be *ready* in the same order.  That would be the rationale for
+>> readiness protocols and other features of the more complex init
+>> systems.
+
+> Strong disagree. This actually is a bug in the initscripts in question
+> that they return before the service is operational. Fixing this does not
+> require exchanging PID 1 at all. In fact, there was some posting on
+> Planet Debian where someone used
+> #!/path/to/some-initscriptwriting-helper instead of shell for them.
+
+If the daemon itself is ill-behaved, you generally have to do some
+additional work to make this happen beyond just writing a better init
+script.  Well-behaved daemons will provide some synchronization point (not
+exiting in the parent until the daemon is started and ready, ideally, but
+this requires a pipe or some other method to coordinate, so more common is
+to have the child not write out its PID file until it's ready).  If they
+don't, then it requires upstream patching, and can be tricky.
+
+This doesn't change across the various init systems, although upstart and
+systemd provide less tricky and racy ways of synchronizing than writing
+PID files.  That said, most of the race conditions involved in the PID
+file approach are rare.  Mostly you get into trouble if two copies of the
+process are started at the same time, particularly if they're racing each
+other to write the PID file.
+
+Synchronizing on the PID file is my personal preference for old-style
+daemons since it's so much easier to implement than controlling when the
+parent process exits.
+
+I *think* that start-stop-daemon properly implements PID-file-based
+synchronization based on the description of the --pidfile option, but I'm
+not positive and haven't checked the source.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 13 Jan 2014 20:57:25 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 13 Jan 2014 20:57:25 GMT) (full text, mbox, link).

+ +

Message #3215 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Status of the init system discussion
+
Date: Mon, 13 Jan 2014 12:56:52 -0800
+
+
Several people have asked me about this in private, so I thought it was
+worth sending a public message about my understanding of the current
+status.
+
+I think those of us who have been active on the discussion have mostly
+stopped writing more because we had started repeating ourselves, or were
+in danger of doing so, and were getting off into minutia.  Ian's and my
+discussion of wording for one of the ballot options was at the point where
+it needed input from other people, so I was holding off on discussing it
+pending that (and I think Ian was as well).  I also don't know if Keith,
+Don, or Andreas wanted to weigh in to the general discussion.
+
+Remaining work that I'm aware of, beyond any further discussion that might
+be sparked by the people who haven't yet participated, is mostly around
+hashing out what the ballot options will be.  I think we have most of the
+framework set up in response to Ian's draft language (thank you again,
+Ian!), but there are details that are uncertain and would benefit from
+more discussion.
+
+We will also need wording for a ballot option to throw the question to a
+GR if we want to have that on the ballot.  I think the general feeling of
+those who have commented on that approach is that it's basically an
+alternative to voting further discussion rather than anyone's primary
+choice.
+
+Speaking only personally, one of my occasional problems with Debian's
+voting system is that it's very unclear in some cases what "futher
+discussion" *means*.  It clearly means "we're not going to make a
+decision," but in cases where we have to make a decision, it's sometimes a
+weird way of phrasing the status quo.  I like having the "have a GR"
+option on the ballot next to further discussion because it provides a
+clear path forward for the project to make a decision, whereas in this
+case further discussion doesn't really.  That effectively reserves further
+discussion as the voting option for people who really think we should not
+make a decision right now, as opposed to thinking we're in the wrong
+decision-making process or feeling like the project should make a decision
+now even if the technical committee can't reach consensus.
+
+On a personal note, I've also gone much more quiet because I was spending
+four to eight hours a day on the discussion, something that I could only
+do because I was on vacation.  Since I'm now back to work, I have to
+drastically reduce the amount of time I can spend on the discussion.
+Thankfully, the major time investment portion seems past, but I thought it
+was worth mentioning in case anyone was worried about slow responses.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 13 Jan 2014 21:00:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 13 Jan 2014 21:00:09 GMT) (full text, mbox, link).

+ +

Message #3220 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, Steven Chamberlain <steven@pyro.eu.org>, 727708@bugs.debian.org
+
Cc: Thorsten Glaser <tg@mirbsd.de>, rootlexx@mail.ru
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Mon, 13 Jan 2014 13:57:29 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I'm coming round to the view that we should be planning to support
+> multiple systems indefinitely.
+
+This has been my opinion all along.  Various assertions that it's
+somehow just too hard really haven't swayed me.  The tricky bit, I
+think, is to define just what "support" means in the context of
+non-default init systems.  
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 13 Jan 2014 23:15:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 13 Jan 2014 23:15:09 GMT) (full text, mbox, link).

+ +

Message #3225 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Mon, 13 Jan 2014 23:12:24 +0000
+
+
[Message part 1 (text/plain, inline)]
+
On 13/01/14 20:57, Bdale Garbee wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+>> I'm coming round to the view that we should be planning to support
+>> multiple systems indefinitely.
+> 
+> This has been my opinion all along.  Various assertions that it's
+> somehow just too hard really haven't swayed me.  The tricky bit, I
+> think, is to define just what "support" means in the context of
+> non-default init systems.  
+
+IIRC, when kfreebsd became a release goal for squeeze, there was some
+policy that certain fixes were allowed to be handled as RC bugs,
+especially during the freeze.  That allowed porters to potentially get
+something NMUd or unblocked if it was important to getting things
+working on that system.
+
+Could each proposed/approved init system for jessie be handled like
+this, generally?  The respective teams would contribute the necessary
+work to make sure things work with that system.  Maintainers would need
+to accommodate reasonable changes (mostly adding native init scripts) if
+they haven't already.
+
+That to me sounds enough like 'supporting' an init system.  After
+committing to such goals, once the work really gets underway, any
+specific disagreements between teams over how to do things or what's
+reasonable, could be handled separately as they arise, and escalated to
+the ctte where necessary?
+
+It wouldn't matter to me which is ultimately chosen as the default in
+that case, if I only knew I wouldn't be wasting my time working on a
+particular init system.
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 17:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 17:39:05 GMT) (full text, mbox, link).

+ +

Message #3230 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Bdale Garbee <bdale@gag.com>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, + Steven Chamberlain <steven@pyro.eu.org>, + Thorsten Glaser <tg@mirbsd.de>, rootlexx@mail.ru
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 19:36:44 +0200
+
+
On Mon, Jan 13, 2014 at 01:57:29PM -0700, Bdale Garbee wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> 
+> > I'm coming round to the view that we should be planning to support
+> > multiple systems indefinitely.
+> 
+> This has been my opinion all along.  Various assertions that it's
+> somehow just too hard really haven't swayed me.  The tricky bit, I
+> think, is to define just what "support" means in the context of
+> non-default init systems.  
+
+There are at least three tricky areas:
+
+1. init systems will have to cope with packages supplying init scripts 
+in several formats they support.
+
+2. How to ensure that both systemd systems and non-systemd systems
+work equally well?
+If dependencies like "installing GNOME enforces systemd as init system"
+would be legal, then after a few more such dependencies it would turn
+out that systemd will be the only option available for virtually all 
+users - and that all the hassle of supporting multiple init systems
+was a waste of effort.
+
+3. Switching init systems after installation.
+Assume I am currently using systemd.
+What is supposed to happen when I do "apt-get install sysvinit-core"?
+
+
+> Bdale
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 17:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 17:51:04 GMT) (full text, mbox, link).

+ +

Message #3235 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Bdale Garbee <bdale@gag.com>, + 727708@bugs.debian.org
+
Cc: Steven Chamberlain <steven@pyro.eu.org>, + Thorsten Glaser <tg@mirbsd.de>, + rootlexx@mail.ru
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 17:49:37 +0000
+
+
Bdale Garbee writes ("Bug#727708: Bits from linux.conf.au"):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > I'm coming round to the view that we should be planning to support
+> > multiple systems indefinitely.
+> 
+> This has been my opinion all along.  Various assertions that it's
+> somehow just too hard really haven't swayed me.  The tricky bit, I
+> think, is to define just what "support" means in the context of
+> non-default init systems.  
+
+Perhaps the resolution should have this stated prominently.
+
+I think supporting an init system X (whether X is the default or not)
+means that:
+
+ - No non-init-system part of the system requires a particular 
+   init system to be in use - so the user has a free choice.
+
+ - When a non-default init system is in use, functionality and
+   correctness is at least equivalent to that provided by sysvinit.
+
+ - There may however be degraded functionality, for example UIs to
+   init system Y != X (or to features provided only by system Y) may
+   be missing or nonfunctional.
+
+ - Functionality and correctness improvements contributed by people
+   who care about init system X are accepted by the project into
+   whatever are the appropriate packages for that support.
+
+Or to put it another way: I think it should be made clear that we are
+committed to supporting at least upstart and systemd.  Not just for
+jessie, but into the foreseeable future, as long as their communities
+remain healthy.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 18:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Stapelberg <stapelberg@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 18:00:05 GMT) (full text, mbox, link).

+ +

Message #3240 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Stapelberg <stapelberg@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>, Bdale Garbee <bdale@gag.com>, <727708@bugs.debian.org>
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, Steven Chamberlain <steven@pyro.eu.org>, Thorsten Glaser <tg@mirbsd.de>, rootlexx@mail.ru
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 18:56:36 +0100
+
+
Hi Adrian,
+
+Adrian Bunk <bunk@stusta.de> writes:
+
+> On Mon, Jan 13, 2014 at 01:57:29PM -0700, Bdale Garbee wrote:
+>> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+>> 
+>> > I'm coming round to the view that we should be planning to support
+>> > multiple systems indefinitely.
+>> 
+>> This has been my opinion all along.  Various assertions that it's
+>> somehow just too hard really haven't swayed me.  The tricky bit, I
+>> think, is to define just what "support" means in the context of
+>> non-default init systems.  
+>
+> There are at least three tricky areas:
+>
+> 1. init systems will have to cope with packages supplying init scripts 
+> in several formats they support.
+Agreed. Effectively, this puts a lot of burden on individual maintainers
+(and also on some external packagers) to test their packages with 2+
+init systems and become familiar with how to properly mask units/handle
+diverting names, what features each system supports, what the best
+practices for each are, etc.
+
+Of course, to some degree, this also needs to happen when we
+transition. But having a one-time transition and doing something forever
+are two very different things, and I’d be really sad if we were to
+impose this kind of work on our contributors.
+
+> 3. Switching init systems after installation.
+> Assume I am currently using systemd.
+> What is supposed to happen when I do "apt-get install sysvinit-core"?
+One could implement a GRUB boot menu (or multiple boot entries) or some
+sort of switcher, but the more important point about this is the
+synchronization of init system state, i.e. which units/scripts are
+enabled/disabled. The idea here is that if you disable lighttpd on
+sysvinit, it should not start when you reboot into systemd and vice
+versa.
+
+Having written deb-systemd-helper (shipped in the init-system-helpers
+package), I know very well how many corner cases and rough edges¹ are out
+there in that respect. deb-systemd-helper was written with the intention
+of getting rid of it after Debian switched to systemd. Supporting/using
+it indefinitely is certainly not a good idea, and I think this is not
+implementation-specific, but a general issue.
+
+In conclusion, I’d hate a situation where we’d support multiple init
+systems. I strongly recommend deciding for one init system.
+
+① The mapping of service file names (and socket file names!) to init
+  script names is just one of them, but a fairly obvious and easy to
+  understand one. Note that there are Alias= directives in service
+  files, too.
+
+-- 
+Best regards,
+Michael
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 18:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 18:06:04 GMT) (full text, mbox, link).

+ +

Message #3245 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Adrian Bunk <bunk@stusta.de>, + 727708@bugs.debian.org
+
Cc: Bdale Garbee <bdale@gag.com>, + Steven Chamberlain <steven@pyro.eu.org>, + Thorsten Glaser <tg@mirbsd.de>, + rootlexx@mail.ru
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 18:03:33 +0000
+
+
Adrian Bunk writes ("Bug#727708: Bits from linux.conf.au"):
+> There are at least three tricky areas:
+> 
+> 1. init systems will have to cope with packages supplying init scripts 
+> in several formats they support.
+
+Perhaps.  I'm certainly not expecting to solve this problem in the
+general case in jessie.  In jessie we'll do this by having each init
+fall back to sysvinit for packages which don't supply native support.
+
+That may well be suitable indefinitely.
+
+> 2. How to ensure that both systemd systems and non-systemd systems
+> work equally well?
+> If dependencies like "installing GNOME enforces systemd as init system"
+> would be legal,
+
+Implicit in "supporting multiple init systems" is that such
+dependencies would have to be avoided.
+
+But that doesn't mean they have to work "equally well" - see my other
+message.
+
+> 3. Switching init systems after installation.
+> Assume I am currently using systemd.
+> What is supposed to happen when I do "apt-get install sysvinit-core"?
+
+I think that if you want to switch init system after installation, I
+don't mind at all if you are expected to reboot.  (With the possible
+exception of switching away from sysvinit.)
+
+And I don't mind very much if service disablement (or even to an
+extent service configuration) isn't translated.  It's probably better
+to have the sysadmin redo that manually than have some kind of
+unreliable and complicated automatic scheme.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 18:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 18:09:04 GMT) (full text, mbox, link).

+ +

Message #3250 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Michael Stapelberg <stapelberg@debian.org>, + 727708@bugs.debian.org
+
Cc: Adrian Bunk <bunk@stusta.de>, + Bdale Garbee <bdale@gag.com>, + Steven Chamberlain <steven@pyro.eu.org>, + Thorsten Glaser <tg@mirbsd.de>, + rootlexx@mail.ru
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 18:05:47 +0000
+
+
Michael Stapelberg writes ("Bug#727708: Bits from linux.conf.au"):
+> Adrian Bunk <bunk@stusta.de> writes:
+> > 1. init systems will have to cope with packages supplying init scripts 
+> > in several formats they support.
+>
+> Agreed. Effectively, this puts a lot of burden on individual maintainers
+> (and also on some external packagers) to test their packages with 2+
+> init systems and become familiar with how to properly mask units/handle
+> diverting names, what features each system supports, what the best
+> practices for each are, etc.
+
+I would expect the community for that init system to do the work.  So
+the burden on maintainers ought to be minimal.  All they ought to be
+required to do is ship the init-system-specific config thingy supplied
+by the community who are interested in that init system.  That might
+even be done by NMU so the maintainer would often not have to do
+anything at all.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 18:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to skirpichev@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 18:33:04 GMT) (full text, mbox, link).

+ +

Message #3255 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sergey B Kirpichev <skirpichev@gmail.com>
+
To: 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 22:27:50 +0400
+
+
On Tue, Jan 14, 2014 at 06:05:47PM +0000, Ian Jackson wrote:
+> Michael Stapelberg writes ("Bug#727708: Bits from linux.conf.au"):
+> > Agreed. Effectively, this puts a lot of burden on individual maintainers
+> > (and also on some external packagers) to test their packages with 2+
+> > init systems and become familiar with how to properly mask units/handle
+> > diverting names, what features each system supports, what the best
+> > practices for each are, etc.
+> 
+> I would expect the community for that init system to do the work.  So
+> the burden on maintainers ought to be minimal.  All they ought to be
+> required to do is ship the init-system-specific config thingy supplied
+> by the community who are interested in that init system.  That might
+> even be done by NMU so the maintainer would often not have to do
+> anything at all.
+
+Clearly, that's not the end of the job.  systemd/upstart/whatever
+configs could be buggy as everything other.  Currently, if maintainer
+provides sysv init script - he is responsible for related bugreports.
+
+Who is responsible for supporting this in your scheme?  Or
+systemd/upstart configs supposed to be written once and
+work well forever?
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 18:33:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 18:33:07 GMT) (full text, mbox, link).

+ +

Message #3260 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Adrian Bunk <bunk@stusta.de>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, Steven Chamberlain <steven@pyro.eu.org>, Thorsten Glaser <tg@mirbsd.de>, rootlexx@mail.ru
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 11:31:09 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Adrian Bunk <bunk@stusta.de> writes:
+
+> There are at least three tricky areas:
+>
+> 1. init systems will have to cope with packages supplying init scripts 
+> in several formats they support.
+
+This doesn't seem that tricky to me.  If a package provides init
+functionality in the preferred native format for a given init system,
+that would take precedence over functionality provided in a supported
+but not preferred format, right? 
+
+> 2. How to ensure that both systemd systems and non-systemd systems
+> work equally well?
+
+This for me immediately gets hung up in how one defines "equally well",
+as expectations are clearly going to differ between init systems.  
+
+> If dependencies like "installing GNOME enforces systemd as init system"
+> would be legal, then after a few more such dependencies it would turn
+> out that systemd will be the only option available for virtually all 
+> users - and that all the hassle of supporting multiple init systems
+> was a waste of effort.
+
+Please be careful about stacking assumptions like this.  Equating GNOME
+to "virtually all users" completely ignores the vast number of Debian
+instances on servers, virtual machines, and embedded systems.  And even
+if you only think about client systems, in my own circle of friends
+there's a lot more XFCE4 than GNOME these days.
+
+> 3. Switching init systems after installation.
+> Assume I am currently using systemd.
+> What is supposed to happen when I do "apt-get install sysvinit-core"?
+
+That's a great question.  I suspect most of the effort in thinking about
+init system transitions so far has gone in to figuring out how to replace
+sysvinit.  But if we're truly going to support alternatives, ensuring we
+have a robust mechanism for deciding which of several init systems that
+may be simultaneously installed is "active" and will control the next
+boot is clearly a requirement.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 18:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 18:36:04 GMT) (full text, mbox, link).

+ +

Message #3265 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: skirpichev@gmail.com
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 18:32:48 +0000
+
+
Sergey B Kirpichev writes ("Re: Bug#727708: Bits from linux.conf.au"):
+> On Tue, Jan 14, 2014 at 06:05:47PM +0000, Ian Jackson wrote:
+> > I would expect the community for that init system to do the work.  So
+> > the burden on maintainers ought to be minimal.  All they ought to be
+> > required to do is ship the init-system-specific config thingy supplied
+> > by the community who are interested in that init system.  That might
+> > even be done by NMU so the maintainer would often not have to do
+> > anything at all.
+> 
+> Clearly, that's not the end of the job.  systemd/upstart/whatever
+> configs could be buggy as everything other.  Currently, if maintainer
+> provides sysv init script - he is responsible for related bugreports.
+> 
+> Who is responsible for supporting this in your scheme?  Or
+> systemd/upstart configs supposed to be written once and
+> work well forever?
+
+It seems to me that the community for the particular init system ought
+to fix this.  It's obviously not practical to ask the maintainer to
+debug each of these scripts.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 18:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 18:42:04 GMT) (full text, mbox, link).

+ +

Message #3270 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Bdale Garbee <bdale@gag.com>, + 727708@bugs.debian.org
+
Cc: Adrian Bunk <bunk@stusta.de>, + Steven Chamberlain <steven@pyro.eu.org>, + Thorsten Glaser <tg@mirbsd.de>, + rootlexx@mail.ru
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 18:39:31 +0000
+
+
Bdale Garbee writes ("Bug#727708: Bits from linux.conf.au"):
+> That's a great question.  I suspect most of the effort in thinking about
+> init system transitions so far has gone in to figuring out how to replace
+> sysvinit.  But if we're truly going to support alternatives, ensuring we
+> have a robust mechanism for deciding which of several init systems that
+> may be simultaneously installed is "active" and will control the next
+> boot is clearly a requirement.
+
+Yes.  I don't think this is particularly difficult, if we are
+relatively relaxed about our requirements.  (For example, we don't
+require that daemon enablement is preserved across such a transition,
+and we don't require that daemon management works properly after such
+a transition has been initiated but not yet completed by a reboot.)
+
+Or to put it another way: obviously it has to be possible for people
+to switch, but I don't think it has to be easy.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 18:42:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Dmitry Yu Okunev <dyokunev@ut.mephi.ru>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 18:42:07 GMT) (full text, mbox, link).

+ +

Message #3275 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Dmitry Yu Okunev <dyokunev@ut.mephi.ru>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 22:39:30 +0400
+
+
[Message part 1 (text/plain, inline)]
+
Hello.
+
+On 01/14/2014 10:32 PM, Ian Jackson wrote:
+> Sergey B Kirpichev writes ("Re: Bug#727708: Bits from linux.conf.au"):
+>> On Tue, Jan 14, 2014 at 06:05:47PM +0000, Ian Jackson wrote:
+>>> I would expect the community for that init system to do the work.  So
+>>> the burden on maintainers ought to be minimal.  All they ought to be
+>>> required to do is ship the init-system-specific config thingy supplied
+>>> by the community who are interested in that init system.  That might
+>>> even be done by NMU so the maintainer would often not have to do
+>>> anything at all.
+>>
+>> Clearly, that's not the end of the job.  systemd/upstart/whatever
+>> configs could be buggy as everything other.  Currently, if maintainer
+>> provides sysv init script - he is responsible for related bugreports.
+>>
+>> Who is responsible for supporting this in your scheme?  Or
+>> systemd/upstart configs supposed to be written once and
+>> work well forever?
+> 
+> It seems to me that the community for the particular init system ought
+> to fix this.  It's obviously not practical to ask the maintainer to
+> debug each of these scripts.
+
+IMHO, that means almost no support for the most of packages.
+
+-- 
+Best regards, Dmitry,
+head of UNIX-tech department NRNU MEPhI,
+tel. 8 (495) 788-56-99, add. 8255
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 18:45:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 18:45:09 GMT) (full text, mbox, link).

+ +

Message #3280 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Cc: Bdale Garbee <bdale@gag.com>, Steven Chamberlain <steven@pyro.eu.org>, + Thorsten Glaser <tg@mirbsd.de>, rootlexx@mail.ru
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 20:40:29 +0200
+
+
On Tue, Jan 14, 2014 at 06:03:33PM +0000, Ian Jackson wrote:
+> Adrian Bunk writes ("Bug#727708: Bits from linux.conf.au"):
+>...
+> > 3. Switching init systems after installation.
+> > Assume I am currently using systemd.
+> > What is supposed to happen when I do "apt-get install sysvinit-core"?
+> 
+> I think that if you want to switch init system after installation, I
+> don't mind at all if you are expected to reboot.  (With the possible
+> exception of switching away from sysvinit.)
+>...
+
+I definitely expect that you have to reboot.
+
+The tricky part is how to reboot.
+
+With a naïve Breaks/Conflicts between the different init systems you 
+would be calling the sysvinit reboot(8) with a running systemd init
+and with all files from systemd already removed.
+
+
+> Ian.
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 18:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 18:57:04 GMT) (full text, mbox, link).

+ +

Message #3285 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Adrian Bunk <bunk@stusta.de>, + 727708@bugs.debian.org
+
Cc: Bdale Garbee <bdale@gag.com>, + Steven Chamberlain <steven@pyro.eu.org>, + Thorsten Glaser <tg@mirbsd.de>, + rootlexx@mail.ru
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 18:54:43 +0000
+
+
Adrian Bunk writes ("Bug#727708: Bits from linux.conf.au"):
+> I definitely expect that you have to reboot.
+> 
+> The tricky part is how to reboot.
+> 
+> With a naïve Breaks/Conflicts between the different init systems you 
+> would be calling the sysvinit reboot(8) with a running systemd init
+> and with all files from systemd already removed.
+
+Then perhaps that's not the right answer.  Do we really need to design
+a good solution to this problem right away ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 19:06:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 19:06:09 GMT) (full text, mbox, link).

+ +

Message #3290 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 20:03:50 +0100
+
+
Le mardi 14 janvier 2014 à 11:31 -0700, Bdale Garbee a écrit :
+> > If dependencies like "installing GNOME enforces systemd as init system"
+> > would be legal, then after a few more such dependencies it would turn
+> > out that systemd will be the only option available for virtually all 
+> > users - and that all the hassle of supporting multiple init systems
+> > was a waste of effort.
+> 
+> Please be careful about stacking assumptions like this.  Equating GNOME
+> to "virtually all users" completely ignores the vast number of Debian
+> instances on servers, virtual machines, and embedded systems.  And even
+> if you only think about client systems, in my own circle of friends
+> there's a lot more XFCE4 than GNOME these days.
+
+As their maintainers have stated, Xfce4 and KDE are most likely going to
+require systemd soon.
+
+> > What is supposed to happen when I do "apt-get install sysvinit-core"?
+> 
+> That's a great question.  I suspect most of the effort in thinking about
+> init system transitions so far has gone in to figuring out how to replace
+> sysvinit.  But if we're truly going to support alternatives, ensuring we
+> have a robust mechanism for deciding which of several init systems that
+> may be simultaneously installed is "active" and will control the next
+> boot is clearly a requirement.
+
+Only one thing comes to mind when reading about supporting multiple init
+systems and how to switch between them:
+http://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html
+
+-- 
+.''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 19:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 19:21:04 GMT) (full text, mbox, link).

+ +

Message #3295 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 11:19:38 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Jan 14, 2014 at 08:03:50PM +0100, Josselin Mouette wrote:
+> Le mardi 14 janvier 2014 à 11:31 -0700, Bdale Garbee a écrit :
+> > > If dependencies like "installing GNOME enforces systemd as init system"
+> > > would be legal, then after a few more such dependencies it would turn
+> > > out that systemd will be the only option available for virtually all 
+> > > users - and that all the hassle of supporting multiple init systems
+> > > was a waste of effort.
+
+> > Please be careful about stacking assumptions like this.  Equating GNOME
+> > to "virtually all users" completely ignores the vast number of Debian
+> > instances on servers, virtual machines, and embedded systems.  And even
+> > if you only think about client systems, in my own circle of friends
+> > there's a lot more XFCE4 than GNOME these days.
+
+> As their maintainers have stated, Xfce4 and KDE are most likely going to
+> require systemd soon.
+
+There has been no such statement from the XFCE maintainers in this
+discussion.
+
+And all such statements are mere parroting of systemd upstream propaganda.
+The interfaces that desktops require do not dictate an init system.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 19:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 19:30:04 GMT) (full text, mbox, link).

+ +

Message #3300 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Bdale Garbee <bdale@gag.com>
+
Cc: 727708@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>, + Steven Chamberlain <steven@pyro.eu.org>, + Thorsten Glaser <tg@mirbsd.de>, rootlexx@mail.ru
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 21:27:41 +0200
+
+
On Tue, Jan 14, 2014 at 11:31:09AM -0700, Bdale Garbee wrote:
+> Adrian Bunk <bunk@stusta.de> writes:
+>...
+> > If dependencies like "installing GNOME enforces systemd as init system"
+> > would be legal, then after a few more such dependencies it would turn
+> > out that systemd will be the only option available for virtually all 
+> > users - and that all the hassle of supporting multiple init systems
+> > was a waste of effort.
+> 
+> Please be careful about stacking assumptions like this.  Equating GNOME
+> to "virtually all users" completely ignores the vast number of Debian
+> instances on servers, virtual machines, and embedded systems.  And even
+> if you only think about client systems, in my own circle of friends
+> there's a lot more XFCE4 than GNOME these days.
+
+That's why I wrote "after a few more such dependencies":
+GNOME is only the first case, and likely not the last case.
+
+When thinking about worst cases, I wonder how many non-systemd users 
+would be left if udev (part of the systemd sources) would ever get a 
+dependency on systemd being the init system...
+
+
+If you want to support multiple init systems, then something like Ian's 
+proposal is really needed. And unless I misread it, that implies e.g. 
+that Debian would also have to provide GNOME for people not using 
+systemd as init system.
+
+
+>...
+> Bdale
+
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 19:54:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 19:54:05 GMT) (full text, mbox, link).

+ +

Message #3305 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Tue, 14 Jan 2014 11:50:22 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> And all such statements are mere parroting of systemd upstream
+> propaganda.  The interfaces that desktops require do not dictate an init
+> system.
+
+Please extend to your fellow Debian developers the courtesy of assuming
+that they arrive at their personal positions with the same care and
+thought that you use to arrive at yours.
+
+You may believe that they're wrong; that's fine, and by all means debate
+the point.  But dismissing the opinions of other Debian developers as
+"parroting" or implying that they have not done any of their own research
+or drawn any of their own conclusions is arguing in bad faith.  It's far
+more likely that they are simply weighing future risks differently than
+you are, or performing different cost/benefit analyses.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 14 Jan 2014 21:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to skirpichev@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 14 Jan 2014 21:42:04 GMT) (full text, mbox, link).

+ +

Message #3310 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sergey B Kirpichev <skirpichev@gmail.com>
+
To: 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Wed, 15 Jan 2014 01:38:36 +0400
+
+
On Tue, Jan 14, 2014 at 06:32:48PM +0000, Ian Jackson wrote:
+> It seems to me that the community for the particular init system ought
+> to fix this.  It's obviously not practical to ask the maintainer to
+> debug each of these scripts.
+
+And who is supposed to redirect the problem to the right
+community?  User?  Maintainer?  Keep in mind that problems
+may be not easily debuggable and not trivial in general.
+
+Should I just ask user if he/she uses upstart/systemd and
+if so - just reassign bugreport to the right community?
+
+Everything more then this - will take maintainer's
+time more or less.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 15 Jan 2014 10:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Martin Pitt <mpitt@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 15 Jan 2014 10:39:05 GMT) (full text, mbox, link).

+ +

Message #3315 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Martin Pitt <mpitt@debian.org>
+
To: Bdale Garbee <bdale@gag.com>, + Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Wed, 15 Jan 2014 11:36:49 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Bdale Garbee [2014-01-13 13:57 -0700]:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> 
+> > I'm coming round to the view that we should be planning to support
+> > multiple systems indefinitely.
+> 
+> This has been my opinion all along.  Various assertions that it's
+> somehow just too hard really haven't swayed me.  The tricky bit, I
+> think, is to define just what "support" means in the context of
+> non-default init systems.  
+
+I think that would be the worst possible (non-)decision that could be
+made. We already have more than enough bugs in Debian; officially
+trying to support 3 init systems is going to end up being a
+combinatorial explosion of testing and bugs, for no obvious benefit
+for the user ("pick your set of bugs").
+
+It's not realistic for a maintainer to continuously test three init
+systems; it's not realistic for a porter to continously test startup
+scripts for thousands of packages. So "I would expect the community
+for that init system to do the work" is not a plan; it's a vague hope
+at best and not realistic at all in my opinion.
+
+Martin
+
+-- 
+Martin Pitt                        | http://www.piware.de
+Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 15 Jan 2014 21:09:18 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Joerg Jaspert <joerg@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 15 Jan 2014 21:09:18 GMT) (full text, mbox, link).

+ +

Message #3320 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Joerg Jaspert <joerg@debian.org>
+
To: Bdale Garbee <bdale@gag.com>
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Wed, 15 Jan 2014 22:01:07 +0100
+
+
[Message part 1 (text/plain, inline)]
+
+>> I'm coming round to the view that we should be planning to support
+>> multiple systems indefinitely.
+> This has been my opinion all along.  Various assertions that it's
+> somehow just too hard really haven't swayed me.  The tricky bit, I
+> think, is to define just what "support" means in the context of
+> non-default init systems.  
+
+Too hard is a lousy defined thing. But it is an enormous amount of extra
+work added to all maintainers of packages with init $things. They
+basically get pressed into maintaining three widely different ways of
+starting their daemons.
+
+It's nice to say "community of $system will support it", but does anyone
+really believe that whichever of the X (currently 3) communities commit
+to maintain their systems init $things in all our packages? Maybe in a
+very ideal world, but thats not where we are in.
+
+Likewise I think one can forget the porters of an arch to do so.
+
+The only way, IMO, to really support this way would be to come up with
+something like our menu support. The maintainer puts a metafile
+somewhere, triggers let the installed init system know there is
+something new, and it converts that metadata into a working init $thing.
+
+And the maintainers of init systems have to, similar like the window
+manager ones had to, come up with the converter metadata -> init $thing.
+
+And yes, I realize that lets a lot to be desired. Starting with "WTH to
+do with software that really needs one over the other systems?" and a
+lot more points, which all had been mentioned times and again.
+
+As much as it may be hated, a clean decision "this is it, the rest is
+officially not supported", no matter for which of the candidates the
+decision goes, is IMO the best for the project longterm.
+
+-- 
+bye, Joerg
+Ubuntu: An ancient african word meaning "I can't configure Debian"
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 15 Jan 2014 21:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Yves-Alexis Perez <corsac@corsac.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 15 Jan 2014 21:21:04 GMT) (full text, mbox, link).

+ +

Message #3325 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Yves-Alexis Perez <corsac@corsac.net>
+
To: Steve Langasek <vorlon@debian.org>, Josselin Mouette <joss@debian.org>
+
Cc: 727708@bugs.debian.org, pkg-xfce-devel@lists.alioth.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Wed, 15 Jan 2014 22:17:17 +0100
+
+
On Tue, Jan 14, 2014 at 11:19:38AM -0800, Steve Langasek wrote:
+> On Tue, Jan 14, 2014 at 08:03:50PM +0100, Josselin Mouette wrote:
+> > Le mardi 14 janvier 2014 à 11:31 -0700, Bdale Garbee a écrit :
+> > > > If dependencies like "installing GNOME enforces systemd as init system"
+> > > > would be legal, then after a few more such dependencies it would turn
+> > > > out that systemd will be the only option available for virtually all 
+> > > > users - and that all the hassle of supporting multiple init systems
+> > > > was a waste of effort.
+> 
+> > > Please be careful about stacking assumptions like this.  Equating GNOME
+> > > to "virtually all users" completely ignores the vast number of Debian
+> > > instances on servers, virtual machines, and embedded systems.  And even
+> > > if you only think about client systems, in my own circle of friends
+> > > there's a lot more XFCE4 than GNOME these days.
+> 
+> > As their maintainers have stated, Xfce4 and KDE are most likely going to
+> > require systemd soon.
+> 
+> There has been no such statement from the XFCE maintainers in this
+> discussion.
+
+If you're really interested in the opinion of Xfce maintainers, it might
+be wise to add us to CC:. I try to look at the bug from time to time,
+but there's simply too much mails and it's running for too long, I just
+can't follow.
+
+I've added the pkg-xfce mailing list for that subthread, please keep
+things Xfce-related and drop the pkg-xfce list when needed.
+
+About systemd. Right now, Xfce in unstable doesn't have any systemd
+specific support. Actually, Xfce is pretty much unrelated to the init
+system.
+
+What Xfce uses right now is actually the PolicyKit/ConsoleKit, in order to manage:
+
+- power events in xfce4-power-manager (lid switch, power button)
+- power actions in xfce4-power-manager and xfce4-session (suspend,
+  hibernate, shutdown/reboot), using upower
+- volume management (USB keys etc.) in Thunar and xfdesktop4, through
+  gvfs and udisks
+
+*Right now*, it's perfectly possible to use Xfce without consolekit
+installed, but you will lose the above features (for shutdown and reboot
+there's actually a shutdown helper which can be run through sudo).
+
+Now, as far as I understand it, PolicyKit/ConsoleKit are unmaintained,
+and the recommended alternative is to use logind. That means in the
+future, it's likely that upstream Xfce will have to move away from
+consolekit. That's not something they really like, considering the
+support was added not so long ago, but there's not much choice, unless
+someone wants to maintain consolekit in the long run. And it seems that
+the only choice right now is to go with logind.
+
+No patch have already been merged for that, but there are patches for
+various components (xfce4-power-manager and xfce4-session mostly, since
+for Thunar it's actually done in gvfs and/or udisks, so we won't have a
+choice anyway). 
+
+Those patches have mostly been contributed by distros who already use
+systemd/logind and have dropped consolekit, so they want the nice
+features back and a consistent environment. Right now I've refrained to
+integrate and upload them because I'm still waiting for the tech-ctte to
+decide on the issue.
+
+Because in the end (as I guess it's been already said multiple times on
+this bug), even though the stuff we'll most likely require in the future
+is in logind, it seems that there'll be no way to use it without systemd
+post-204 (but I might be wrong). And I have no idea what's the Xubuntu
+plan.
+
+TL;DR
+
+ it's most likely Xfce upstream will move from consolekit to logind (and
+thus systemd) at one point. Not because they really like it, but because
+indeed everyone else is moving to it, and there's simply not enough
+manpower to rebuild the whole freedesktop.org stack. I hope (and some
+people in the Xfce developers community too) it won't be a hard
+dependency, and I guess it's likely that a non-logind Xfce will continue
+to work the same as a non-consolekit Xfce right now.
+
+Regards,
+-- 
+Yves-Alexis
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 15 Jan 2014 21:39:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 15 Jan 2014 21:39:05 GMT) (full text, mbox, link).

+ +

Message #3330 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: 727708@bugs.debian.org
+
Cc: Joerg Jaspert <joerg@debian.org>
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Wed, 15 Jan 2014 21:35:15 +0000
+
+
[Message part 1 (text/plain, inline)]
+
On 15/01/14 21:01, Joerg Jaspert wrote:
+> Likewise I think one can forget the porters of an arch to do so.
+> [...]
+> As much as it may be hated, a clean decision "this is it, the rest is
+> officially not supported" [...]
+
+If the decision were something like that, and only systemd were
+officially supported, don't expect porters of non-Linux arches to down
+tools and give up.  We may have to drop lots of stuff if we can't get it
+working without systemd.  But I expect we'd still put out a release
+(official or not) with some other compatible init system and our own
+init scripts for whatever we have to.
+
+I also think some people would care enough about running GNU/Linux
+without systemd, that we could combine our efforts in that case.
+
+I'd like to know as soon as possible if non-Linux ports ought to focus
+efforts on our existing SysV init, switching to OpenRC, or be trying to
+port Upstart.  I'm personally undecided and the tech-ctte decision could
+easily sway my opinion on this.
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 15 Jan 2014 21:45:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to nisse@lysator.liu.se (Niels Möller):
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 15 Jan 2014 21:45:07 GMT) (full text, mbox, link).

+ +

Message #3335 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: nisse@lysator.liu.se (Niels Möller)
+
To: Martin Pitt <mpitt@debian.org>
+
Cc: 727708@bugs.debian.org, Bdale Garbee <bdale@gag.com>, + Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Wed, 15 Jan 2014 22:34:06 +0100
+
+
Martin Pitt <mpitt@debian.org> writes:
+
+> I think that would be the worst possible (non-)decision that could be
+> made. We already have more than enough bugs in Debian; officially
+> trying to support 3 init systems is going to end up being a
+> combinatorial explosion of testing and bugs, for no obvious benefit
+> for the user ("pick your set of bugs").
+
+One of the init systems is the *default*, and that's likely the only one
+that will see testing and quality that is up to debian's standards.
+
+Users should not select a non-default init system lightly. I think it's
+going to be a bit like using the "non-default" kfreebsd or hurd kernel.
+It's not for the average user who wants as much software as possible to
+work as well as possible. It's for the user who is curious, or really
+likes to use or hack that piece of software, or maybe hopes that it's
+going to replace the current default component sometime in the future.
+
+Then there are differences of course. On one hand, I imagine both
+upstart and systemd are more mature than the hurd, and they definitely
+have more users. And on the other hand, the needed porting to get a
+random daemon to work well with a new init system might be slightly more
+work than for porting the same random daemon to work on the hurd or
+kfreebsd.
+
+(And it's going to be at least 4 init systems, not 3, right? systemd,
+upstart, sysv and openrc. With support for sysv possibly dropped after a
+few release cycles).
+
+Regards,
+/Niels
+
+-- 
+Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
+Internet email is subject to wholesale government surveillance.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 15 Jan 2014 21:51:03 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 15 Jan 2014 21:51:03 GMT) (full text, mbox, link).

+ +

Message #3340 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: nisse@lysator.liu.se (Niels Möller)
+
Cc: 727708@bugs.debian.org, Martin Pitt <mpitt@debian.org>
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Wed, 15 Jan 2014 13:48:50 -0800
+
+
nisse@lysator.liu.se (Niels Möller) writes:
+
+> (And it's going to be at least 4 init systems, not 3, right? systemd,
+> upstart, sysv and openrc. With support for sysv possibly dropped after a
+> few release cycles).
+
+If OpenRC proves to be of broad interest and becomes supported, at least
+at the non-default level, I doubt we would continue to support sysv
+without OpenRC for very long (quite possibly not even in jessie+1).  My
+impression is that OpenRC provides a strict superset of sysv init script
+features in a way that's backwards-compatible, so the upgrade path from
+sysvinit only to sysvinit with OpenRC should be fairly smooth.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 15 Jan 2014 22:21:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 15 Jan 2014 22:21:10 GMT) (full text, mbox, link).

+ +

Message #3345 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Wed, 15 Jan 2014 22:17:01 +0000
+
+
On 15/01/14 21:48, Russ Allbery wrote:
+> If OpenRC proves to be of broad interest and becomes supported, at least
+> at the non-default level, I doubt we would continue to support sysv
+> without OpenRC for very long [...] the upgrade path from
+> sysvinit only to sysvinit with OpenRC should be fairly smooth.
+
+I do hope for something like this.  Continuing to support SysV doesn't
+have to be a requirement.  A comfortable transition away from SysV
+initscripts is possible, as long as native init definitions are provided
+for the official init system[s], and for whatever the ports have.
+(That's also why GNU/kFreeBSD and Hurd ought to pick the same).
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 04:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 04:27:04 GMT) (full text, mbox, link).

+ +

Message #3350 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Wed, 15 Jan 2014 20:25:52 -0800
+
+
Martin Pitt <mpitt@debian.org> writes:
+> Bdale Garbee [2014-01-13 13:57 -0700]:
+>> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+>> 
+>> > I'm coming round to the view that we should be planning to support
+>> > multiple systems indefinitely.
+>> 
+>> This has been my opinion all along.  Various assertions that it's
+>> somehow just too hard really haven't swayed me.  The tricky bit, I
+>> think, is to define just what "support" means in the context of
+>> non-default init systems.  
+>
+> I think that would be the worst possible (non-)decision that could be
+> made. We already have more than enough bugs in Debian; officially
+> trying to support 3 init systems is going to end up being a
+> combinatorial explosion of testing and bugs, for no obvious benefit
+> for the user ("pick your set of bugs").
+
+
+I think it would be helpful for the discussion if people would first
+define what they mean with "support" (and "default"), and then discuss
+whether it's desirable or not.
+
+Support could mean anything from "packages not shipping init scripts
+using the full functionality of each available init systems are not
+accepted to the archive" to "packages of alternate init systems are
+allowed in the archieve, but integration has to be done completely by
+the local administrator".
+
+I'm pretty sure most people's opinions on whether Debian should support
+multiple init systems would be quite different for those two cases. 
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 06:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Martin Pitt <mpitt@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 06:06:04 GMT) (full text, mbox, link).

+ +

Message #3355 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Martin Pitt <mpitt@debian.org>
+
To: Yves-Alexis Perez <corsac@corsac.net>
+
Cc: 727708@bugs.debian.org, pkg-xfce-devel@lists.alioth.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Thu, 16 Jan 2014 07:04:05 +0100
+
+
Hey Yves-Alexis,
+
+Yves-Alexis Perez [2014-01-15 22:17 +0100]:
+> Now, as far as I understand it, PolicyKit/ConsoleKit are unmaintained,
+> and the recommended alternative is to use logind.
+
+To clarify, ConsoleKit has been deprecated for a while, and logind is
+the official successor (and roughly equivalent in terms of what a
+desktop environment needs from it). polkit is a different beast and is
+*not* deprecated; it has been switched over to use logind for checking
+"is that process on an active foreground console", which it previously
+used ConsoleKit for.
+
+Martin
+-- 
+Martin Pitt                        | http://www.piware.de
+Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 06:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Martin Pitt <mpitt@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 06:12:05 GMT) (full text, mbox, link).

+ +

Message #3360 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Martin Pitt <mpitt@debian.org>
+
To: Niels Möller <nisse@lysator.liu.se>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Thu, 16 Jan 2014 07:09:37 +0100
+
+
Niels Möller [2014-01-15 22:34 +0100]:
+> Users should not select a non-default init system lightly. I think it's
+> going to be a bit like using the "non-default" kfreebsd or hurd kernel.
+> It's not for the average user who wants as much software as possible to
+> work as well as possible. It's for the user who is curious, or really
+> likes to use or hack that piece of software, or maybe hopes that it's
+> going to replace the current default component sometime in the future.
+
+That's not something I'd call "supported" then. So either that
+non-default init system does get a certain amount of  interest, and
+many maintainers add an init script for that system to their packages
+-- then there's the additional maintenance/testing/subpar quality
+problem for that. Or they don't, and then having that init system
+doesn't make much sense in the first place.
+
+> (And it's going to be at least 4 init systems, not 3, right? systemd,
+> upstart, sysv and openrc. With support for sysv possibly dropped after a
+> few release cycles).
+
+There's no practical way to drop sysv of course, at least as long as
+we have non-Linux ports. So this is already 2, and that at least still
+has some technical justification. But having more than $DEFAULT and
+sysv just boils down to "we can't make a decision".
+
+Martin
+
+-- 
+Martin Pitt                        | http://www.piware.de
+Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 07:45:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Emilio Pozuelo Monfort <pochu@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 07:45:14 GMT) (full text, mbox, link).

+ +

Message #3365 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Emilio Pozuelo Monfort <pochu@debian.org>
+
To: Yves-Alexis Perez <corsac@corsac.net>, 727708@bugs.debian.org
+
Cc: Steve Langasek <vorlon@debian.org>, + Josselin Mouette <joss@debian.org>, + pkg-xfce-devel@lists.alioth.debian.org
+
Subject: Re: Bug#727708: Xfce & logind
+
Date: Thu, 16 Jan 2014 08:38:47 +0100
+
+
On 15/01/14 22:17, Yves-Alexis Perez wrote:
+> Now, as far as I understand it, PolicyKit/ConsoleKit are unmaintained,
+> and the recommended alternative is to use logind. That means in the
+> future, it's likely that upstream Xfce will have to move away from
+> consolekit. That's not something they really like, considering the
+> support was added not so long ago, but there's not much choice, unless
+> someone wants to maintain consolekit in the long run. And it seems that
+> the only choice right now is to go with logind.
+> 
+> No patch have already been merged for that, but there are patches for
+> various components (xfce4-power-manager and xfce4-session mostly, since
+> for Thunar it's actually done in gvfs and/or udisks, so we won't have a
+> choice anyway). 
+
+Maybe I've misunderstood what you mean there, but xfce4-session had logind
+support merged[1] a while ago, though consolekit support is still there and you
+can choose to build one or the other.
+
+Cheers,
+Emilio
+
+[1]
+http://git.xfce.org/xfce/xfce4-session/commit/?id=ae28aef315a7a6b90f1649ce6d1f30b842791cbf
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 08:12:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Yves-Alexis Perez <corsac@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 08:12:11 GMT) (full text, mbox, link).

+ +

Message #3370 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Yves-Alexis Perez <corsac@debian.org>
+
To: Emilio Pozuelo Monfort <pochu@debian.org>
+
Cc: 727708@bugs.debian.org, Steve Langasek <vorlon@debian.org>, + Josselin Mouette <joss@debian.org>, + pkg-xfce-devel@lists.alioth.debian.org
+
Subject: Re: Bug#727708: Xfce & logind
+
Date: Thu, 16 Jan 2014 09:08:48 +0100
+
+
On Thu, Jan 16, 2014 at 08:38:47AM +0100, Emilio Pozuelo Monfort wrote:
+> On 15/01/14 22:17, Yves-Alexis Perez wrote:
+> > Now, as far as I understand it, PolicyKit/ConsoleKit are unmaintained,
+> > and the recommended alternative is to use logind. That means in the
+> > future, it's likely that upstream Xfce will have to move away from
+> > consolekit. That's not something they really like, considering the
+> > support was added not so long ago, but there's not much choice, unless
+> > someone wants to maintain consolekit in the long run. And it seems that
+> > the only choice right now is to go with logind.
+> > 
+> > No patch have already been merged for that, but there are patches for
+> > various components (xfce4-power-manager and xfce4-session mostly, since
+> > for Thunar it's actually done in gvfs and/or udisks, so we won't have a
+> > choice anyway). 
+> 
+> Maybe I've misunderstood what you mean there, but xfce4-session had logind
+> support merged[1] a while ago, though consolekit support is still there and you
+> can choose to build one or the other.
+
+Yeah actually it was mostly about xfpm.
+
+Also note that it's not yet released, and that the upload issue still
+stands.  Unless there's a runtime detection (like some of the proposed
+patches for xfpm), logind support is not something I can really upload
+until the tech-ctte has made its decision.
+
+Regards,
+-- 
+Yves-Alexis
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 09:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 09:06:04 GMT) (full text, mbox, link).

+ +

Message #3375 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Martin Pitt <mpitt@debian.org>, 727708@bugs.debian.org
+
Cc: Bdale Garbee <bdale@gag.com>, Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Thu, 16 Jan 2014 19:03:37 +1000
+
+
On 15 January 2014 20:36, Martin Pitt <mpitt@debian.org> wrote:
+> It's not realistic for a maintainer to continuously test three init
+> systems;
+
+It's not realistic for a maintainer to continuously test against 13
+architectures (including three different kernel trees) either. So we
+don't do that and instead let maintainers make their best effort when
+packaging, expect them to test locally, and then rely on porters and
+users to report bugs when there are problems.
+
+> it's not realistic for a porter to continously test startup
+> scripts for thousands of packages.
+
+It's reasonable to semi-continuously test installation scripts for
+thousands of packages -- that's what piuparts does, and we have
+sponsored cloud resources to support that. It seems like that would be
+fairly straightforward to duplicate for testing packages with
+alternative init systems.
+
+Cheers,
+aj
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 12:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 12:15:05 GMT) (full text, mbox, link).

+ +

Message #3380 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: 727708@bugs.debian.org
+
Cc: Martin Pitt <mpitt@debian.org>, aj@erisian.com.au
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Thu, 16 Jan 2014 12:12:11 +0000
+
+
On 16/01/14 06:09, Martin Pitt wrote:
+> There's no practical way to drop sysv of course, at least as long as
+> we have non-Linux ports.
+
+If maintainers are particularly keen to drop support for SysV, that
+encourages porters to go with either OpenRC or a port of Upstart.
+
+Then you could drop SysV support as long as your package has a native
+init definition for whichever of those is used on ports.  Porters could
+test or even write that for you.
+
+On 16/01/14 09:03, Anthony Towns wrote:
+> It's reasonable to semi-continuously test installation scripts for
+> thousands of packages -- that's what piuparts does
+
+The modern init systems likely have a clearer idea of whether the daemon
+started successfully or not, so this seems to make sense.  If tests can
+be run on every port, that would also catch daemon startup bugs that are
+not even due to the init script.
+
+A really nice dashboard may also show a diff of changes in the default
+init script, to keep track of when the others might need updating.
+Maybe that's similar to how translators' work is done.
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 15:39:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 15:39:09 GMT) (full text, mbox, link).

+ +

Message #3385 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Init system resolution open questions
+
Date: Thu, 16 Jan 2014 15:35:53 +0000
+
+
I think what we need to decide at the meeting later today is:
+
+ * Are we ready to make a decision ?
+
+ * If anyone is not, what other information/research/etc. is required
+   and how long will that take ?
+
+ * If we are ready, what resolution texts should we be voting on ?
+
+ * If we are ready, can we set a timetable for the vote itself to make
+   sure that we hold the voting period during a time when everyone is
+   going to be available ?  (Constitutionally we can't extend the
+   voting period, and it is IMO important that as many TC members as
+   possible cast votes.)
+
+I'm hoping that the answer to the first question is "yes".  I'm happy
+to draft all the versions for everyone, although obviously every TC
+member is entitled to propose a resolution of their own.
+
+There are a number of questions on which TC members have so far
+expressed diverging views, or at least the answers aren't clear:
+
+Q1 (Obviously) What should be the default in jessie ?
+
+Q2 Should we declare an intent to support multiple systems for the
+   foreseeable future ?
+
+Q3 Should we issue guidance on what kind of changes ought to be
+   accepted by maintainers ?  In particular, should we explicitly lay
+   out certain objections as _not_ good reasons for a maintainer to
+   accept an init system patch and what should be on that list of
+   non-objections ?
+
+Q4 Do we want to retain some comment along the lines of my current
+   draft's s11 "Replacement of existing functionality".
+
+The combinatorial matrix of all these options, even after we drop any
+that don't have significant support, is going to be too unweildy.  We
+mustn't vote on each question independently because people's views
+might intertwine the issues.
+
+My initial suggestion would be:
+
+Firstly, Q4 could be separated out as genuinely independent.  If there is
+support for such a statement, it can come as a separate resolution.
+
+Regarding Q1-3 and other objections that arise from my drafts:
+constitutionally we put anything on the ballot that any TC member
+proposes.  I suggest that TC members should request for combinations
+to be on the ballot if either (a) that combination is anyone's
+preferred outcome or (b) it makes a plausible compromise between some
+other pair of proposed options.
+
+Does that make sense ?
+
+Ian.
+
+PS: After I've found out what versions people care about, I'm tempted
+to turn my draft into something that can be automatically converted
+into various versions...
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 15:48:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 15:48:05 GMT) (full text, mbox, link).

+ +

Message #3390 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Martin Pitt <mpitt@debian.org>, 727708@bugs.debian.org, Niels + Möller <nisse@lysator.liu.se>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Thu, 16 Jan 2014 08:44:24 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Martin Pitt <mpitt@debian.org> writes:
+
+> But having more than $DEFAULT and
+> sysv just boils down to "we can't make a decision".
+
+I understand your point, but the more I learn about OpenRC the more
+likely it seems to me that supporting it as an enhancement of sysvinit
+makes sense as the "other" init system than just sysvinit alone.
+
+Whether you choose to think of that as meaning we have 3 or 2 after a
+transition interval is debatable.
+
+If your real point is "pick systemd *or* upstart and don't try to
+assert that we should support both", I can easily agree with that.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 16:09:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Martin Pitt <mpitt@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 16:09:13 GMT) (full text, mbox, link).

+ +

Message #3395 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Martin Pitt <mpitt@debian.org>
+
To: Bdale Garbee <bdale@gag.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Thu, 16 Jan 2014 17:04:35 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Bdale Garbee [2014-01-16  8:44 -0700]:
+> > But having more than $DEFAULT and
+> > sysv just boils down to "we can't make a decision".
+> 
+> I understand your point, but the more I learn about OpenRC the more
+> likely it seems to me that supporting it as an enhancement of sysvinit
+> makes sense as the "other" init system than just sysvinit alone.
+
+Yes, I actually meant "SysV init scripts", not necessarily the SysV
+init package itself; OpenRC still works with SysV init scripts AFAIUI,
+so from the point of view of package maintainers it doesn't lead to
+duplication in the same way as "provide an upstart script AND a
+systemd unit AND a SysV init script does".
+
+> Whether you choose to think of that as meaning we have 3 or 2 after a
+> transition interval is debatable.
+
+Right, and I don't want to quibble over that. In that sense we already
+support classic sysvinit and startpar, but they don't use different
+startup scripts in packages.
+
+> If your real point is "pick systemd *or* upstart and don't try to
+> assert that we should support both", I can easily agree with that.
+
+That indeed is my main point.
+
+Thanks!
+
+Martin
+-- 
+Martin Pitt                        | http://www.piware.de
+Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 16:21:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 16:21:14 GMT) (full text, mbox, link).

+ +

Message #3400 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Thu, 16 Jan 2014 17:18:24 +0100
+
+
Le jeudi 16 janvier 2014 à 08:44 -0700, Bdale Garbee a écrit : 
+> I understand your point, but the more I learn about OpenRC the more
+> likely it seems to me that supporting it as an enhancement of sysvinit
+> makes sense as the "other" init system than just sysvinit alone.
+
+This assumes that OpenRC can be fixed to have parallel boot, otherwise
+this is a big regression from the current insserv setup. 
+
+> If your real point is "pick systemd *or* upstart and don't try to
+> assert that we should support both", I can easily agree with that.
+
+Amen.
+
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 16:39:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 16:39:10 GMT) (full text, mbox, link).

+ +

Message #3405 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Upstart running on GNU/kFreeBSD
+
Date: Thu, 16 Jan 2014 16:36:46 +0000
+
+
[Message part 1 (text/plain, inline)]
+
James Hunt just let us know they have Upstart running on GNU/kFreeBSD -
+although not yet doing the /etc/rcS.d early boot tasks like remount root
+filesystem read-rewrite - it's a fairly significant development:
+
+https://lists.ubuntu.com/archives/upstart-devel/2014-January/003010.html
+
+AFAIK neither OpenRC nor Upstart have been ported to GNU/Hurd yet, but
+I'd guess at least one of them could be ported in time for jessie.
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 17:57:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 17:57:09 GMT) (full text, mbox, link).

+ +

Message #3410 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: On diversity
+
Date: Thu, 16 Jan 2014 17:52:48 +0000
+
+
What is Debian ?  In one respect, Debian is an operating system.  And
+of course in another respect Debian is a community.
+
+But there are two other aspects of Debian's nature that have been very
+important for our success:
+
+* Debian is a forum for cooperation and technical development.
+
+  Specifically Debian is a place where if you have some particular
+  goals, you can find other like-minded people and collaborate with
+  them to achieve them.  Even if others in the project don't
+  necessarily think those goals are important.
+
+  (I remember when I was very dismissive of the idea that
+  cross-building Debian would ever be feasible or useful.  I was
+  wrong; but more importantly, the fact that I - and some others -
+  thought that way was no blocker to those who wanted to the work.)
+
+* Debian, as a piece of software, tries to be all things to all
+  people (within reason).
+
+  That is, the software we ship is both a working system, but also a
+  template, including all the pieces, for making your own operating
+  system, the way you want it.
+
+  This may mean that everything we do is slightly less slick in the
+  "usual" case, but I think the value of that flexibility massively
+  outweighs the costs.  If others want to derive from us and make
+  more specific choices then that's good, but we should truly aim to
+  be as universal an upstream distro as we can be.
+
+These two things are very closely related; arguably they are aspects
+of the same principles.
+
+We are reluctant to commit to any particular way of doing things;
+reluctant to declare other people's goals out of our scope; and
+reluctant to tell our users and downstreams that things Will Be Done
+in a particular way.  We make those firm choices only when absolutely
+necessary.
+
+This flexibility and tolerance for divergence has made Debian an
+extremely attractive target for everyone to work within, work on, and
+derive from.  I think it has been key to the success of the project.
+
+Of course all this diversity brings substantial distribution-wide
+costs.  We do regularly struggle with issues where a particular goal
+imposes costs on packages, and we try to minimise that.
+
+But the flipside is that this acceptance for others' goals and choices
+brings those people into our community, providing us with the manpower
+we have used to build the best, the most flexible, and the most
+derived-from Free Software operating system in the world.
+
+I passionately believe that we need to retain this aspect of our
+community, even if that causes us extra work; and even if it causes
+friction with those who would like to make the world nice and simple
+by only supporting certain goals, certain use cases, or certain
+software.
+
+
+Now let me apply that to init systems:
+
+If you think that the difference between upstart and systemd, or
+between either of those and systemd, is not important, then perhaps
+you could conclude that it was OK to impose a particular decision on
+all of our users and all of our downstreams.
+
+But I think the differences /are/ important.
+
+That means that we need to be the venue where systemd proponents, and
+upstart proponents, and openrc proponents, can make the best system
+they can.
+
+Naturally that will involve some compromises.  That's an unavoidable
+cost of trying to be the best place for everyone to pursue their own
+goals.
+
+I think in this case those compromises are absolutely essential.  Not
+just from a technical point of view because of the advantages of one
+system over another.  But also to ensure that Debian continues to be
+the place where serious and dynamic people come to do their stuff.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 17:57:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 17:57:12 GMT) (full text, mbox, link).

+ +

Message #3415 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: On diversity
+
Date: Thu, 16 Jan 2014 17:55:03 +0000
+
+
Ian Jackson writes ("On diversity"):
+> If you think that the difference between upstart and systemd, or
+> between either of those and systemd, is not important, then perhaps
+                              ^^^^^^^
+Should read sysvinit.  Bah, etc.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 18:06:46 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 18:06:47 GMT) (full text, mbox, link).

+ +

Message #3420 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Thu, 16 Jan 2014 09:59:14 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> Andreas, Bdale, Don, Keith: please let us know what you're thinking,
+> and what more information/discussion would be useful.
+
+As the newest TC member, I hope to emulate my learned colleagues and try
+to keep the discussion moving in a positive direction.
+
+First off, my personal interest and experience with init has been
+limited; starting off my Unix life doing system administration on a
+PDP-11 running V7 and then 2.7 BSD, and then rapidly escaping into
+desktop system software development has never made me comfortable with
+our current sysvinit-based systems. I suspect I've spent more time in
+the last six months exploring this space than I did in the previous 32
+years of Unix experience...
+
+As with any core system component, I believe we need to find a solution
+which best meets the following goals:
+
+ 1) Technical excellence.
+
+ 2) Support for the whole Debian community.
+
+ 3) Sharing with other Linux communities.
+
+Sometimes it is possible to find a single solution which is obviously
+the best in all of these areas, but in this case, we will need to
+compromise -- none of the proposed solutions ranks number one in all
+three areas.
+
+Because of the central nature of pid 1, and influenced by experiences
+like that expressed by Marc Merlin, I believe that Debian will need to
+support multiple init systems going forward, even on Linux.
+
+However, on Linux, I believe that the vast majority of Debian users
+would be best served by encouraging them to use systemd by making that
+the default.
+
+systemd is being developed by a broad cross-distribution community who
+are solving long-standing technical issues with how subsystems are
+managed within the Linux environment. Yes, there are technical issues
+with using systemd in a Debian environment, but I don't see any of them
+as significant blockers, and only by contributing our expertise can we
+expect them to be resolved in the best way.
+
+In contrast, upstart has a developer community limited to Canonical
+employees and others who are able and willing to sign the onerous CLA
+associated with that software. I believe as a result, upstart
+development has flagged and now lags far behind systemd in several key
+areas.
+
+I would like to encourage the OpenRC community to continue working on
+their most excellent system though; I feel like it has a great place as
+a simpler and more portable system for use in environments like that
+described by Marc Merlin in his LCA talk discussed here recently, as
+well as in non-Linux environments.
+
+Thanks to Ian, Russ and Bdale for offering their opinions on this
+matter, it's certainly helped focus my thoughts on the one or two key
+points that matter most to me. And, thanks to Steve for creating a
+couple of virtual hosts for me to play with both upstart and systemd.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 19:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 19:15:05 GMT) (full text, mbox, link).

+ +

Message #3425 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Thu, 16 Jan 2014 19:12:54 +0000
+
+
It turns out that we aren't quite ready.  Don and Andreas say they
+will reply with their views by the end of the weekend.
+
+In particular we aren't settled on the support/enforcement/
+requirement/status of the various sytems on the various platforms.
+
+AFAICT we are all agreed that:
+
+* sysv support needs to remain mandatory (RC-buggy if missing) in
+  jessie.
+
+* Applications which aren't part of the init system must not require a
+  particular init to be pid 1.  (So in particular a desktop
+  environment may not require a particular pid 1.)
+
+As I mentioned on IRC, I think we need to get some clear answers to
+certain questions from everybody.
+
+* For which init systems should there be a low nmu threshold for
+  native support in packages ?
+
+* Daemon package maintainers should accept reasonable patches for
+  some set of init systems.  Which init systems ?
+
+* What opinions do we state for jessie+1 - are we hoping for one or
+  two systems (which two), or more, or are we not saying yet ?
+
+* If systemd is the default on Linux, what opinions do we want to
+  state, if any, re non-Linux ports at this stage ?
+
+* What should be an RC bug in jessie ?
+
+* What should be an RC bug in jessie+1 ?
+
+I also think we need to answer:
+
+* What level of dysfunction is OK if an application (or a desktop
+  environment or whatever) isn't running on its preferred pid 1 ?
+
+* Do we want to give any guidance about what a maintainer may consider
+  an unreasonable native-init-system-support patch ?  Or to put it
+  another way, do we intend to overrule a maintainer who declines to
+  implement one (or any) non-forking startup protocol ?
+
+Please reply by the end of the weekend.  It would be helpful if
+everyone would reply again even if the answers ought to be obvious
+from what you've said before.
+
+I will try to transfer the results into draft(s) in git.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 19:27:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 19:27:13 GMT) (full text, mbox, link).

+ +

Message #3430 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Thu, 16 Jan 2014 19:23:02 +0000
+
+
Ian Jackson writes ("Re: Bug#727708: Init system resolution open questions"):
+> As I mentioned on IRC, I think we need to get some clear answers to
+> certain questions from everybody.
+
+My answers:
+
+> * For which init systems should there be a low nmu threshold for
+>   native support in packages ?
+
+At least systemd, upstart and openrc, provided the policy guidance is
+in place.
+
+> * Daemon package maintainers should accept reasonable patches for
+>   some set of init systems.  Which init systems ?
+
+All.
+
+> * What opinions do we state for jessie+1 - are we hoping for one or
+>   two systems (which two), or more, or are we not saying yet ?
+
+We would like to make provision of sysvinit scripts optional.  We
+would like to continue to support multiple systems into the future so
+long as their communities remain healthy.
+
+Ideally there would be some kind of metalanguage or conversion or
+compatibility scheme that would allow at least simple cases to be
+dealt with without duplicated effort.
+
+> * If systemd is the default on Linux, what opinions do we want to
+>   state, if any, re non-Linux ports at this stage ?
+
+We should express the hope that they will use upstart and that it will
+be suitably ready on both kFreeBSD and Hurd.
+
+> * What should be an RC bug in jessie ?
+
+Lack of support for sysvinit.  Dependency on a particular init system
+as pid 1.
+
+> * What should be an RC bug in jessie+1 ?
+
+Lack of support for whatever the default is on Linux; also, lack of
+support for whatever the default is on kFreeBSD.  Hopefully the Hurd
+default will be the same as kFreeBSD.  In both cases support via
+sysvinit compatibility is acceptable to avoid the RC bug (but
+obviously support only via sysvinit compatibility is not desirable).
+
+> I also think we need to answer:
+> 
+> * What level of dysfunction is OK if an application (or a desktop
+>   environment or whatever) isn't running on its preferred pid 1 ?
+
+Interfaces or functions which access features of a particular init
+system are allowed to break.  Basic functionality must still work.
+
+> * Do we want to give any guidance about what a maintainer may consider
+>   an unreasonable native-init-system-support patch ?  Or to put it
+>   another way, do we intend to overrule a maintainer who declines to
+>   implement one (or any) non-forking startup protocol ?
+
+A maintainer must not reject a patch solely because they don't care to
+support that init system.  A maintainer _may_ reject a patch because
+they don't like the specific non-forking startup protocol being used.
+
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 19:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 19:57:04 GMT) (full text, mbox, link).

+ +

Message #3435 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Thu, 16 Jan 2014 21:54:02 +0200
+
+
On Thu, 2014-01-16 at 19:12 +0000, Ian Jackson wrote:
+> AFAICT we are all agreed that:
+
+> * Applications which aren't part of the init system must not require a
+>   particular init to be pid 1.  (So in particular a desktop
+>   environment may not require a particular pid 1.)
+
+I read the log, and I don't see common agreement with that, at least not
+agreement with not allowing it as an effective requirement (as in GNOME
+can require interfaces which are only available with systemd as PID 1,
+though this might be expressed in ways other than a direct "what is PID
+1" dependency and it would at least in theory be possible that something
+else would provide the interfaces sometime in the future).
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 20:12:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 20:12:04 GMT) (full text, mbox, link).

+ +

Message #3440 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Thu, 16 Jan 2014 12:08:41 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> AFAICT we are all agreed that:
+
+> * Applications which aren't part of the init system must not require a
+>   particular init to be pid 1.  (So in particular a desktop
+>   environment may not require a particular pid 1.)
+
+I still have concerns about this.
+
+This position seems to be predicated on the assumption that applications
+will be able to depend on a working logind for jessie, and that a working
+logind will be provided for systems using sysvinit.  This apparently works
+today with systemd-shim but will stop working with post-205 systemd.
+
+I want to understand whether setting this requirement means that we're
+intending to require that jessie ship with systemd 204, or, if not, what
+level of certainty we have that post-205 logind will work with sysvinit
+for jessie.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 20:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 20:21:04 GMT) (full text, mbox, link).

+ +

Message #3445 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Thu, 16 Jan 2014 21:18:26 +0100
+
+
]] Ian Jackson 
+
+> As I mentioned on IRC, I think we need to get some clear answers to
+> certain questions from everybody.
+
+It's not clear to me that the CTTE is allowed to rule on a bunch of
+those questions, especially the RC bug ones seem to directly contradict
+both 6.3.5 and 6.3.6 in the constitution.  The release team is the team
+that sets RC policies and I'm not aware of any failed attempts at
+arriving at a consensus with them or that they've delegated the decision
+to the CTTE.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 20:42:05 GMT) (full text, mbox, link).

+ +

Message #3448 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Thu, 16 Jan 2014 21:39:37 +0100
+
+
Hi,
+
+Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> AFAICT we are all agreed that:
+[...]
+> * Applications which aren't part of the init system must not require a
+>   particular init to be pid 1.  (So in particular a desktop
+>   environment may not require a particular pid 1.)
+
+What about applications that are specifically designed to work with a
+particular init system? DSA was investigating setting up systemd for
+codesearch.debian.net which uses it to manage worker pools (including
+startup via socket activation and load balancing IIRC).
+
+Another example would be a seperate gnome-session-systemd package[1].
+I don't think tech-ctte should forbid people to maintain such packages
+if they wish to.
+
+  [1] Let's assume this only provides a (possibly non-default)
+      alternative for and doesn't replace gnome-session here.
+
+Of course these might work (partially) if someone implemented enough of
+the systemd dbus interfaces to make the user systemd work without
+systemd being pid-1 as well. However (without having investigated this)
+I would assume this unlikely to happen.
+
+Maintainers only should not drop support for a (default) init system
+when the application supports it. This would be similar to the situation
+with different kernels: when applications support all of them, fine, but
+there may be programs that require a specific kernel.
+
+Ansgar
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 21:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 21:06:04 GMT) (full text, mbox, link).

+ +

Message #3453 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Thu, 16 Jan 2014 13:01:51 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> As I mentioned on IRC, I think we need to get some clear answers to
+> certain questions from everybody.
+
+> * For which init systems should there be a low nmu threshold for
+>   native support in packages ?
+
+I believe this should be the Linux default plus (if different) whatever
+init system is used by the non-Linux ports.  (Putting aside the question
+of whether the Technical Committee can set an NMU threshold for the
+moment.)
+
+> * Daemon package maintainers should accept reasonable patches for
+>   some set of init systems.  Which init systems ?
+
+The same as the list for a low NMU threshold above.
+
+> * What opinions do we state for jessie+1 - are we hoping for one or
+>   two systems (which two), or more, or are we not saying yet ?
+
+I think we should say that native (not via legacy sysvinit shell scripts)
+support for the Linux default is encouraged for jessie+1, and beyond that
+leave this alone.
+
+My fallback position would be to say that we expect to converge on at most
+two well-supported init systems, one for Linux ports and one for non-Linux
+ports.  I think the question of whether to use OpenRC or upstart for
+non-Linux ports is best deferred.
+
+> * If systemd is the default on Linux, what opinions do we want to
+>   state, if any, re non-Linux ports at this stage ?
+
+We will require sysvinit support through the jessie release.
+
+Post jessie, my preference would be to say that support for the init
+system used by non-Linux ports should be treated the same way as any other
+porting issue to the non-Linux ports, such as PATH_MAX issues with Hurd.
+In other words, those are normal bugs in packages unless the release team
+decides that a non-Linux port is a release architecture, maintainers
+should apply patches unless they're excessively intrusive, and maintainers
+aren't expected to test on those architectures.
+
+> * What should be an RC bug in jessie ?
+
+> * What should be an RC bug in jessie+1 ?
+
+I think we should (and possibly are required to) defer to the release team
+on RC bugs in particular, but I do think we should say that support for
+the default init system and for sysvinit are required for jessie (with the
+caveat about what "required" means for packages that rely on functionality
+not provided by sysvinit).
+
+> I also think we need to answer:
+
+> * What level of dysfunction is OK if an application (or a desktop
+>   environment or whatever) isn't running on its preferred pid 1 ?
+
+I think this depends a lot on whether the package is something significant
+enough that we would consider it to be a release blocker or whether it is
+an edge package, and whether the package is directly related to the init
+system or is unrelated.
+
+For example, were someone to want to package a variety of neat daemon
+management tools for OpenRC, I don't see any reason why that should be
+prohibited from the archive even if it requires OpenRC to run.  And while
+I think it's a little weird to have some application in the archive that's
+packaged so that it will only work with a non-default init, as long as it
+declares that dependency in some reasonable way (that doesn't result in
+the system being switched to that init system when it's installed), I have
+a hard time seeing exactly what it *hurts* to have it in the archive.
+
+I think that major packages that would be considered release blockers,
+which probably includes GNOME, KDE, and Xfce, need to support the default
+Linux init system in the sense that, if they don't, I don't think we can
+release.
+
+I think a substantial degredation of functionality when running on an init
+system other than the Linux default would be okay for for jessie+1.  For
+jessie, I think it depends greatly on how feasible making them work with
+sysvinit is (and I suspect sysvinit support would be sufficient for all
+other purposes).
+
+> * Do we want to give any guidance about what a maintainer may consider
+>   an unreasonable native-init-system-support patch ?  Or to put it
+>   another way, do we intend to overrule a maintainer who declines to
+>   implement one (or any) non-forking startup protocol ?
+
+This is hard.  I'm not sure.  I'm leaning towards not getting into this.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 22:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 22:00:05 GMT) (full text, mbox, link).

+ +

Message #3458 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Ansgar Burchardt <ansgar@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Thu, 16 Jan 2014 23:56:15 +0200
+
+
On Thu, Jan 16, 2014 at 09:39:37PM +0100, Ansgar Burchardt wrote:
+>...
+> Maintainers only should not drop support for a (default) init system
+> when the application supports it.
+>...
+
+So if udev (maintained by systemd upstream as part of the systemd 
+sources) would ever get a dependency on systemd being the init 
+system,[1] that should be fine even when the decision of Debian
+was to support multiple init systems?
+
+> Ansgar
+
+cu
+Adrian
+
+[1] I am not assuming bad faith by systemd upstream. But if there ever
+    is a technical advantage in making udev depending on systemd being
+    pid 1, it might be a reasonable option for systemd upstream to add 
+    such a hard dependency to udev.
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 16 Jan 2014 23:18:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 16 Jan 2014 23:18:05 GMT) (full text, mbox, link).

+ +

Message #3463 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: Steven Chamberlain <steven@pyro.eu.org>
+
Cc: 727708@bugs.debian.org, + Алексей Шилин <rootlexx@mail.ru>
+
Subject: Re: Bug#727708: Bits from linux.conf.au
+
Date: Thu, 16 Jan 2014 23:13:48 +0000 (UTC)
+
+
Steven Chamberlain dixit:
+
+>Then he gives a preference for Debian's own insserv and startpar.  It
+>allows for boot order to be fixed (after running insserv once, the same
+>/etc/rc2.d/Sxx numbering may be rsync'd out to many machines).  startpar
+
+I would like to express a preference for one init system that is
+able to do that to be supported.
+
+>allows for some limited/controlled amount of concurrency to happen, for
+>extra speed.
+
+I would like to express a *strong* preference for one init system
+that allows *disabling* parallel boot to be supported.
+
+Thanks,
+//mirabilos
+-- 
+I believe no one can invent an algorithm. One just happens to hit upon it
+when God enlightens him. Or only God invents algorithms, we merely copy them.
+If you don't believe in God, just consider God as Nature if you won't deny
+existence.		-- Coywolf Qi Hunt
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 00:48:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 00:48:09 GMT) (full text, mbox, link).

+ +

Message #3468 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: On diversity
+
Date: Fri, 17 Jan 2014 02:45:51 +0200
+
+
On Thu, 2014-01-16 at 17:52 +0000, Ian Jackson wrote:
+> * Debian is a forum for cooperation and technical development.
+
+> * Debian, as a piece of software, tries to be all things to all
+>   people (within reason).
+
+> This flexibility and tolerance for divergence has made Debian an
+> extremely attractive target for everyone to work within, work on, and
+> derive from.  I think it has been key to the success of the project.
+
+I think the divergence has gone too far in things like non-Linux ports.
+They have had an overall negative effect on people working on Linux
+within Debian and people creating derivatives.
+
+
+> I passionately believe that we need to retain this aspect of our
+> community, even if that causes us extra work; and even if it causes
+> friction with those who would like to make the world nice and simple
+> by only supporting certain goals, certain use cases, or certain
+> software.
+> 
+> 
+> Now let me apply that to init systems:
+
+Even if you start from the assumption that diversity is positive, you
+can't justify support for any particular system without analyzing costs
+and possible alternative goals. Is support for multiple init systems
+more important than having a good SELinux policy for each package? Being
+able to compile packages with several different compilers? Just fixing
+more known bugs in existing packages? You could come up with hundreds of
+possible goals that would all have at least some positive effect; just
+saying that diversity is good can't allow you to pick some and reject
+others.
+
+
+> If you think that the difference between upstart and systemd, or
+> between either of those and systemd, is not important, then perhaps
+> you could conclude that it was OK to impose a particular decision on
+> all of our users and all of our downstreams.
+
+I think there are important differences: upstart is significantly worse
+than systemd in several areas.
+
+> But I think the differences /are/ important.
+
+Do you actually believe that upstart has some nontrivial technical
+advantages over systemd, such that it would be a noticeably better
+alternative even when considering only some specific use case? IIRC you
+did not identify any when saying you preferred upstart earlier, and
+mainly based your opinion on the assumption that upstart would be more
+likely to get ported.
+
+Even the upstart proponents do not seem to have significant arguments
+about upstart having better functionality, and there don't seem to be
+all that many people who would have a reasonably informed opinion that
+upstart would be technically better even for just their particular use.
+To me it looks like the main reason Upstart is still alive at all is
+that Ubuntu don't want to pay the cost of the conversion to the better
+system and don't want to admit that "their" alternative was inferior.
+
+If the differences are mainly just "it's worse" rather than tradeoffs
+where each software has clear technical advantages, it's unlikely
+diversity would give any significant benefits.
+
+
+> That means that we need to be the venue where systemd proponents, and
+> upstart proponents, and openrc proponents, can make the best system
+> they can.
+
+I do not believe it is possible to create such a venue. The result of
+the kind of "everything must be supported" policies you seem to favor
+would be a venue where nobody is able to create a system they would be
+happy with. Or possibly only sysvinit/openrc proponents would be happy
+with, if everything is dumbed down to the level where those systems can
+handle it.
+
+> Naturally that will involve some compromises.  That's an unavoidable
+> cost of trying to be the best place for everyone to pursue their own
+> goals.
+
+"The best place for everyone to pursue their own goals" is
+self-contradictory. You need to choose whose goals matter most; if you
+don't, it'll require so many compromises that it's not only not "the
+best place" for most, it outright sucks. Everyone can maintain their own
+leaf package, but not everyone can design how boot and service
+management should work.
+
+> I think in this case those compromises are absolutely essential.  Not
+> just from a technical point of view because of the advantages of one
+> system over another.  But also to ensure that Debian continues to be
+> the place where serious and dynamic people come to do their stuff.
+
+Debian has been successful in some ways, but I don't think it is "the
+place where serious and dynamic people come to do their stuff". For
+example, none of the newer init systems come from Debian itself; I think
+that reflects how hard it is to create the kind of progress I'd
+associate with the word "dynamic" within Debian. Debian mainly
+integrates serious new developments long after they've been used
+elsewhere.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 01:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 01:03:04 GMT) (full text, mbox, link).

+ +

Message #3473 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Thu, 16 Jan 2014 17:00:38 -0800
+
+
Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
+
+> I think the divergence has gone too far in things like non-Linux ports.
+> They have had an overall negative effect on people working on Linux
+> within Debian and people creating derivatives.
+
+I have to take exception to this.  There has been a great deal of
+*concern* from people over the past two years that the non-Linux ports
+*might* have a negative effect on Linux in the context of this particular
+discussion.  But, in the meantime, the non-Linux porters have been
+first-class Debian contributors over the years.  They have not
+substantially gotten in the way of Debian's processes, certainly no more
+than any Linux port to a more obscure architecture, and they have
+contributed a great many improvements to our software.
+
+For example, I think special thanks should go to the Hurd porters for
+extended, thankless work on removing static buffers from the code in the
+archive.  They were doing so because some of the constants used to size
+those buffers are not portable to the Hurd, but using static buffers to
+store paths and related strings is often incorrect regardless of its
+portability, and can even be a security issue depending on how the code is
+written.  The Hurd porters have provided reasonable patches that can go
+back to upstream and result in objectively more robust software.  I have
+gotten a steady stream of solid and thoughtful patches from the Hurd
+porters for years as a Debian package maintainer, and I appreciate that
+work.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 07:51:04 GMT) (full text, mbox, link).

+ +

Message #3476 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Fri, 17 Jan 2014 08:46:57 +0100
+
+
Hi,
+
+Adrian Bunk <bunk@stusta.de> writes:
+> On Thu, Jan 16, 2014 at 09:39:37PM +0100, Ansgar Burchardt wrote:
+>>...
+>> Maintainers only should not drop support for a (default) init system
+>> when the application supports it.
+>>...
+>
+> So if udev (maintained by systemd upstream as part of the systemd 
+> sources) would ever get a dependency on systemd being the init 
+> system,[1] that should be fine even when the decision of Debian
+> was to support multiple init systems?
+
+If it doesn't work at all without systemd enabled, yes. Note that this
+doesn't stop people from keeping it working without systemd in which
+case it wouldn't need this dependency.
+
+Having already existing packages gain a dependency on a specific init
+system is probably more controverse and more people might want to avoid
+that[1], but that is (IMHO) no reason to forbid such dependencies
+altogether.
+
+Ansgar
+
+  [1] That's why there was a footnote in my earlier mail.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 08:54:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 08:54:10 GMT) (full text, mbox, link).

+ +

Message #3481 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Colin Watson <cjwatson@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Fri, 17 Jan 2014 18:50:31 +1000
+
+
On 31 December 2013 12:55, Colin Watson <cjwatson@debian.org> wrote:
+> The criticisms of Upstart's event model in the systemd position
+> statement simply do not make sense to me.  Events model how things
+> actually happen in reality; dependencies are artificial constructions on
+> top of them, and making them work requires the plethora of different
+> directives in systemd (e.g. Wants, which is sort of a non-depending
+> dependency) to avoid blocking the boot process on a single failing
+> service.
+
+Riffing off this more than replying to it.
+
+I tend to think dependencies and events are both useful ways of
+describing when to start up parts of the system. In particular, it
+seems like:
+
+ - when a network is connected, start web server
+ - when a usb disk is connected, mount it
+ - when a VPN is started, sync various things
+
+are best described by an "event" model, while:
+
+ - in order to run GNOME, logind must be started
+ - in order to run logind, dbus must be available
+ - as part of making the system ready for a user, network-manager
+should be running
+
+make the most sense when described by "dependencies". In particular,
+in many of those cases, the reverse might not be true: For debugging,
+I might want to start the web server manually without connecting the
+network; or I might want logind running without GNOME, or
+network-manager running without the other parts of my desktop
+environment.
+
+Events and dependencies aren't that different; an event essentially
+lets a service X say that:
+
+  whenever Y happens, X happens
+  whenever Y happens, X stops happening
+
+while a (systemd'ish) dependency says either:
+
+  when X happens, Y happens as well    [X Requires: Y]
+  before X happens, Y happens as well   [X Requires: Y, After: Y]
+  after X happens, Y happens as well     [X Requires: Y, Before: Y]
+
+(with Wants and Requisite and Overridable variants as well; also
+RequiredBy and WantedBy variants)
+
+If you look at "Y", there are a few phases it could go through:
+
+    no-Y
+    Y-starts-starting
+    Y-started
+    Y-begins-ending
+    no-Y
+
+If you wanted to emulate upstart events with dependencies, you'd need
+to do four things, I think:
+
+    * create a dummy "Y-started-event" unit ["network-is-available",
+"usb-is-available"]
+    * invoke "systemctl start Y-started-event" when Y is finished starting
+    * invoke "systemctl stop Y-started-event" when Y begins ending
+    * add "RequiredBy: Y-started-event" and "PartOf: Y-started-event"
+to X's unit file
+
+That seems reasonably straight forward to me? If the event is
+something systemd already knows about, you might only need to do
+something equivalent to the last step. I don't think invoking
+systemctl start/stop is any better or worse than whatever would be
+needed to notify upstart of the same events.
+
+To emulate systemd dependencies in an event model (ie, X depends on
+Y), you'd need to do either:
+
+    * change Y's job to say "start on starting X"
+    * add "stop on stopping Y" to X's job description
+
+or
+
+    * add a pre-start script to X in order to start Y first
+    * add "stop on stopping Y" to X's job description
+
+The latter looks like it's the documented way of doing things. Neither
+of those seem particularly great -- I think that's due to upstart not
+letting you reverse event descriptions in the same way that systemd
+has Requires/RequiredBy statements. If you could say:
+
+   * on starting start Y
+   * stop on stopping Y
+
+in X's job description, by contrast, I think that would be a fine way
+of declaring a "dependency" from X to Y without leaving the "event"
+model. Not having a simple way of specifying this sort of dependency
+seems pretty weak on upstart's behalf.
+
+It would probably also be nice to have a way of saying "when a new
+network comes up, reload/refresh service X" -- so that it could bind
+to new ports or whatever even if it was already running; that seems
+like the sort of thing that would be easier to specify in an event
+model ("on new-network-interface-started reload or start"), than in a
+dependency model.
+
+Cheers,
+aj
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 08:54:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 08:54:13 GMT) (full text, mbox, link).

+ +

Message #3486 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: Uoti Urpala <uoti.urpala@pp1.inet.fi>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Fri, 17 Jan 2014 08:47:11 +0000 (UTC)
+
+
Uoti Urpala dixit:
+
+>They have had an overall negative effect on people working on Linux
+>within Debian and people creating derivatives.
+
+Besides what Russ said: Debian isn’t about Linux.
+Debian is the universal operating system.
+
+bye,
+//mirabilos
+-- 
+18:47⎜<mirabilos:#!/bin/mksh> well channels… you see, I see everything in the
+same window anyway      18:48⎜<xpt:#!/bin/mksh> i know, you have some kind of
+telnet with automatic pong         18:48⎜<mirabilos:#!/bin/mksh> haha, yes :D
+18:49⎜<mirabilos:#!/bin/mksh> though that's more tinyirc – sirc is more comfy
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 09:24:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ondřej Surý <ondrej@sury.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 09:24:08 GMT) (full text, mbox, link).

+ +

Message #3491 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ondřej Surý <ondrej@sury.org>
+
To: Uoti Urpala <uoti.urpala@pp1.inet.fi>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Fri, 17 Jan 2014 10:21:42 +0100
+
+
On Fri, Jan 17, 2014, at 1:45, Uoti Urpala wrote:
+> On Thu, 2014-01-16 at 17:52 +0000, Ian Jackson wrote:
+> > * Debian is a forum for cooperation and technical development.
+> 
+> > * Debian, as a piece of software, tries to be all things to all
+> >   people (within reason).
+> 
+> > This flexibility and tolerance for divergence has made Debian an
+> > extremely attractive target for everyone to work within, work on, and
+> > derive from.  I think it has been key to the success of the project.
+> 
+> I think the divergence has gone too far in things like non-Linux ports.
+> They have had an overall negative effect on people working on Linux
+> within Debian and people creating derivatives.
+
+Could you please state your affiliation with Debian and the real work
+you have done on Linux within Debian?
+
+All I have seen and can find from you is the flaming in the lists. So I
+suggest that unless you do a work within Debian you should not voice
+your opinions for other Debian Developers. E.g. speak about yourself and
+not about "people". You are not the voice of the people and definitely
+not a voice of Debian people. Preferably just refrain from adding more
+of *your* opinions into this bug report.
+
+Thank you,
+-- 
+Ondřej Surý <ondrej@sury.org>
+Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 11:06:23 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Holger Levsen <holger@layer-acht.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 11:06:23 GMT) (full text, mbox, link).

+ +

Message #3496 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Holger Levsen <holger@layer-acht.org>
+
To: 727708@bugs.debian.org
+
Subject: piuparts sadly does not test init scripts^w^wdaemon starting (Re: Bug#727708: Bits from linux.conf.au)
+
Date: Fri, 17 Jan 2014 12:05:22 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Hi,
+
+On Donnerstag, 16. Januar 2014, Anthony Towns wrote:
+> > it's not realistic for a porter to continously test startup
+> > scripts for thousands of packages.
+> It's reasonable to semi-continuously test installation scripts for
+> thousands of packages -- that's what piuparts does, and we have
+> sponsored cloud resources to support that. It seems like that would be
+> fairly straightforward to duplicate for testing packages with
+> alternative init systems.
+
+piuparts has /sbin/policy.rc.d in place with the content of "exit 0", IOW, it 
+does not execute init scripts at all. Running, monitoring and killing 
+arbitrary daemons is not trivial.
+
+Help and patches welcome! :-)
+
+
+cheers,
+	Holger
+
+
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 11:27:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Lars Wirzenius <liw@liw.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 11:27:09 GMT) (full text, mbox, link).

+ +

Message #3501 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Lars Wirzenius <liw@liw.fi>
+
To: Holger Levsen <holger@layer-acht.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: piuparts sadly does not test init scripts^w^wdaemon + starting (Re: Bug#727708: Bits from linux.conf.au)
+
Date: Fri, 17 Jan 2014 11:15:06 +0000
+
+
On Fri, Jan 17, 2014 at 12:05:22PM +0100, Holger Levsen wrote:
+> Hi,
+> 
+> On Donnerstag, 16. Januar 2014, Anthony Towns wrote:
+> > > it's not realistic for a porter to continously test startup
+> > > scripts for thousands of packages.
+> > It's reasonable to semi-continuously test installation scripts for
+> > thousands of packages -- that's what piuparts does, and we have
+> > sponsored cloud resources to support that. It seems like that would be
+> > fairly straightforward to duplicate for testing packages with
+> > alternative init systems.
+> 
+> piuparts has /sbin/policy.rc.d in place with the content of "exit 0", IOW, it 
+> does not execute init scripts at all. Running, monitoring and killing 
+> arbitrary daemons is not trivial.
+
+Indeed. Early on in my original development of piuparts I realised
+that testing, in a chroot, code that starts arbitrary daemons is a bad
+idea in oh so many ways. I haven't followed piuparts development in
+recent years, so I don't know if it still uses chroot, but unless it's
+started using containers or virtual machines, it should continue to
+NOT allow init.d scripts to run. At all.
+
+-- 
+http://www.cafepress.com/trunktees -- geeky funny T-shirts
+http://gtdfh.branchable.com/ -- GTD for hackers
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 12:33:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 12:33:09 GMT) (full text, mbox, link).

+ +

Message #3506 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Anthony Towns <aj@erisian.com.au>, 727708@bugs.debian.org
+
Cc: Colin Watson <cjwatson@debian.org>
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Fri, 17 Jan 2014 04:25:46 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Jan 17, 2014 at 12:50 AM, Anthony Towns <aj@erisian.com.au> wrote:
+
+> On 31 December 2013 12:55, Colin Watson <cjwatson@debian.org> wrote:
+> > The criticisms of Upstart's event model in the systemd position
+> > statement simply do not make sense to me.  Events model how things
+> > actually happen in reality; dependencies are artificial constructions on
+> > top of them, and making them work requires the plethora of different
+> > directives in systemd (e.g. Wants, which is sort of a non-depending
+> > dependency) to avoid blocking the boot process on a single failing
+> > service.
+>
+> Riffing off this more than replying to it.
+>
+> I tend to think dependencies and events are both useful ways of
+> describing when to start up parts of the system. In particular, it
+> seems like:
+>
+>  - when a network is connected, start web server
+>  - when a usb disk is connected, mount it
+>  - when a VPN is started, sync various things
+>
+> are best described by an "event" model, while:
+>
+>  - in order to run GNOME, logind must be started
+>  - in order to run logind, dbus must be available
+>  - as part of making the system ready for a user, network-manager
+> should be running
+>
+>
+You could express that as an event because GNOME and logind communicate
+with logind and dbus (respectively) through IPC. So you can say "when GNOME
+tries to use logind's dbus interface, start logind", or you can say "when
+//anything// tries to use logind's dbus interface, start logind" and have
+that done for. Same for starting dbus, just change a dbus interface to
+dbus's port.
+
+
+> make the most sense when described by "dependencies". In particular,
+> in many of those cases, the reverse might not be true: For debugging,
+> I might want to start the web server manually without connecting the
+> network; or I might want logind running without GNOME, or
+> network-manager running without the other parts of my desktop
+> environment.
+>
+>
+With the above method, this problem is avoided because GNOME does not start
+when logind starts, it just starts whenever the runlevel is right and then
+logind is started automatically. So if GNOME is stopped/waiting, you can
+start logind without GNOME starting.
+
+--
+Cameron Norman
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 12:42:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Holger Levsen <holger@layer-acht.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 12:42:08 GMT) (full text, mbox, link).

+ +

Message #3511 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Holger Levsen <holger@layer-acht.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: piuparts sadly does not test init scripts^w^wdaemon starting (Re: Bug#727708: Bits from linux.conf.au)
+
Date: Fri, 17 Jan 2014 13:38:38 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Hi,
+
+On Freitag, 17. Januar 2014, Lars Wirzenius wrote:
+> Indeed. Early on in my original development of piuparts I realised
+> that testing, in a chroot, code that starts arbitrary daemons is a bad
+> idea in oh so many ways. I haven't followed piuparts development in
+> recent years, so I don't know if it still uses chroot, but unless it's
+> started using containers or virtual machines, it should continue to
+> NOT allow init.d scripts to run. At all.
+
+while piuparts now indeed supports other virtualisation methods, no support 
+for dealing with starting, stopping & evaluating(!) daemons has been added 
+yet. I wrote "patches welcome" already :)
+
+
+cheers,
+	Holger
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 12:45:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thomas Goirand <zigo@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 12:45:05 GMT) (full text, mbox, link).

+ +

Message #3516 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thomas Goirand <zigo@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: OpenRC now works on GNU/Hurd! :)
+
Date: Fri, 17 Jan 2014 20:41:59 +0800
+
+
Hi,
+
+It's with great joy that I can announce here that OpenRC now supports
+GNU/Hurd. I have just added a few patches which were worked out with
+upstream (you can look at them, it's really trival FTBFS fixing...),
+tested it, and I can happily say it works.
+
+The only thing that bothers me a bit is that the ANSI output isn't so
+pretty, but I guess this is fixable and a minor problem.
+
+On the  Thu, 16 Jan 2014 17:18:24 +0100, Josselin Mouette
+<joss@debian.org> wrote:
+> This assumes that OpenRC can be fixed to have parallel boot, otherwise
+> this is a big regression from the current insserv setup.
+
+This is just plain wrong, OpenRC perfectly supports parallel booting,
+it's just that the output on the screen is very ugly for the moment
+(that as well can be fixed, I suppose).
+
+Also, I'd like to point out to everyone that the OpenRC runscripts are
+stored in /etc/init.d. This means that if someone wants to support
+OpenRC and use a runscript instead of a traditional init.d shell script,
+that someone will also have to support whatever we will choose as
+default. Let me explain to make sure everyone gets it...
+
+Let's say you rewrite /etc/init.d/foo, and transform it from a init.d
+traditional sysv-rc script to an OpenRC runscript in your package. If
+the init system is systemd, then systemd will *not* understand the
+OpenRC runscript. This means that you will also have to write a systemd
+unit file, if you want to write /etc/init.d/foo as an OpenRC runscript.
+The same would of course apply to Upstart.
+
+Though I think that writing a systemd unit file, plus an OpenRC
+runscript, is still more easy and strait forward than writing a single
+init.d sysv-rc shell script.
+
+So, if we are to switch to systemd as default (same would apply if we
+choose Upstart), IMO the policy should be that package maintainers have
+2 choices:
+
+1/ Write a standard LSB-header SysV-rc init script, which will of course
+work with any init system (sysv-rc, OpenRC, systemd, Upstart, file-rc...)
+
+2/ If the /etc/init.d/foo is an OpenRC runscript (which we should, IMO,
+push for since traditional scripts have some many problems which I can't
+even lest in this mail, and we all agree about that), then the package
+maintainer *must* provide support for systemd (or upstart, if we choose
+that as default).
+
+IMO, the above would be the best way forward for Debian if we want to
+continue to support our ports.
+
+Cheers,
+
+Thomas Goirand (zigo)
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 12:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 12:51:05 GMT) (full text, mbox, link).

+ +

Message #3521 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Tollef Fog Heen <tfheen@err.no>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Fri, 17 Jan 2014 12:48:59 +0000
+
+
Tollef Fog Heen writes ("Bug#727708: Init system resolution open questions"):
+> [Ian Jackson]:
+> > As I mentioned on IRC, I think we need to get some clear answers to
+> > certain questions from everybody.
+> 
+> It's not clear to me that the CTTE is allowed to rule on a bunch of
+> those questions, especially the RC bug ones seem to directly contradict
+> both 6.3.5 and 6.3.6 in the constitution.  The release team is the team
+> that sets RC policies and I'm not aware of any failed attempts at
+> arriving at a consensus with them or that they've delegated the decision
+> to the CTTE.
+
+Under the circumstances I think it would be appropriate for the
+committee to give appropriate advice.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 12:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Vincent Lefevre <vincent@vinc17.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 12:54:04 GMT) (full text, mbox, link).

+ +

Message #3526 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Vincent Lefevre <vincent@vinc17.net>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: OpenRC now works on GNU/Hurd! :)
+
Date: Fri, 17 Jan 2014 13:51:19 +0100
+
+
On 2014-01-17 20:41:59 +0800, Thomas Goirand wrote:
+> On the  Thu, 16 Jan 2014 17:18:24 +0100, Josselin Mouette
+> <joss@debian.org> wrote:
+> > This assumes that OpenRC can be fixed to have parallel boot, otherwise
+> > this is a big regression from the current insserv setup.
+> 
+> This is just plain wrong, OpenRC perfectly supports parallel booting,
+> it's just that the output on the screen is very ugly for the moment
+> (that as well can be fixed, I suppose).
+
+Parallel booting also breaks output with sysv-rc.
+
+-- 
+Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
+100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
+Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 12:54:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 12:54:08 GMT) (full text, mbox, link).

+ +

Message #3531 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Fri, 17 Jan 2014 12:51:48 +0000
+
+
Adrian Bunk writes ("Re: Bug#727708: Init system resolution open questions"):
+> (Only as a PM since I am repeating myself.)
+
+Thanks for your mail.  I think it deserves wider consideration.
+
+> One question you should consider adding:
+> 
+> * What switching between init systems has to be supported?
+>   Should it be possible for the user to switch from one supported init 
+>   system to another supported init system at any point (it is OK if that 
+>   requires a reboot), or is it acceptable if that is not possible in all 
+>   cases or even not at all?
+
+It seems obvious to me that if multiple ones are supported that there
+has to be some way to get from using one to using a different one.  So
+the question is more one of how difficult it is.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 13:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andrew Shadura <andrew@shadura.me>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 13:27:04 GMT) (full text, mbox, link).

+ +

Message #3536 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andrew Shadura <andrew@shadura.me>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: OpenRC now works on GNU/Hurd! :)
+
Date: Fri, 17 Jan 2014 14:24:40 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Hello,
+
+On Fri, 17 Jan 2014 20:41:59 +0800
+Thomas Goirand <zigo@debian.org> wrote:
+
+> Let's say you rewrite /etc/init.d/foo, and transform it from a init.d
+> traditional sysv-rc script to an OpenRC runscript in your package. If
+> the init system is systemd, then systemd will *not* understand the
+> OpenRC runscript. This means that you will also have to write a
+> systemd unit file, if you want to write /etc/init.d/foo as an OpenRC
+> runscript. The same would of course apply to Upstart.
+
+It is actually fairly easy to write an initscript which uses native
+OpenRC facilities if they're available. While this serves little
+practical use, I tried to play with this, and this is the result:
+
+http://sources.debian.net/src/twms/0.05t-2/debian/init
+
+This lacks OpenRC's depends() function, but has LSB headers instead,
+so otherwise it works fine.
+
+-- 
+Cheers,
+  Andrew
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 13:45:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 13:45:08 GMT) (full text, mbox, link).

+ +

Message #3541 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Fri, 17 Jan 2014 14:43:37 +0100
+
+
]] Ian Jackson 
+
+> Tollef Fog Heen writes ("Bug#727708: Init system resolution open questions"):
+> > [Ian Jackson]:
+> > > As I mentioned on IRC, I think we need to get some clear answers to
+> > > certain questions from everybody.
+> > 
+> > It's not clear to me that the CTTE is allowed to rule on a bunch of
+> > those questions, especially the RC bug ones seem to directly contradict
+> > both 6.3.5 and 6.3.6 in the constitution.  The release team is the team
+> > that sets RC policies and I'm not aware of any failed attempts at
+> > arriving at a consensus with them or that they've delegated the decision
+> > to the CTTE.
+> 
+> Under the circumstances I think it would be appropriate for the
+> committee to give appropriate advice.
+
+You're of course free to give advice.  My point was that it's not
+binding (you can't rule on it).
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 14:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Noa Resare <noa@spotify.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 14:00:04 GMT) (full text, mbox, link).

+ +

Message #3546 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Noa Resare <noa@spotify.com>
+
To: 727708@bugs.debian.org
+
Subject: Spotify position in support of systemd in the default init debate
+
Date: Fri, 17 Jan 2014 14:58:41 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Friends,
+
+Spotify, an online streaming music service, is a significant user of Debian
+GNU/Linux. We have some 5000 physical servers and well over a thousand
+virtual servers using both public and private clouds running Debian
+GNU/Linux serving millions of songs to our users every day.
+
+We would like to take this opportunity to endorse systemd as our preferred
+init system and we would like to see it as default on Debian GNU/Linux
+moving forward.
+
+Our main reasons for this preference:
+
+- We believe that the dependency model of systemd is easier to understand,
+explain and work with than the event based counterpart of upstart.
+
+- We believe that the various features built on top of the way systemd uses
+cgroups, notably mechanisms for resource limitations, would be very useful
+in a highly scalable highly available environment such as ours.
+
+- We believe that systemd will have the stronger community momentum moving
+forward when it comes to seeing close integration between modern init
+system features and upstream projects.
+
+With kind regards
+Spotify infrastructure and operations
+via
+Noa Resare, Free Software ombudsman
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 15:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ihar Filipau <thephilips@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 15:12:05 GMT) (full text, mbox, link).

+ +

Message #3551 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ihar Filipau <thephilips@gmail.com>
+
To: 727708@bugs.debian.org
+
Cc: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
Subject: Re: On diversity
+
Date: Fri, 17 Jan 2014 16:08:53 +0100
+
+
Uoti Urpala wrote:
+> Even the upstart proponents do not seem to have significant arguments
+> about upstart having better functionality, and there don't seem to be
+> all that many people who would have a reasonably informed opinion that
+> upstart would be technically better even for just their particular use.
+
+I followed the discussion from the beginning and I'd like to comment on that.
+My own comparison of systemd vs. upstart (Fedora 20 vs. Ubuntu 13.10) is still
+fresh in my memory.
+
+Though I do not have strong personal preference for one or another, the Ubuntu
+(as an OS based on upstart) left much much better impression than the Fedora (as
+an OS based on systemd). Looking at the both of them over period of two days
+showed several cardinal differences. I'll narrow it down to three, first one
+addressing "what's better in upstart?".
+
+1. "upstart" is a highly configurable init system, while "systemd" hardcodes
+most of the nuts and bolts in the 32 shipped executables. I spent one days
+going through the upstart's setup on Ubuntu: lots of stuff, lots of non-trivial
+inter-connections. I needed only two hours to review systemd setup. Because
+every interesting and important bit was just a call of the special systemd
+binary. Most (but not all) of the special binaries have man pages, but only few
+of the helper binaries actually provide any customization capability.
+Again: systemd on Fedora 10 is compromised of more than *30* binaries
+(not counting: systemd binary itself, the generators and the admin utilities).
+
+
+So here you go. The advantage of the upstart, is that if you need to tweak the
+boot of your system, you can do it right there, with the text editor, by
+changing the .conf files or the shell scripts. While with the systemd, you have
+to patch the sources, recompile and reinstall. Because literally everything
+is hardcoded in some special systemd binary.
+(Coming from the embedded systems, to me personally that is a biggie.)
+
+2. "upstart" was not designed or intended to be a SMF (service management
+facility), while "systemd" was.
+
+I think it is insincere of upstart proponents to even advertise it as such. On
+Ubuntu, upstart effectively ends its work by calling the
+`/etc/init.d/rc $RUNLEVEL`. (What IMO means it might make sense to look into
+integration of upstart with OpenRC. Orthogonality of the two should mean few
+conflicts.)
+
+On the other side of the fence. As I see it, it is only a coincidence that
+"systemd" is also an init system. To me it was clearly designed from ground up
+as SMF: boot and initialization were only afterthought. That's why the magic
+binaries, because the initialization, an event driven process, simply doesn't
+fit into the systemd "everything is a service" model.
+
+
+3. Boot times. Though systemd was supposed to improve the boot time, Fedora 20
+VM on my rig needs 1m5s-1m15s to start - while Ubuntu 13.10 VM always timed
+flat 0m35s. That was pretty dumbfounding realization, especially after finding
+that Fedora has only few sysvinit scripts - and Ubuntu has almost all services
+started by the sysvinit shell scripts.
+
+
+Summary. Since the discussion about the init system choice IMO went on for too
+long, I can only recommend to repeat my experiment: create two VMs - VirtualBox
+is available right from the Debian repos ;-) - and install Fedora 20 and Ubuntu
+13.10. See the differences for yourself. Experience the differences for
+yourself.
+
+Regards,
+and good luck reaching the decision.
+
+
+P.S. bugs.debian.org doesn't seem to let my e-mails through.
+Two attempts to subscribe to the bug went nowhere.
+Let's see if this message is luckier.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 15:15:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 15:15:09 GMT) (full text, mbox, link).

+ +

Message #3556 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Fri, 17 Jan 2014 16:13:41 +0100
+
+
Le vendredi 17 janvier 2014 à 08:47 +0000, Thorsten Glaser a écrit :
+> Besides what Russ said: Debian isn’t about Linux.
+> Debian is the universal operating system.
+
+Just because you don’t understand that sentence doesn’t mean you can use
+it to justify whatever convoluted position of yours.
+
+An operating system is universal if it can be used for all purposes.
+An operating system that supports several kernels and init systems, but
+all incompletely, letting the user choose between different ways of
+failing to boot, is not universal. It is irrelevant to any serious use
+case.
+
+-- 
+.''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 15:19:20 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Moritz Muehlenhoff <jmm@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 15:19:20 GMT) (full text, mbox, link).

+ +

Message #3561 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Moritz Muehlenhoff <jmm@debian.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Fri, 17 Jan 2014 16:05:48 +0100
+
+
On Thu, Jan 16, 2014 at 01:01:51PM -0800, Russ Allbery wrote:
+> I think that major packages that would be considered release blockers,
+> which probably includes GNOME, KDE, and Xfce, need to support the default
+> Linux init system in the sense that, if they don't, I don't think we can
+> release.
+> 
+> I think a substantial degredation of functionality when running on an init
+> system other than the Linux default would be okay for for jessie+1.  For
+> jessie, I think it depends greatly on how feasible making them work with
+> sysvinit is (and I suspect sysvinit support would be sufficient for all
+> other purposes).
+
+I think we should move away from them target that the non-Linux ports should
+build the entire archive.
+
+FreeBSD upstream isn't a desktop OS and never will be, there're just too
+many deficiencies (e.g. lack of dbus, limited hardware support, only OSS 
+sound drivers, limited KMS/3D support in Xorg etc. pp). So why should the 
+Debian port with it's minimal porters achieve what upstream doesn't deliver? 
+And for Hurd it's even more obvious.
+
+All the use cases mentioned for Debian kfreebsd are server-based (e.g. pf
+or NAS using ZFS). Why not focus on a useful subsection of Debian and get that
+right instead of fighting an uphill battle?
+
+Cheers,
+        Moritz
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 15:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 15:21:04 GMT) (full text, mbox, link).

+ +

Message #3566 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: OpenRC now works on GNU/Hurd! :)
+
Date: Fri, 17 Jan 2014 16:19:45 +0100
+
+
Le vendredi 17 janvier 2014 à 20:41 +0800, Thomas Goirand a écrit :
+> Hi,
+> 
+> It's with great joy that I can announce here that OpenRC now supports
+> GNU/Hurd. I have just added a few patches which were worked out with
+> upstream (you can look at them, it's really trival FTBFS fixing...),
+> tested it, and I can happily say it works.
+> 
+> The only thing that bothers me a bit is that the ANSI output isn't so
+> pretty, but I guess this is fixable and a minor problem.
+> 
+> On the  Thu, 16 Jan 2014 17:18:24 +0100, Josselin Mouette
+> <joss@debian.org> wrote:
+> > This assumes that OpenRC can be fixed to have parallel boot, otherwise
+> > this is a big regression from the current insserv setup.
+> 
+> This is just plain wrong, OpenRC perfectly supports parallel booting,
+> it's just that the output on the screen is very ugly for the moment
+> (that as well can be fixed, I suppose).
+
+Oh, really?
+Then can you explain why https://bugs.gentoo.org/show_bug.cgi?id=391945
+has not been marked as fixed?
+
+> Though I think that writing a systemd unit file, plus an OpenRC
+> runscript, is still more easy and strait forward than writing a single
+> init.d sysv-rc shell script.
+
+That, I can definitely agree with. Although it is a shame that OpenRC
+chose a non-declarative format.
+
+-- 
+.''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 15:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Christoph Anton Mitterer <calestyo@scientia.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 15:51:04 GMT) (full text, mbox, link).

+ +

Message #3571 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Christoph Anton Mitterer <calestyo@scientia.net>
+
To: 727708@bugs.debian.org
+
Subject: personal views of Debian users
+
Date: Fri, 17 Jan 2014 16:46:43 +0100
+
+
Hey.
+
+Well not sure whether this is actually welcomed or not,... but since
+some people have already started to share their personal feelings about
+the debate, I want to do so as well.
+
+
+I've been using sysvinit for countless years (as most of us)... and I've
+tried both, systemd and upstart when the recent discussion began (which
+was, I guess, actually sparked indirectly by a post of mine, when I
+"asked" whether systemd was now mandatory due to GNOME depending on
+it))...
+I haven't really looked in depth at OpenRC or other solutions, since
+from the descriptions made by other people, I think it's not comparable
+to systemd/upstart.
+
+I'm maintaining a large Tier-2 for the LHC Computing Grid... so I guess
+I do have "some" ;) experience in what is useful in real life (like most
+other people here have of course as well).
+
+
+
+Now I guess it doesn't make much sense to repeat all technical arguments
+people have already brought up over and over again in this bug, so to
+make it short:
+
+From a technical POV, I'd clearly go for systemd.
+
+Not only are (IMHO) it's core concepts and design superior... it also
+seems to provide much more and better features.
+
+Speaking only about Debian GNU/Linux... I'd even go as far, that I'd say
+we should in the long term, think about integrating the "other" features
+of systemd, like the Journal replacing rsyslog, or perhaps even having
+it in the initramfs (well, that is of course something one would really
+need to investigate closely)...
+In any case we should try to get something like the un-initramfs at
+shutdown, which systemd seems to support quite well.
+
+
+I think however, that a main part (50%) of the question systemd vs.
+upstart vs. something-else is not a technical one.
+Code, design and features can be improved or added.
+I think there is a strong political part in this decision.
+
+- At most upstream projects (the kernel, wayland, X, etc. pp.) people
+seem to at least think first about systemd... if they support upstart at
+all.
+Just look at recent developments like kdbus, which are clearly strongly
+"influenced/triggered" by systemd.
+So I fear that when going for upstart, Debian might sooner or later sit
+on a lone island (next to *buntu's island), having to spend a lot time
+to keep things working and adapted to upstart.
+
+- Most other major distros (except *buntu) have decided for systemd,...
+so again here,... with upstart we'd sit on a lone island, which
+ultimately would lead to many problems for sure.
+
+- In my opinion (and I'm sure some people will agree and others will
+contrary): RedHat has proven to be more "neutral" to projects it
+"governs" than Canonical.
+Actually, many people seem to think,... that Canonical has recently gone
+some strange paths, which somehow seem to lead them away from the
+community and classical open source ecosystem (just think about the
+whole Mir-story).
+
+- With upstart there is the contributor license agreement issue... which
+I think is a major political problem.
+
+- Last but not least... there are people (including myself, I guess),...
+which are concerned about the Debian/*buntu relationship in several
+ways... so having upstart the default init system, would give Canonical
+for sure some bit more of influence on Debian (and if it was just by
+technical decisions they make upstream).
+Of course one can argue, that this kind of influence might now be taken
+by RedHat.
+
+
+As another side note (which is not really a reason against upstart), but
+has also some political "impact", I guess...
+I really wonder what the decision "systemd vs. upstart in Debian" means
+to upstart?
+systemd for sure wouldn't bother much, if Debian decides for upstart.
+But it seems to me, that if Debian decides for systemd, this could be
+the end of upstart itself.
+Why?
+- *buntu would then permanently be completely alone on the
+upstart-island.
+- And since Debian packages would then focus on systemd, *buntu would
+get proper support for that for free - so why continuing to spend much
+efforts just for having an own init-system, which even provides no real
+technical benefits?
+
+Actually Canonical *is* known for dropping support or at least active
+development for their praised products,... think about bzr.
+
+
+
+Some last things:
+
+- While I think there should be a default init-system which all packages
+MUST support (which I'd want to be systemd)... others should be allowed
+as well.
+
+- I do have a big problem with projects (especially like GNOME) which
+sometimes seem to have an agenda of enforcing people to use the
+techniques they want. IMHO, open source IS about choice. But reality is
+probably, that one cannot do much about it.
+
+- I strongly like the idea of having k/freebsd and other non-Linux
+Debians,... and if it is just for diversity.
+Whatever decision is taken in the end,...care should be taken, that
+these ports can continue to exist.
+
+
+Best wishes,
+Chris.
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 15:51:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Christoph Anton Mitterer <calestyo@scientia.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 15:51:08 GMT) (full text, mbox, link).

+ +

Message #3576 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Christoph Anton Mitterer <calestyo@scientia.net>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Fri, 17 Jan 2014 16:48:36 +0100
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, 2014-01-17 at 16:13 +0100, Josselin Mouette wrote:
+> Just because you don’t understand that sentence doesn’t mean you can use
+> it to justify whatever convoluted position of yours.
+I wonder who really doesn't understand here...
+
+> An operating system is universal if it can be used for all purposes.
+> An operating system that supports several kernels and init systems, but
+> all incompletely, letting the user choose between different ways of
+> failing to boot, is not universal. It is irrelevant to any serious use
+> case.
+... since which king is then,... who decides which way/init
+system/kernel/etc... is the "right", the universal, for all people?
+
+
+Cheers,
+Chris.
+
+
[smime.p7s (application/x-pkcs7-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 16:03:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 16:03:07 GMT) (full text, mbox, link).

+ +

Message #3581 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Christoph Anton Mitterer <calestyo@scientia.net>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Fri, 17 Jan 2014 16:01:12 +0000
+
+
Christoph Anton Mitterer writes ("Bug#727708: On diversity"):
+> On Fri, 2014-01-17 at 16:13 +0100, Josselin Mouette wrote:
+> > Just because you don’t understand that sentence doesn’t mean you can use
+> > it to justify whatever convoluted position of yours.
+> I wonder who really doesn't understand here...
+
+I think this discussion is sterile.  The "universal operating system"
+phrase is a slogan.  It's not sensible to go into a detailed semantic
+analysis of it.  If Josselin doesn't find it convincing then arguing
+over the meaning of "universal" or whatever isn't helpful.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 16:12:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Christoph Anton Mitterer <calestyo@scientia.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 16:12:04 GMT) (full text, mbox, link).

+ +

Message #3586 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Christoph Anton Mitterer <calestyo@scientia.net>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Fri, 17 Jan 2014 17:08:51 +0100
+
+
On Fri, 2014-01-17 at 16:01 +0000, Ian Jackson wrote:
+> The "universal operating system"
+> phrase is a slogan.
+Sure it is, but that slogan actually stands for some important
+principles in the open source world... like not to "force" stuff upon
+users... and allowing many different things to happily co-exist.
+Open source is also a lot about freedom (not only that of developers but
+also that of users)
+
+Now looking at the GNOME-background,... there are surely people who'd
+say that these folks have sometimes forgotten a bit those ideals.
+
+
+Anyway... I guess that's off topic to this discussion (sorry for
+that)... except perhaps that part,... that neither choice for an
+init-system should restrict the freedom of others (k/freebsd, hurd, the
+guys who like another init-system more) more than absolutely necessary.
+
+
+
+Cheers,
+Chris.
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 17:02:50 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 17:02:50 GMT) (full text, mbox, link).

+ +

Message #3591 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: Thorsten Glaser <tg@mirbsd.de>
+
Cc: Noa Resare <noa@spotify.com>, 727708@bugs.debian.org, + debian-bugs-dist@lists.debian.org, + Technical Committee <debian-ctte@lists.debian.org>
+
Subject: Re: Bug#727708: Spotify position in support of systemd in the + default init debate
+
Date: Fri, 17 Jan 2014 12:00:43 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Jan 17, 2014 at 04:37:45PM +0000, Thorsten Glaser wrote:
+> >- We believe that systemd will have the stronger community momentum moving
+> >forward when it comes to seeing close integration between modern init
+> >system features and upstream projects.
+> 
+> I believe that this is precisely a reason *against* choosing systemd,
+> as it leads to monoculture, vendor lock-in (even more than we already
+> have), replacement of UNIX with FLOS, and caters to Poettering fans.
+
+Debian's job is delivering a spot-on OS. Diverging with everyone else
+means we have to spend time and effort doing stuff that doesn't matter,
+namely, maintaining our own patches and changes to make software run in
+Debian, rather then spending effort on ensuring everything's stable.
+
+I know some folks enjoy this work, but I sure don't.
+
+Cheers,
+  Paul
+
+
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
+: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+`. `'`  http://people.debian.org/~paultag
+ `-     http://people.debian.org/~paultag/conduct-statement.txt
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 17:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 17:42:04 GMT) (full text, mbox, link).

+ +

Message #3596 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Andrew Shadura <andrew@shadura.me>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: OpenRC now works on GNU/Hurd! :)
+
Date: Fri, 17 Jan 2014 10:31:44 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Andrew Shadura <andrew@shadura.me> writes:
+
+> It is actually fairly easy to write an initscript which uses native
+> OpenRC facilities if they're available. While this serves little
+> practical use, I tried to play with this, and this is the result:
+
+Thanks for sharing that.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 17:42:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 17:42:07 GMT) (full text, mbox, link).

+ +

Message #3601 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: Christoph Anton Mitterer <calestyo@scientia.net>, 727708@bugs.debian.org
+
Cc: debian-bugs-dist@lists.debian.org, + Technical Committee <debian-ctte@lists.debian.org>
+
Subject: Re: Bug#727708: personal views of Debian users
+
Date: Fri, 17 Jan 2014 16:50:21 +0000 (UTC)
+
+
Christoph Anton Mitterer dixit:
+
+>- At most upstream projects (the kernel, wayland, X, etc. pp.) people
+>seem to at least think first about systemd...
+
+Only those that have strong ties to Poettering, Red Hat, GNOME.
+
+>if they support upstart at all.
+
+Right, upstart is, right now, a Canonical solution. But upstreams
+in general support SYSV init scripts (especially since LSB), whereas
+systemd is rarely seen across all upstreams (not just those already
+poettering’d’.
+
+But if Debian were to support Upstart, I could see this change.
+(And I never thought I’d see the day where something from *buntu
+can rescue Debian.)
+
+>Just look at recent developments like kdbus, which are clearly strongly
+>"influenced/triggered" by systemd.
+
+Or by people abusing the “message bus” for things it never was
+intended. And also, the kdbus “movement” comes from the Poettering
+crowd.
+
+>- Most other major distros (except *buntu) have decided for systemd,...
+>so again here,... with upstart we'd sit on a lone island, which
+>ultimately would lead to many problems for sure.
+
+Yes, but this is a very good reason to *not* join others, so we
+do not share their deficiencies either.
+
+>- In my opinion (and I'm sure some people will agree and others will
+>contrary): RedHat has proven to be more "neutral" to projects it
+>"governs" than Canonical.
+[…]
+>- With upstart there is the contributor license agreement issue... which
+>I think is a major political problem.
+
+Mh. This clearly is a problem, unless they’d be willing to open up
+this thing.
+
+But there’s also sysv-rc and OpenRC still as contenders. (I think
+file-rc – sadly – left the train.)
+
+>- Last but not least... there are people (including myself, I guess),...
+>which are concerned about the Debian/*buntu relationship in several
+>ways... so having upstart the default init system, would give Canonical
+>for sure some bit more of influence on Debian (and if it was just by
+>technical decisions they make upstream).
+
+I consider myself as one of these people too, but they’re influencing
+enough already, yet still the danger from Canonical (when balanced by
+the rest of the Debian mass) is perceived as much less than the danger
+from Poettering and Co.
+
+>Of course one can argue, that this kind of influence might now be taken
+>by RedHat.
+
+This is something I have been seeing more and more recently. The RedHat,
+“freedesktop”, GNOME people *are* trying to force everyone to do things,
+and not just some but everything, their way *only*. With *buntu, other
+things are at least just not supported commercially, modulo sponsoring
+the spin-offs to some degree. They try to promote their way, which may
+work well for a large percentage of the “average user”, but do not cut
+off experts entirely (granted, it becomes harder and harder to run a
+*buntu in a nōn-default configuration, but it’s not impossible, plus,
+Debian is not to become another *buntu just for supporting upstart.)
+
+Note I’m still in favour of supporting multiple init systems. (And there
+is absolutely *zero* reason anything like *kit (console, policy, package
+or whatever) or logind to use a system as a desktop. This is only used
+by some fancy additional optional and rarely used features. And never in
+your typical centrally-managed company desktops, for example.)
+
+>- I do have a big problem with projects (especially like GNOME) which
+>sometimes seem to have an agenda of enforcing people to use the
+>techniques they want. IMHO, open source IS about choice. But reality is
+>probably, that one cannot do much about it.
+
+And that’s where Debian is stong: ensuring the freedom of its *users*
+from people wanting to prescribe them things. Honestly, sometimes, the
+GNOME people are worse than Microsoft®…
+
+bye,
+//mirabilos
+-- 
+22:59⎜<Vutral> glaub ich termkit is kompliziert | glabe nicht das man
+damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil
+zuviel bilder │ wie ein spiel | 23:00⎜<Vutral> die meisten raffen auch
+nicht mehr von windows | 23:01⎜<Vutral> bilderbücher sind ja auch nich
+wirklich verbreitet als erwachsenen literatur	‣ who needs GUIs thus?
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 17:42:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 17:42:10 GMT) (full text, mbox, link).

+ +

Message #3606 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: Noa Resare <noa@spotify.com>, 727708@bugs.debian.org
+
Cc: debian-bugs-dist@lists.debian.org, + Technical Committee <debian-ctte@lists.debian.org>
+
Subject: Re: Bug#727708: Spotify position in support of systemd in the default + init debate
+
Date: Fri, 17 Jan 2014 16:37:45 +0000 (UTC)
+
+
Noa Resare dixit:
+
+>- We believe that systemd will have the stronger community momentum moving
+>forward when it comes to seeing close integration between modern init
+>system features and upstream projects.
+
+I believe that this is precisely a reason *against* choosing systemd,
+as it leads to monoculture, vendor lock-in (even more than we already
+have), replacement of UNIX with FLOS, and caters to Poettering fans.
+
+In short: if you want systemd, you can do that in a Debian Pure Blend
+or something else, IMHO…
+
+bye,
+//mirabilos (DD but speaking his own opinion)
+-- 
+13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good
+guy. But he's always right! In every fsckin' situation, he's right. Even
+with his deeply perverted taste in software and borked ambition towards
+broken OSes - in the end, he's damn right about it :(! […] works in mksh
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 17:42:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 17:42:13 GMT) (full text, mbox, link).

+ +

Message #3611 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: Moritz Muehlenhoff <jmm@debian.org>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>, debian-bugs-dist@lists.debian.org, + Technical Committee <debian-ctte@lists.debian.org>
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Fri, 17 Jan 2014 16:29:07 +0000 (UTC)
+
+
Moritz Muehlenhoff dixit:
+
+>FreeBSD upstream isn't a desktop OS and never will be, there're just too
+>many deficiencies (e.g. lack of dbus
+
+Eh, excuse me! It’s obviously possible to run a desktop without dbus!
+In fact, this is a feature, in my eyes.
+
+>limited hardware support
+
+Oh c’mon. Linux does not support any and all hardware either.
+
+>only OSS sound drivers
+
+I fail to see where the problem is with this.
+
+>limited KMS/3D support in Xorg
+
+As if that were not the case in Linux. Its support may be a
+bit broader but still limited.
+
+
+Sorry, but this is FUD.
+
+bye,
+//mirabilos
+-- 
+[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
+what about xfs, and if only i had waited until reiser4 was ready... in the be-
+ginning, there was ffs, and in the middle, there was ffs, and at the end, there
+was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 17:42:16 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 17:42:17 GMT) (full text, mbox, link).

+ +

Message #3616 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Christoph Anton Mitterer <calestyo@scientia.net>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Fri, 17 Jan 2014 09:34:46 -0800
+
+
Christoph Anton Mitterer <calestyo@scientia.net> writes:
+> On Fri, 2014-01-17 at 16:01 +0000, Ian Jackson wrote:
+
+>> The "universal operating system" phrase is a slogan.
+
+> Sure it is, but that slogan actually stands for some important
+> principles in the open source world... like not to "force" stuff upon
+> users... and allowing many different things to happily co-exist.
+
+It does for you.  It doesn't necessarily for everyone, and since there's
+no meat to the slogan beyond that one sentence, there's nothing there to
+persuade anyone that your interpretation is correct and someone else's is
+incorrect.
+
+I agree with Ian: there's no real point in using this as a basis for an
+argument, since it's not going to convince people.  I think there are
+other, better arguments in favor of supporting a variety of goals and
+projects in Debian.
+
+> Now looking at the GNOME-background,... there are surely people who'd
+> say that these folks have sometimes forgotten a bit those ideals.
+
+Again, please extend to your fellow developers the courtesy of assuming
+that they understand all of this background just as well as you do.
+People can disagree with each other without one of them being forgetful,
+or disagreeing with freedom, or possessing some other character flaw.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 17:42:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 17:42:20 GMT) (full text, mbox, link).

+ +

Message #3621 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Christoph Anton Mitterer <calestyo@scientia.net>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Fri, 17 Jan 2014 19:41:37 +0200
+
+
On Fri, Jan 17, 2014 at 05:08:51PM +0100, Christoph Anton Mitterer wrote:
+> On Fri, 2014-01-17 at 16:01 +0000, Ian Jackson wrote:
+> > The "universal operating system"
+> > phrase is a slogan.
+> Sure it is, but that slogan actually stands for some important
+> principles in the open source world... like not to "force" stuff upon
+> users... and allowing many different things to happily co-exist.
+> Open source is also a lot about freedom (not only that of developers but
+> also that of users)
+>...
+
+This is a common misconception:
+
+There is no such principle, and Open Source does not turn the developers 
+who (often in their spare time) work on the software into slaves of 
+their users. The exact opposite is true, and the developers who do the 
+work have the freedom to force whatever they want on the users of their 
+software.
+
+Among the freedoms Open Source gives to all users the relevant one is 
+actually the right to fork: If you don't like a policy decision of an 
+Open Source project, you can always create a fork that works exactly
+the way you envision it.
+
+This is quite fair in giving the power of making decisions not to the 
+users who scream loudest, but to the people who actually do the work.
+
+And for Debian the Technical Committee is the instance to make such 
+decisions on behalf of the whole project.
+
+> Cheers,
+> Chris.
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 17:51:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 17:51:09 GMT) (full text, mbox, link).

+ +

Message #3626 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Thomas Goirand <zigo@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: OpenRC now works on GNU/Hurd! :)
+
Date: Fri, 17 Jan 2014 09:46:41 -0800
+
+
Thomas Goirand <zigo@debian.org> writes:
+
+> It's with great joy that I can announce here that OpenRC now supports
+> GNU/Hurd. I have just added a few patches which were worked out with
+> upstream (you can look at them, it's really trival FTBFS fixing...),
+> tested it, and I can happily say it works.
+
+Congratulations, Thomas!  That's great news.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 18:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 18:09:04 GMT) (full text, mbox, link).

+ +

Message #3631 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: On diversity
+
Date: Fri, 17 Jan 2014 20:06:28 +0200
+
+
On Fri, 2014-01-17 at 16:08 +0100, Ihar Filipau wrote:
+> Uoti Urpala wrote:
+> > Even the upstart proponents do not seem to have significant arguments
+> > about upstart having better functionality, and there don't seem to be
+> > all that many people who would have a reasonably informed opinion that
+> > upstart would be technically better even for just their particular use.
+> 
+> I followed the discussion from the beginning and I'd like to comment on that.
+> My own comparison of systemd vs. upstart (Fedora 20 vs. Ubuntu 13.10) is still
+> fresh in my memory.
+
+Your comparison does not look very informed, see below.
+
+
+> 1. "upstart" is a highly configurable init system, while "systemd" hardcodes
+> most of the nuts and bolts in the 32 shipped executables. I spent one days
+
+Your "hardcodes" is wrong: systemd ships with helper executables and a
+default boot setup which uses those, but they're not hardcoded and you
+can use something else if you have a reason to.
+
+> So here you go. The advantage of the upstart, is that if you need to tweak the
+> boot of your system, you can do it right there, with the text editor, by
+> changing the .conf files or the shell scripts. While with the systemd, you have
+
+I strongly disagree that using shell more as an implementation language
+would be a good thing. But out of the things in your post I think this
+is the closest to a not-factually-incorrect personal preference someone
+could have for upstart: some people could prefer working in shell only.
+However, this isn't really a comparison of the init systems themselves
+so much as a comparison of the default boot setups shipped with the
+inits. Even if you decide that almost every program running on your
+system should be implemented in shell only, you could still use systemd
+to start those programs, though you'd need to change more of the default
+configuration if you wanted to avoid starting anything non-shell at
+boot.
+
+
+> 2. "upstart" was not designed or intended to be a SMF (service management
+> facility), while "systemd" was.
+> 
+> I think it is insincere of upstart proponents to even advertise it as such. On
+
+> On the other side of the fence. As I see it, it is only a coincidence that
+> "systemd" is also an init system. To me it was clearly designed from ground up
+> as SMF: boot and initialization were only afterthought. That's why the magic
+> binaries, because the initialization, an event driven process, simply doesn't
+> fit into the systemd "everything is a service" model.
+
+This is nonsense. Technically, the choice of implementation language for
+the binaries/scripts and the event/dependency model are completely
+orthogonal. This means your last sentence is completely wrong. It's also
+not plausible as a historical fact that boot would have been an
+"afterthought".
+
+
+> 3. Boot times. Though systemd was supposed to improve the boot time, Fedora 20
+> VM on my rig needs 1m5s-1m15s to start - while Ubuntu 13.10 VM always timed
+> flat 0m35s. That was pretty dumbfounding realization, especially after finding
+
+Other people have Fedora booting a lot faster. There are lots of reasons
+that could make boot slow other than inherent problems with the init
+system, so if you haven't done any analysis of the causes of the
+slowness, this does not really tell anything.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 18:27:16 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 18:27:16 GMT) (full text, mbox, link).

+ +

Message #3636 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Christoph Anton Mitterer <calestyo@scientia.net>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: personal views of Debian users
+
Date: Fri, 17 Jan 2014 10:26:27 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Jan 17, 2014 at 04:46:43PM +0100, Christoph Anton Mitterer wrote:
+> Well not sure whether this is actually welcomed or not,... but since
+> some people have already started to share their personal feelings about
+> the debate, I want to do so as well.
+
+I don't think this is necessary or helpful (regardless of which init system
+someone is in favor of).  The TC members each need to make up their own mind
+about what is technically best for Debian, and in a thread that's already
+over 1000 messages long, these personal testimonials are very unlikely to
+introduce any genuinely new technical arguments.  I don't think that adding
+to the TC's incoming mail load is going to help the process of reaching a
+sound decision.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 17 Jan 2014 19:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Noa Resare <noa@spotify.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 17 Jan 2014 19:30:04 GMT) (full text, mbox, link).

+ +

Message #3641 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Noa Resare <noa@spotify.com>
+
To: Thorsten Glaser <tg@mirbsd.de>
+
Cc: 727708@bugs.debian.org, debian-bugs-dist@lists.debian.org, + Technical Committee <debian-ctte@lists.debian.org>
+
Subject: Re: Bug#727708: Spotify position in support of systemd in the default + init debate
+
Date: Fri, 17 Jan 2014 20:27:19 +0100
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Jan 17, 2014 at 5:37 PM, Thorsten Glaser <tg@mirbsd.de> wrote:
+
+> Noa Resare dixit:
+>
+> >- We believe that systemd will have the stronger community momentum moving
+> >forward when it comes to seeing close integration between modern init
+> >system features and upstream projects.
+>
+> I believe that this is precisely a reason *against* choosing systemd,
+> as it leads to monoculture, vendor lock-in (even more than we already
+> have), replacement of UNIX with FLOS, and caters to Poettering fans.
+>
+> In short: if you want systemd, you can do that in a Debian Pure Blend
+> or something else, IMHO…
+>
+> bye,
+> //mirabilos (DD but speaking his own opinion)
+>
+>
+(these opinions are my own, and not cleared with Spotify leadership)
+
+I believe that examples can be found in the history of Free Software of
+both extremes. Personally I think that the current java stewardship by
+Oracle is an example where monoculture and vendor lock-in is a real
+problem, and there are examples where competing solutions to the same
+problem has needlessly diverted resources that would have made either
+solution substantially better.
+
+My conclusion is that the risks of vendor lock-in and monoculture inte case
+of systemd are smaller than the cost of losses due to duplicate efforts. I
+understand that you are not a fan of Lennart, but I believe that he has
+proven that given his frame of reference (bringing new kernel features to
+end users trumps compatibility with less feature rich environments) he is a
+person that listens to technical arguments. The better solution from a
+technical point of view tends to win over the over it's politically more
+convenient counterpart.
+
+/noa
+
+-- 
+Spotify Free Software coordinator, strategist and possibly even evangelist.
+I/O Tribe.
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 02:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 02:48:04 GMT) (full text, mbox, link).

+ +

Message #3646 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Anthony Towns <aj@erisian.com.au>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Fri, 17 Jan 2014 18:45:19 -0800
+
+
Anthony Towns <aj@erisian.com.au> writes:
+> To emulate systemd dependencies in an event model (ie, X depends on
+> Y), you'd need to do either:
+>
+>     * change Y's job to say "start on starting X"
+>     * add "stop on stopping Y" to X's job description
+>
+> or
+>
+>     * add a pre-start script to X in order to start Y first
+>     * add "stop on stopping Y" to X's job description
+>
+> The latter looks like it's the documented way of doing things.
+
+But maybe not the working and/or recommend one:
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#3150 (the quoted
+parts are important).
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 04:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 04:03:04 GMT) (full text, mbox, link).

+ +

Message #3651 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Fri, 17 Jan 2014 19:59:07 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Thu, Jan 16, 2014 at 12:08:41PM -0800, Russ Allbery wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> > AFAICT we are all agreed that:
+
+> > * Applications which aren't part of the init system must not require a
+> >   particular init to be pid 1.  (So in particular a desktop
+> >   environment may not require a particular pid 1.)
+
+> I still have concerns about this.
+
+> This position seems to be predicated on the assumption that applications
+> will be able to depend on a working logind for jessie, and that a working
+> logind will be provided for systems using sysvinit.  This apparently works
+> today with systemd-shim but will stop working with post-205 systemd.
+
+> I want to understand whether setting this requirement means that we're
+> intending to require that jessie ship with systemd 204, or, if not, what
+> level of certainty we have that post-205 logind will work with sysvinit
+> for jessie.
+
+I don't believe we need to know the answer to these questions to know that
+Ian's requirement is a correct one.  If we are saying that packages cannot
+drop their sysvinit scripts in jessie in order to ensure smooth upgrades,
+then the same requirement should apply to desktop environments, even if we
+don't know at the moment precisely how the maintainers of the affected
+packages will solve this - because having smooth upgrades between releases
+is a *baseline* for the quality of Debian integration, and we should not
+vacillate merely because some people fear it will be hard in this particular
+case.
+
+The consequences of a desktop environment having a hard dependency on a
+particular init system in jessie are that a desktop system becomes unusable
+partway through the upgrade.  If a user tries to open a new login session
+while the upgrade is in progress, or if for whatever reason the user running
+the upgrade logs out (or gets logged out due to a bug) and tries to log back
+in, this will in all likelihood fail.  I don't think that's an acceptable
+outcome; so the requirement not to hard-depend on systemd follows directly
+from this.
+
+There may be other failure modes if the system is rebooted partway through
+the upgrade, but that's always the case, and doesn't speak against declaring
+a dependency on an init system.
+
+Separately, I don't agree that it's actually hard to support logind on
+non-systemd for jessie.  This already works for v204, and the work to
+support v205 is in progress.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 04:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 04:15:04 GMT) (full text, mbox, link).

+ +

Message #3656 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Fri, 17 Jan 2014 20:13:30 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> I don't believe we need to know the answer to these questions to know
+> that Ian's requirement is a correct one.  If we are saying that packages
+> cannot drop their sysvinit scripts in jessie in order to ensure smooth
+> upgrades, then the same requirement should apply to desktop
+> environments, even if we don't know at the moment precisely how the
+> maintainers of the affected packages will solve this - because having
+> smooth upgrades between releases is a *baseline* for the quality of
+> Debian integration, and we should not vacillate merely because some
+> people fear it will be hard in this particular case.
+
+I believe it is reasonable to allow GNOME to require systemd as the init
+system if that's the only way to get a working logind with the software
+that we release with jessie, and I don't believe holding systemd to
+pre-206 in order to make that possible makes sense.  204 will be getting
+pretty long in the tooth by the time we get to the jessie release.
+
+So, basically, I disagree with this.
+
+Now, obviously, hopefully logind will work fine in the jessie release
+without requiring systemd as the init system, and this will all be
+theoretical, but I'm worried that we're going to paint ourselves into an
+unreasonable corner by stating a hard and fast rule about this before we
+know what the shape of the software will be at the time of the release.
+
+> The consequences of a desktop environment having a hard dependency on a
+> particular init system in jessie are that a desktop system becomes
+> unusable partway through the upgrade.  If a user tries to open a new
+> login session while the upgrade is in progress, or if for whatever
+> reason the user running the upgrade logs out (or gets logged out due to
+> a bug) and tries to log back in, this will in all likelihood fail.  I
+> don't think that's an acceptable outcome; so the requirement not to
+> hard-depend on systemd follows directly from this.
+
+Clearly the release team and the GNOME team will need to look at proper
+behavior during the upgrade, including aborted upgrades, but I think this
+is a separate issue that they would be looking at regardless.  If the
+dependency causes separate RC issues around upgrades, obviously those
+issues will need to be addressed, but I'm dubious about simply *assuming*
+it will without looking at how the actual system could be assembled or
+letting people try to find good solutions to the problem.
+
+In other words, it's not that I want to say the *opposite* of what Ian
+stated as consensus.  Rather, I want to make sure that we don't rule on
+things that we don't need to be ruling on, and make sure that we don't
+write a decision that effectively ends up telling the GNOME team that they
+have to get the version they target for jessie working without logind or
+have it removed from the archive.
+
+> Separately, I don't agree that it's actually hard to support logind on
+> non-systemd for jessie.  This already works for v204, and the work to
+> support v205 is in progress.
+
+In this case, omitting this requirement from our ruling won't actually
+make any difference, since it will be easy to support and hence
+uncontroversial.  So, either way, I think we should make sure the
+statement we make permits packages to depend on logind.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 04:45:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 04:45:09 GMT) (full text, mbox, link).

+ +

Message #3661 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Thoughts on Init System Debate
+
Date: Fri, 17 Jan 2014 20:41:32 -0800
+
+
First off, I'd like to apologize again for taking so long to figure out
+and write up my opinion. I still feel a little bit swamped with all of
+the information that I've reviewed to come to my opinion, and I
+certainly don't yet completely understand the full architecture of
+either upstart or systemd even though I've been working with them both
+for a while now
+
+From the information which I have reviewed, and seen, either upstart or
+systemd are viable choices for Debian, but we must choose between them.
+
+Upstart has much clearer documentation than systemd, but systemd's
+documentation is sufficient.[1]
+
+Systemd's declarative style has the advantage of being directly
+parsable, but the disadvantage of forcing logic out into daemons...
+though that's probably where it should be in the first place.[2]
+
+Upstart's CLA is problematic, and coupled with the fact that the rest of
+the non-Debian distributions appear to be standardizing on systemd gives
+me pause. I'm not sure if this is actually a major concern, though, as
+long as Ubuntu continues using upstart.
+
+Systemd's socket-based activation and cgroup based tracking are
+technically superior to upstart, even though the latter causes problems
+with portability to non-linux systems. However, if we were to decide on
+upstart, we could have just a single init system everywhere, which would
+be beneficial.[3]
+
+Writing non-complicated unit or job files for systemd or upstart is
+fairly straightforward, and should be easy for the vast majority of
+packages. [A strong argument could be made that packages like
+spamass-milter which it isn't so straightforward are deficient.]
+
+With all that said, I think all of these considerations give me a slight
+preference for systemd over upstart, though I believe that whatever the
+committee decides on will be a great improvement over venerable SysV.
+
+I should point out that I have not extensively examined openrc, nor have
+I taken into account planned features and development in either systemd
+or upstart which could sway my opinion.
+
+Finally, thanks to everyone who has participated in this massive thread,
+writing position statements, and putting up with all of the questions
+that the CTTE has had.
+
+1: For example, systemd could have much better introductory
+documentation for unit file writers than it currently has. It also
+describes many of its features in blog posts which are not written into
+a cohesive manual which flows. I suspect these will be rectified in the
+future, but I found it fairly frustrating to deal with.
+
+It would also be super-nice, since almost all of systemd's configuration
+is in /lib/systemd/system for there to be a manpage or similar which had
+all of them and pointers to documentation what they did, etc.
+
+2: It's sort of annoying that systemd's declarative syntax has knobs
+like CondtionPathExists= etc, but doesn't have methods of then wrapping
+segments of the unit file in conditionals. Instead, the solution
+appears to be writing multiple unit files with the correct sets of
+Condition...= But perhaps I'm missing something. (This matters to be
+because of
+http://svn.donarmstrong.com/deb_pkgs/spamass-milter/trunk/debian/spamass-milter.init )
+
+3: Frankly, I don't want to support more than one set of init files; if
+the other architectures are to be release architectures, they really
+should get whatever the CTTE decides is the default init system ported
+to them, and the maintainers of that init system in Debian should accept
+patches to do so, even if it means that the default init system is less
+functional on those architectures than it would otherwise be. [Even
+without cgroups, it'll be superior to sysv, after all.]
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+Clothes make the man. Naked people have little or no influence on
+society.
+ -- Mark Twain 
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 04:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 04:54:04 GMT) (full text, mbox, link).

+ +

Message #3666 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Don Armstrong <don@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Sat, 18 Jan 2014 04:43:05 -0008
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Jan 17, 2014 at 8:41 PM, Don Armstrong <don@debian.org> wrote
+> Upstart's CLA is problematic, and coupled with the fact that the rest 
+> of
+> the non-Debian distributions appear to be standardizing on systemd 
+> gives
+> me pause. I'm not sure if this is actually a major concern, though, as
+> long as Ubuntu continues using upstart.
+> 
+
+If you have the time, I must ask: if Upstart had no CLA, would you 
+prefer it over systemd?
+
+--
+Cameron Norman
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 05:12:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 05:12:04 GMT) (full text, mbox, link).

+ +

Message #3671 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Fri, 17 Jan 2014 21:08:23 -0800
+
+
On Sat, 18 Jan 2014, Cameron Norman wrote:
+> If you have the time, I must ask: if Upstart had no CLA, would you
+> prefer it over systemd?
+
+No, but it would certain close the gap even more.
+
+Wildly Off-Topic: I should note that I think if upstart did not have the
+CLA that it does, the rest of the FOSS world might have just improved
+it, and systemd might never have shown up. I suspect that the fate of
+bzr might be similar.
+
+These should serve as a cautionary tale for for-profit companies
+requiring CLAs. [Or everyone, even.]
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+Live and learn
+or die and teach by example
+ -- a softer world #625
+    http://www.asofterworld.com/index.php?id=625
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 07:21:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 07:21:05 GMT) (full text, mbox, link).

+ +

Message #3676 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Anthony Towns <aj@erisian.com.au>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Fri, 17 Jan 2014 23:19:49 -0800
+
+
Anthony Towns <aj@erisian.com.au> writes:
+
+> To emulate systemd dependencies in an event model (ie, X depends on
+> Y), you'd need to do either:
+
+>     * change Y's job to say "start on starting X"
+>     * add "stop on stopping Y" to X's job description
+
+> or
+
+>     * add a pre-start script to X in order to start Y first
+>     * add "stop on stopping Y" to X's job description
+
+> The latter looks like it's the documented way of doing things. Neither
+> of those seem particularly great -- I think that's due to upstart not
+> letting you reverse event descriptions in the same way that systemd has
+> Requires/RequiredBy statements. If you could say:
+
+>    * on starting start Y
+>    * stop on stopping Y
+
+> in X's job description, by contrast, I think that would be a fine way of
+> declaring a "dependency" from X to Y without leaving the "event"
+> model. Not having a simple way of specifying this sort of dependency
+> seems pretty weak on upstart's behalf.
+
+It's worth noting that even the second solution above does not allow
+simulation of systemd's Requisite=, only Requires=.  Now, normally
+Requires= (when starting X, start Y if not already started) is going to be
+fine, but I can certainly imagine cases where Requisite= (if Y is not
+started, just immediately fail startup of X) is the behavior one actually
+wants.  I'm not sure how you would pry that behavior out of upstart's
+event model short of bypassing the event structure entirely and just
+writing an explicit check in shell in pre-start to ask whether Y is
+running.  Which, of course, one can certainly do, but it means that
+information is now stored outside the dependency graph in
+difficult-to-parse shell and doesn't show up in analysis tools, etc.
+
+It took me a long time to wrap my mind around the objections to upstart's
+event model, but now that I'm starting to understand the exception cases,
+I keep seeing more things that feel like they should be straightforward
+but end up oddly convoluted when expressed in upstart's event model.
+
+> It would probably also be nice to have a way of saying "when a new
+> network comes up, reload/refresh service X" -- so that it could bind to
+> new ports or whatever even if it was already running; that seems like
+> the sort of thing that would be easier to specify in an event model ("on
+> new-network-interface-started reload or start"), than in a dependency
+> model.
+
+That, however, is also a good point.  This specific case is the place
+where an event model does have a clear advantage.  It looks like the
+preferred strategy in the systemd model is to teach daemons to watch for
+this themselves, which while certainly a good idea (most high-quality UDP
+daemons I know of that care about binding to specific interfaces do in
+fact do this), is decidedly non-trivial and hard to do portably if the
+daemon doesn't already support it.  Freebind sockets get one out of a lot
+of the places where this is needed, but not all of them.
+
+In general, it would be nice to move this sort of thing out of the daemon
+into the init system.  Given that there's already a system service that
+knows when things like this happen, duplicating that listening code in all
+the daemons isn't as appealing as just letting the system service inform
+the daemons when it happens.
+
+That said, I think the dependency model is a lot clearer in the common
+cases, and the places where the event model is superior are fairly
+unusual.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 07:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 07:39:04 GMT) (full text, mbox, link).

+ +

Message #3681 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Sat, 18 Jan 2014 17:36:53 +1000
+
+
On 18 January 2014 17:19, Russ Allbery <rra@debian.org> wrote:
+> It's worth noting that even the second solution above does not allow
+> simulation of systemd's Requisite=, only Requires=.  Now, normally
+> Requires= (when starting X, start Y if not already started) is going to be
+> fine, but I can certainly imagine cases where Requisite= (if Y is not
+> started, just immediately fail startup of X) is the behavior one actually
+> wants.  I'm not sure how you would pry that behavior out of upstart's
+> event model short of bypassing the event structure entirely and just
+> writing an explicit check in shell in pre-start to ask whether Y is
+> running.
+
+I think this would be most analogous to the "complex conditions" bit,
+where you'd say
+
+  start on Y and Q
+
+so that it will only be started when event "Q" happens if "Y" has also
+already happened. I don't see how you'd prevent it from being manually
+started without a prescript checking for Y though, but I'm not
+entirely sure if that bothers me -- if I'm manually telling it to
+start a daemon, that's configured not to automatically start some
+thing it needs, do I care that much if I get an error from upstart or
+the daemon itself?
+
+Of course, upstart's "complex conditions" are documented not to work
+the way you'd expect, so that's not entirely a solution. I could
+easily imagine the complex condition support being enhanced to work to
+fix the behaviour described in [0] and to also block manual starts of
+the service prior to events happening, but that's not something that
+exists now afaics. And the CLA's essentially the opposite of saying
+"patches welcome"...
+
+(Personally, I think I'm convincing myself that in an ideal world I'd
+prefer the event model. upstart doesn't seem to implement that
+sufficiently though at this point. Sigh, now I'm imagining an event
+based init system written in haskell...)
+
+Cheers,
+aj
+
+[0] http://upstart.ubuntu.com/cookbook/#restarting-jobs-with-complex-conditions
+
+-- 
+Anthony Towns <aj@erisian.com.au>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 08:03:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 08:03:08 GMT) (full text, mbox, link).

+ +

Message #3686 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Don Armstrong <don@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Sat, 18 Jan 2014 09:58:25 +0200
+
+
On Fri, Jan 17, 2014 at 08:41:32PM -0800, Don Armstrong wrote:
+>...
+> With all that said, I think all of these considerations give me a slight
+> preference for systemd over upstart, though I believe that whatever the
+> committee decides on will be a great improvement over venerable SysV.
+>...
+> 3: Frankly, I don't want to support more than one set of init files; if
+> the other architectures are to be release architectures, they really
+> should get whatever the CTTE decides is the default init system ported
+> to them, and the maintainers of that init system in Debian should accept
+> patches to do so, even if it means that the default init system is less
+> functional on those architectures than it would otherwise be. [Even
+> without cgroups, it'll be superior to sysv, after all.]
+
+Note that everyone (including systemd upstream [1]) agrees that it is 
+impossible to port systemd to non-Linux kernels. And if anyone would 
+(against all odds) actually succeed in doing such a port, then systemd 
+upstream would not accept patches.[2] [3]
+
+The CTTE might decide "Systemd should be the only init system in Debian",
+but that would clearly imply that Debian will drop all non-Linux ports.
+
+cu
+Adrian
+
+[1] https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html
+[2] https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00456.html
+[3] I know both emails are from 2011, but this thread is the only one
+    I recall to provide an (incomplete) list of potentially Linux-only
+    features used by systemd. From all I've read Lennart's opinions haven't
+    changed since then - may someone correct me if I'm wrong on that.
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 08:03:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to HacKurx <hackurx@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 08:03:11 GMT) (full text, mbox, link).

+ +

Message #3691 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: HacKurx <hackurx@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: OpenRC
+
Date: Sat, 18 Jan 2014 08:59:47 +0100
+
+
If notice of a systems administrator interests you:
+upstart & systemd > /dev/null
+
+Now please go look OpenRC:
+http://en.wikipedia.org/wiki/OpenRC
+
+I put the link to wikipedia :)
+Lightweight, easily editable and portable. What more?
+
+Best regards,
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 08:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 08:24:04 GMT) (full text, mbox, link).

+ +

Message #3696 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Sat, 18 Jan 2014 09:20:18 +0100
+
+
]] Russ Allbery 
+
+> That, however, is also a good point.  This specific case is the place
+> where an event model does have a clear advantage.  It looks like the
+> preferred strategy in the systemd model is to teach daemons to watch for
+> this themselves, which while certainly a good idea (most high-quality UDP
+> daemons I know of that care about binding to specific interfaces do in
+> fact do this), is decidedly non-trivial and hard to do portably if the
+> daemon doesn't already support it.  Freebind sockets get one out of a lot
+> of the places where this is needed, but not all of them.
+
+I believe you can do this fairly easily.
+
+A is the service that needs to be reloaded when a network device shows
+up.  In A's service file, have ReloadPropagatedFrom=network.target and
+then make your ifup@.service include an ExecStart=systemctl reload
+network.target.  You probably want the same for ExecStop too, to handle
+interfaces going away.
+
+Another alternative is having multiple instance services and using
+BindTo=sys-subsystem-net-devices-%i.device (like ifup@.service is
+doing).
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 08:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 08:54:04 GMT) (full text, mbox, link).

+ +

Message #3701 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sat, 18 Jan 2014 09:49:52 +0100
+
+
* Russ Allbery (rra@debian.org) [140118 05:15]:
+> Steve Langasek <vorlon@debian.org> writes:
+> 
+> > I don't believe we need to know the answer to these questions to know
+> > that Ian's requirement is a correct one.  If we are saying that packages
+> > cannot drop their sysvinit scripts in jessie in order to ensure smooth
+> > upgrades, then the same requirement should apply to desktop
+> > environments, even if we don't know at the moment precisely how the
+> > maintainers of the affected packages will solve this - because having
+> > smooth upgrades between releases is a *baseline* for the quality of
+> > Debian integration, and we should not vacillate merely because some
+> > people fear it will be hard in this particular case.
+> 
+> I believe it is reasonable to allow GNOME to require systemd as the init
+> system if that's the only way to get a working logind with the software
+> that we release with jessie, and I don't believe holding systemd to
+> pre-206 in order to make that possible makes sense.  204 will be getting
+> pretty long in the tooth by the time we get to the jessie release.
+
+I however believe that it would be a major fault if installation of
+gnome would exchange the init system / pid1, so my expectation on
+Debian would be that we integrate into a system where Gnome could be
+used without systemd as pid1 or systemwide init-system (having gnome
+require systemd to be installed as a "daemon" however would be ok,
+same as e.g. cereal depends on runit - nothing new, and nothing
+worrying).
+
+
+> In other words, it's not that I want to say the *opposite* of what Ian
+> stated as consensus.  Rather, I want to make sure that we don't rule on
+> things that we don't need to be ruling on, and make sure that we don't
+> write a decision that effectively ends up telling the GNOME team that they
+> have to get the version they target for jessie working without logind or
+> have it removed from the archive.
+
+"working without systemd" doesn't translate for me into "they are not
+allowed to use new features of systemd", so it might be that gnomes
+integration with systemd is better than with other init-systems /
+pid1 providers. But I would consider it inappropriate if "apt-get
+install gnome" replaces my initsystem / pid1.
+
+
+
+> > Separately, I don't agree that it's actually hard to support logind on
+> > non-systemd for jessie.  This already works for v204, and the work to
+> > support v205 is in progress.
+> 
+> In this case, omitting this requirement from our ruling won't actually
+> make any difference, since it will be easy to support and hence
+> uncontroversial.  So, either way, I think we should make sure the
+> statement we make permits packages to depend on logind.
+
+Perhaps we could add an comment saying that as the situation is as of
+above, we don't expect an issue programms requiring logind.
+
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 09:21:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 09:21:08 GMT) (full text, mbox, link).

+ +

Message #3706 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sat, 18 Jan 2014 11:18:47 +0200
+
+
On Fri, Jan 17, 2014 at 08:13:30PM -0800, Russ Allbery wrote:
+>...
+> I believe it is reasonable to allow GNOME to require systemd as the init
+> system if that's the only way to get a working logind with the software
+> that we release with jessie,
+
+Why does logind actually have to be a hard dependency for GNOME in jessie?
+
+May someone correct me if I'm wrong, but as far as I can see from a 
+quick look at the sources, as of today GNOME still supports ConsoleKit
+as alternative to logind.
+
+And if the Debian GNOME maintainers would tell GNOME upstream that 
+shipping GNOME 3.14 in jessie would only be possible if the existing
+ConsoleKit support does not get removed until then, that might be
+enough for having that working in jessie.
+
+> and I don't believe holding systemd to
+> pre-206 in order to make that possible makes sense.  204 will be getting
+> pretty long in the tooth by the time we get to the jessie release.
+>...
+
+What is your general position on what dependencies on a specific init 
+system are acceptable, and which are not, if the CTTE decision will
+be that Debian will support multiple init systems?
+
+Worst case:
+I can imagine valid technical reasons why systemd upstream might make
+udev depend on other parts of systemd. Hypothetically, tomorrow a new
+systemd release might be released where udev depends on systemd being
+the init system.
+
+network-manager is among the packages that already switched from
+ConsoleKit to logind in experimental (upstream still supports both).
+Looking at popcon stats, network-manager is used by 40% of all Debian
+users.
+
+udev is used by > 99% of all users of Debian on Linux. [1]
+
+What percentage of Debian users locked into one init system by package 
+dependencies would be the threshold for making a CTTE decision
+"Debian supports multiple init systems" a farce?
+
+cu
+Adrian
+
+[1] using the Inst stats from popcon, since the Vote number looks bogus
+    and it is unlikely that many people have udev installed without
+    using it
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 13:03:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 13:03:05 GMT) (full text, mbox, link).

+ +

Message #3711 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Don Armstrong <don@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Sat, 18 Jan 2014 12:58:48 +0000
+
+
Don Armstrong writes ("Bug#727708: Thoughts on Init System Debate"):
+> 3: Frankly, I don't want to support more than one set of init files; if
+> the other architectures are to be release architectures, they really
+> should get whatever the CTTE decides is the default init system ported
+> to them, and the maintainers of that init system in Debian should accept
+> patches to do so, even if it means that the default init system is less
+> functional on those architectures than it would otherwise be. [Even
+> without cgroups, it'll be superior to sysv, after all.]
+
+This, together with your earlier comments that you somewhat prefer
+systemd, is not realistic.  No-one has seriously suggested that making
+systemd portable would be feasible, and reimplementing it would be a
+very big project.
+
+Do you recognise that a decision to make systemd the only supported
+init would mean the end of non-Linux-based ports of Debian ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 14:18:03 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 14:18:03 GMT) (full text, mbox, link).

+ +

Message #3716 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sat, 18 Jan 2014 09:14:34 -0500
+
+
On Fri, Jan 17, 2014 at 11:29 AM, Thorsten Glaser wrote:
+> Moritz Muehlenhoff dixit:
+>
+>>FreeBSD upstream isn't a desktop OS and never will be, there're just too
+>>many deficiencies (e.g. lack of dbus
+>
+> Eh, excuse me! It’s obviously possible to run a desktop without dbus!
+> In fact, this is a feature, in my eyes.
+
+I think Moritz's point is that the project should get to the point
+where it is perceived as ok for the non-linux ports to lose things
+like gnome once it entirely depends on linux-only features (lots of
+alternative desktops xfce, lxde, etc. still of course remain).  To
+make that ok, the % build requirement for kfreebsd/hurd will probably
+need to be reduced.
+
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 17:39:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 17:39:15 GMT) (full text, mbox, link).

+ +

Message #3721 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Sat, 18 Jan 2014 09:34:33 -0800
+
+
Anthony Towns <aj@erisian.com.au> writes:
+
+> I think this would be most analogous to the "complex conditions" bit,
+> where you'd say
+
+>   start on Y and Q
+
+> so that it will only be started when event "Q" happens if "Y" has also
+> already happened. I don't see how you'd prevent it from being manually
+> started without a prescript checking for Y though, but I'm not entirely
+> sure if that bothers me -- if I'm manually telling it to start a daemon,
+> that's configured not to automatically start some thing it needs, do I
+> care that much if I get an error from upstart or the daemon itself?
+
+That depends on whether you think you'll ever want to have a job that
+won't be able to detect its own prerequisites and might just do something
+harmful if started without its prerequisites instead of exiting with an
+error.  But agreed, that's probably relatively rare, and upstart *does*
+offer a way to represent that via a pre-start shell condition.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 17:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 17:48:04 GMT) (full text, mbox, link).

+ +

Message #3726 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sat, 18 Jan 2014 09:45:35 -0800
+
+
Adrian Bunk <bunk@stusta.de> writes:
+
+> Why does logind actually have to be a hard dependency for GNOME in
+> jessie?
+
+If it doesn't, then it's not an issue.  But it seemed like at least a
+possibility given upstream GNOME direction.
+
+> What is your general position on what dependencies on a specific init
+> system are acceptable, and which are not, if the CTTE decision will be
+> that Debian will support multiple init systems?
+
+In general, I think it should be up to the maintainers of that package,
+with the understanding that it's potentially pretty obnoxious for our
+users to require one init system, so it's not something to do lightly.  I
+truly don't think this will be a problem.  Debian contributors already
+understand this sort of thing.
+
+If software that people want to package for Debian is deeply entangled in
+one init system (that is supported in Debian), for good or for ill,
+regardless of what one might think of the decisions made by upstream that
+created that situation, I think it's going rather far to require the
+Debian package maintainers to port it to different init systems in order
+to get (or keep) their package in Debian.  I have a very hard time
+defending that position.
+
+> Worst case:
+> I can imagine valid technical reasons why systemd upstream might make
+> udev depend on other parts of systemd. Hypothetically, tomorrow a new
+> systemd release might be released where udev depends on systemd being
+> the init system.
+
+> network-manager is among the packages that already switched from
+> ConsoleKit to logind in experimental (upstream still supports both).
+> Looking at popcon stats, network-manager is used by 40% of all Debian
+> users.
+
+Note that I expect popcon stats to massively overcount desktops relative
+to servers, so I'm pretty sure this percentage is wildly inflated.  For
+example, I have more than 200 systems not reporting to popcon (it's hard
+to justify running popcon from a security perspective since, although the
+risk is low, the upside for my employer is also very low), and not a
+single one of them runs network-manager.  They all just use ifupdown.  I
+expect that to be a very common scenario.
+
+> udev is used by > 99% of all users of Debian on Linux. [1]
+
+udev is getting close to required on Linux already.  I'm not sure how many
+people are testing the non-udev code paths, particularly for more obscure
+packages.  And that's the way I would expect this to go.  The non-default
+cases that are rarely used will tend to bitrot unless someone who cares
+about them puts the work into making sure they keep working, and there's
+some way to do that work that doesn't put too much of a burden on everyone
+else.
+
+> What percentage of Debian users locked into one init system by package 
+> dependencies would be the threshold for making a CTTE decision
+> "Debian supports multiple init systems" a farce?
+
+I don't think percentage of users is the right metric.  By that metric,
+Debian doesn't support kFreeBSD or Hurd right now.  And yet, we do, even
+though some of our software is not ported to those platforms yet (and
+possibly ever).
+
+I'm not sure the exact answer to your question, but I don't believe that
+GNOME requiring systemd would make "Debian supports multiple init systems"
+a farce.  There are a bunch of other desktop environments, some of which
+have more interest in portability (including to non-Linux, which would
+obviously rule out a hard systemd dependency), as well as a bunch of ways
+to use Debian that don't involve a desktop environment at all (like
+servers).  It would be nice if we could avoid it as long as people have
+reasons to not want to use systemd (which may be indefinitely), but I also
+don't think that burden should be carried by the GNOME package
+maintainers.  *If* it ends up being a burden.  Steve doesn't think it will
+be much of a burden, and I hope he's right.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 17:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 17:51:04 GMT) (full text, mbox, link).

+ +

Message #3731 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system thoughts
+
Date: Sat, 18 Jan 2014 09:47:27 -0800
+
+
Tollef Fog Heen <tfheen@err.no> writes:
+
+> I believe you can do this fairly easily.
+
+> A is the service that needs to be reloaded when a network device shows
+> up.  In A's service file, have ReloadPropagatedFrom=network.target and
+> then make your ifup@.service include an ExecStart=systemctl reload
+> network.target.  You probably want the same for ExecStop too, to handle
+> interfaces going away.
+
+Oh, thank you!  I didn't know about ReloadPropagatedFrom= and
+PropagatesReloadTo=.  That looks quite a bit like an event.  :)
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 18:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 18:03:04 GMT) (full text, mbox, link).

+ +

Message #3736 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Sat, 18 Jan 2014 09:59:39 -0800
+
+
On Sat, 18 Jan 2014, Ian Jackson wrote:
+> Do you recognise that a decision to make systemd the only supported
+> init would mean the end of non-Linux-based ports of Debian ?
+
+Which is why I'm not proposing it at this juncture. However, moving to a
+single supported init system with a defined interface is something that
+I would like to see. 
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+Tell me something interesting about yourself.
+Lie if you have to.
+ -- hugh macleod http://www.gapingvoid.com/archives/batch20.php
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 18:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 18:57:04 GMT) (full text, mbox, link).

+ +

Message #3741 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sat, 18 Jan 2014 20:54:40 +0200
+
+
On Sat, Jan 18, 2014 at 09:45:35AM -0800, Russ Allbery wrote:
+>...
+> If software that people want to package for Debian is deeply entangled in
+> one init system (that is supported in Debian), for good or for ill,
+> regardless of what one might think of the decisions made by upstream that
+> created that situation, I think it's going rather far to require the
+> Debian package maintainers to port it to different init systems in order
+> to get (or keep) their package in Debian.  I have a very hard time
+> defending that position.
+
+So in the hypothetical case that systemd upstream decides to make udev 
+hard depend on systemd being pid 1, would you even defend that such a
+change could go into jessie if the CTTE decision was that Debian should
+support multiple init systems?
+
+ 
+> > Worst case:
+> > I can imagine valid technical reasons why systemd upstream might make
+> > udev depend on other parts of systemd. Hypothetically, tomorrow a new
+> > systemd release might be released where udev depends on systemd being
+> > the init system.
+>...
+> > udev is used by > 99% of all users of Debian on Linux. [1]
+> 
+> udev is getting close to required on Linux already.
+>...
+
+We are in full agreement on that.
+
+And my point on top of that is that if the CTTE decsion would be that 
+Debian should support multiple init systems, but it does not set a 
+policy limiting strictly what hard dependencies on systemd are allowed,
+then it would be better if the CTTE would rule that Debian should 
+support only systemd since that's what would anyway happen in practice
+through package dependencies pretty soon.
+
+If Debian wants to support multiple init systems and wants to continue 
+supporting non-Linux ports, then Debian's policy must force Debian 
+maintainers to put pressure on their upstreams to keep support for
+non-systemd systems and for non-Linux kernels.
+
+And where that is not possible, such issues have to be resolved before 
+the packages hit unstable. [1]
+
+
+cu
+Adrian
+
+[1] E.g. in the hypothetical udev worst case, a second udev package
+    based on a fork that does not depend on systemd might be required.
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 19:24:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 19:24:05 GMT) (full text, mbox, link).

+ +

Message #3746 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sat, 18 Jan 2014 21:20:00 +0200
+
+
On Fri, Jan 17, 2014 at 12:51:48PM +0000, Ian Jackson wrote:
+> Adrian Bunk writes ("Re: Bug#727708: Init system resolution open questions"):
+> > (Only as a PM since I am repeating myself.)
+> 
+> Thanks for your mail.  I think it deserves wider consideration.
+> 
+> > One question you should consider adding:
+> > 
+> > * What switching between init systems has to be supported?
+> >   Should it be possible for the user to switch from one supported init 
+> >   system to another supported init system at any point (it is OK if that 
+> >   requires a reboot), or is it acceptable if that is not possible in all 
+> >   cases or even not at all?
+> 
+> It seems obvious to me that if multiple ones are supported that there
+> has to be some way to get from using one to using a different one.  So
+> the question is more one of how difficult it is.
+
+If it is clear for you that this is a requirement, please state it 
+explicitely for the "multiple init systems supported" option:
+
+ * Any supported init system must support switching a running system
+   from any other supported init system to this init system, as well
+   as switching a running system from this init system to any other
+   supported init system. This switch is expected to require a reboot.
+
+
+> Thanks,
+> Ian.
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 19:24:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 19:24:09 GMT) (full text, mbox, link).

+ +

Message #3751 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sat, 18 Jan 2014 11:22:06 -0800
+
+
Adrian Bunk <bunk@stusta.de> writes:
+> On Sat, Jan 18, 2014 at 09:45:35AM -0800, Russ Allbery wrote:
+
+>> If software that people want to package for Debian is deeply entangled
+>> in one init system (that is supported in Debian), for good or for ill,
+>> regardless of what one might think of the decisions made by upstream
+>> that created that situation, I think it's going rather far to require
+>> the Debian package maintainers to port it to different init systems in
+>> order to get (or keep) their package in Debian.  I have a very hard
+>> time defending that position.
+
+> So in the hypothetical case that systemd upstream decides to make udev 
+> hard depend on systemd being pid 1, would you even defend that such a
+> change could go into jessie if the CTTE decision was that Debian should
+> support multiple init systems?
+
+It would, of course, depend on *why* they made that decision, but at least
+on the surface that seems like it would prevent us from either supporting
+multiple init systems or having a reasonable upgrade from sysvinit.  Those
+would both be significant drawbacks, so I think in such a situation we
+should look for alternatives.  (And I know the udev maintainer really
+wants to require a modern init system -- that was one of the messages that
+set off this discussion -- but I do think it would be worthwhile waiting
+until after jessie to take that step.)
+
+You may be noticing a theme here: I'm refusing to take hard positions, in
+advance, on theoretical future possibilities.  I think that's part of the
+responsibility of the Technical Committee.  See 6.3.6:
+
+    Technical Committee makes decisions only as last resort.
+
+    The Technical Committee does not make a technical decision until
+    efforts to resolve it via consensus have been tried and failed, unless
+    it has been asked to make a decision by the person or body who would
+    normally be responsible for it.
+
+I believe the spirit of that provision includes not borrowing trouble for
+ourselves by making definitive statements about future events that may or
+may not happen.  Remember, the context of this discussion is around
+whether the Technical Committee, assuming that we choose systemd as a
+default, will require that all software in Debian that's part of the
+jessie release work with sysvinit as well.  I'm pointing out edge cases
+and possible drawbacks to making a firm and sweeping statement without
+knowing, in advance, *why* some piece of software doesn't work with
+sysvinit.  Other people have pointed out other cases, such as software
+that was never part of previous releases and hence doesn't pose upgrade
+issues.
+
+> We are in full agreement on that.
+
+> And my point on top of that is that if the CTTE decsion would be that
+> Debian should support multiple init systems, but it does not set a
+> policy limiting strictly what hard dependencies on systemd are allowed,
+> then it would be better if the CTTE would rule that Debian should
+> support only systemd since that's what would anyway happen in practice
+> through package dependencies pretty soon.
+
+And yet there are still people who use Debian without udev (or at least I
+think there is based on debian-devel discussion).  Why go out of our way
+to tell those people to go away?
+
+There is a natural process here, where rarely-used configurations slowly
+stop working and people eventually decide not to bother to keep them
+working and move on to other things.  Eventually, they may acquire RC bugs
+that no one wants to fix and be dropped, or the package maintenance team
+may decide that they just can't support the configuration any more, make a
+public call for people to step forward and maintain it, and, when that
+call isn't answered, drop support.
+
+The drawback of trying to short-circuit that process is that it's quite
+easy to guess wrong and decide to proactively drop support for something
+that turns out to not be that hard to continue to support, or that someone
+else wants to support and is willing to do all the work to support.  I'd
+rather leave it to the expert analysis of the people directly involved,
+and don't want to skip past the courtesy of inviting people to find a way
+to fix the problem if they care about it.
+
+To take another example, do you think the Technical Committee should have
+said that file-rc is not supported?  I don't see why we should make that
+sort of proactive statement.  Yes, it doesn't work very well, and has some
+problems, but people have still been using it, and people are still
+willing to fix problems with it, so why go out of our way to tell those
+people to stop?
+
+In other words, I would rather be clear about what we consider to be the
+primary technical direction, and the core functionality that we should try
+to support, and let the long tail and personal projects take care of
+themselves.  Some of them will fade away, some of them will putter along
+in the background without hurting anyone, and we may be quite surprised by
+one of them becoming a huge asset to the project later on.  That's why I
+like the framing of this discussion as deciding the *default*.
+
+> If Debian wants to support multiple init systems and wants to continue
+> supporting non-Linux ports, then Debian's policy must force Debian
+> maintainers to put pressure on their upstreams to keep support for
+> non-systemd systems and for non-Linux kernels.
+
+Sort of.  But I don't think that level of pressure is necessarily higher
+than the pressure we've been putting on upstream to support Hurd for
+years, which has amounted to a small stream of patches that are generally
+unobjectionable.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 18 Jan 2014 20:36:23 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 18 Jan 2014 20:36:23 GMT) (full text, mbox, link).

+ +

Message #3756 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sat, 18 Jan 2014 22:35:37 +0200
+
+
On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote:
+> Adrian Bunk <bunk@stusta.de> writes:
+>...
+> > We are in full agreement on that.
+> 
+> > And my point on top of that is that if the CTTE decsion would be that
+> > Debian should support multiple init systems, but it does not set a
+> > policy limiting strictly what hard dependencies on systemd are allowed,
+> > then it would be better if the CTTE would rule that Debian should
+> > support only systemd since that's what would anyway happen in practice
+> > through package dependencies pretty soon.
+> 
+> And yet there are still people who use Debian without udev (or at least I
+> think there is based on debian-devel discussion).  Why go out of our way
+> to tell those people to go away?
+
+Considering that even the X server package depends on udev, there are 
+only some niches where it is still possible at all to use Debian on 
+Linux without udev - and it is slowly evolving into becoming impossible.
+
+> There is a natural process here, where rarely-used configurations slowly
+> stop working and people eventually decide not to bother to keep them
+> working and move on to other things.  Eventually, they may acquire RC bugs
+> that no one wants to fix and be dropped, or the package maintenance team
+> may decide that they just can't support the configuration any more, make a
+> public call for people to step forward and maintain it, and, when that
+> call isn't answered, drop support.
+>...
+
+The problem is different - with systemd there is a fast process going
+on where frequently-used configurations stop working without systemd.
+
+And the problem is exactly that without a strong policy there will not 
+be RC bugs anywhere - when it is fine for everyone to depend on systemd, 
+then any bugs demanding support for other init systems can just be 
+tagged "wontfix" by the Debian maintainer of the package.
+
+> In other words, I would rather be clear about what we consider to be the
+> primary technical direction, and the core functionality that we should try
+> to support, and let the long tail and personal projects take care of
+> themselves.  Some of them will fade away, some of them will putter along
+> in the background without hurting anyone, and we may be quite surprised by
+> one of them becoming a huge asset to the project later on.  That's why I
+> like the framing of this discussion as deciding the *default*.
+
+Are in your opinion Debian's non-Linux ports part of the core 
+functionality that we should try to support?
+
+And if yes, with the whole set of Debian's functionality or only with 
+some specific subset (e.g. only for headless servers)?
+
+AFAIR even the "make logind usable without systemd" discussions don't 
+mention that this won't make logind available for Debian's non-Linux 
+ports.
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 04:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 04:51:05 GMT) (full text, mbox, link).

+ +

Message #3761 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sat, 18 Jan 2014 20:49:48 -0800
+
+
Adrian Bunk <bunk@stusta.de> writes:
+> On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote:
+
+>> There is a natural process here, where rarely-used configurations
+>> slowly stop working and people eventually decide not to bother to keep
+>> them working and move on to other things.  Eventually, they may acquire
+>> RC bugs that no one wants to fix and be dropped, or the package
+>> maintenance team may decide that they just can't support the
+>> configuration any more, make a public call for people to step forward
+>> and maintain it, and, when that call isn't answered, drop support.
+
+> The problem is different - with systemd there is a fast process going
+> on where frequently-used configurations stop working without systemd.
+
+Are you only thinking of logind with desktop environments here, or are you
+thinking of something else?
+
+I don't think this process is actually very fast (we've been arguing about
+this for at least a year), and I think you're overstating this case, but
+maybe I missed something.  If you're just referring to GNOME, one desktop
+environment currently switched over doesn't strike me as very fast, and
+whether that's the path forward for that desktop environment for jessie is
+to a large extent what we're debating here.
+
+I think it's also important here to distinguish between decisions that
+Debian maintainers make and decisions *upstream* makes that Debian
+maintainers choose not to *reverse*.  Those are two very, very different
+situations, and I think they're being treated interchangeably way too much
+in these discussions.  We ask Debian maintainers to integrate their
+packages with the distribution, but we don't, in general, ask them to
+maintain long-term major forks in order to do so.  When we run into a
+situation where that looks like it might be necessary, we generally start
+a conversation about it and try to make a decision about the best path
+forward based on the specifics of that individual case.
+
+> And the problem is exactly that without a strong policy there will not
+> be RC bugs anywhere - when it is fine for everyone to depend on systemd,
+> then any bugs demanding support for other init systems can just be
+> tagged "wontfix" by the Debian maintainer of the package.
+
+This sounds like you're assuming a level of bad faith that I really don't
+think is appropriate.  I don't want to give Debian maintainers orders in
+advance just because we're worried they might otherwise do the wrong
+thing.  I think it's more likely that they'll make *better* decisions for
+their own packages when people aren't telling them specifically what to
+do, just advising on general project direction.
+
+> Are in your opinion Debian's non-Linux ports part of the core
+> functionality that we should try to support?
+
+No, which is not the same thing as saying that they're not supported.
+(More than 80% of the packages I maintain are similarly not part of the
+core functionality we should try to support.)
+
+> AFAIR even the "make logind usable without systemd" discussions don't
+> mention that this won't make logind available for Debian's non-Linux
+> ports.
+
+That's been discussed at length in the bug to which you are responding.  I
+realize it's quite long and has quite a lot of messages, though, so it's
+easy to lose track of what's been talked about.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 07:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 07:51:04 GMT) (full text, mbox, link).

+ +

Message #3766 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sun, 19 Jan 2014 09:48:09 +0200
+
+
On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote:
+> Adrian Bunk <bunk@stusta.de> writes:
+> > On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote:
+> 
+> >> There is a natural process here, where rarely-used configurations
+> >> slowly stop working and people eventually decide not to bother to keep
+> >> them working and move on to other things.  Eventually, they may acquire
+> >> RC bugs that no one wants to fix and be dropped, or the package
+> >> maintenance team may decide that they just can't support the
+> >> configuration any more, make a public call for people to step forward
+> >> and maintain it, and, when that call isn't answered, drop support.
+> 
+> > The problem is different - with systemd there is a fast process going
+> > on where frequently-used configurations stop working without systemd.
+> 
+> Are you only thinking of logind with desktop environments here, or are you
+> thinking of something else?
+> 
+> I don't think this process is actually very fast (we've been arguing about
+> this for at least a year), and I think you're overstating this case, but
+> maybe I missed something.  If you're just referring to GNOME, one desktop
+> environment currently switched over doesn't strike me as very fast, and
+> whether that's the path forward for that desktop environment for jessie is
+> to a large extent what we're debating here.
+
+I am not only talking about GNOME, or only about logind.
+
+I already gave my hypothetical "udev gets a hard dependency on systemd 
+as init system" worst case.
+To make the worst case even worse, assume a new upstream version of 
+systemd with this change gets released 2 weeks before the jessie freeze,
+and gets uploaded into unstable immediately.[1]
+
+In this hypothetical even worse worst case, would you consider such an 
+immediate upload to unstable a valid action of the Debian systemd 
+maintainers, or would you word the CTTE decision in a way that would 
+make it clear that an action like this would not be appropriate?
+
+Note that this is a hypothetical (but not completely impossible) 
+example and I am not implying that the Debian systemd maintainers
+would actually do such an upload in such a situation
+
+My point is that the CTTE decision has to cover such cases, to avoid
+in this hypothetical even worse worst case huge flamewars and possibly 
+even a GR during the freeze delaying the release of jessie.
+
+IMHO the whole point of having a CTTE decision on the init system 
+question is to have the issue settled in a way that any major 
+disagreements can be resolved by referring to the text of the
+CTTE decision.
+
+> I think it's also important here to distinguish between decisions that
+> Debian maintainers make and decisions *upstream* makes that Debian
+> maintainers choose not to *reverse*.  Those are two very, very different
+> situations, and I think they're being treated interchangeably way too much
+> in these discussions.  We ask Debian maintainers to integrate their
+> packages with the distribution, but we don't, in general, ask them to
+> maintain long-term major forks in order to do so.
+>...
+
+The best way to avoid long-term major forks is when the Debian 
+maintainers make it clear to upstream that e.g. ConsoleKit codepaths
+shouldn't be dropped upstream since that would make it harder for
+Debian's non-Linux ports.
+
+And in the cases where it doesn't work, it is very likely that 
+supporting any non-systemd init system will imply that Debian will
+have to maintain or at least adopt long-term major forks.
+
+logind is one example for such a long-term major fork.
+
+> > And the problem is exactly that without a strong policy there will not
+> > be RC bugs anywhere - when it is fine for everyone to depend on systemd,
+> > then any bugs demanding support for other init systems can just be
+> > tagged "wontfix" by the Debian maintainer of the package.
+> 
+> This sounds like you're assuming a level of bad faith that I really don't
+> think is appropriate.  I don't want to give Debian maintainers orders in
+> advance just because we're worried they might otherwise do the wrong
+> thing.  I think it's more likely that they'll make *better* decisions for
+> their own packages when people aren't telling them specifically what to
+> do, just advising on general project direction.
+
+No, I am not assuming bad faith.
+
+But there will be cases where the goals like
+1. give users of systemd under Linux the best possible experience
+2. support non-Linux ports
+3. support other init systems
+conflict.
+
+What is better depends on which goal has a higher priority for you.
+
+There shoud be a general project direction that clearly defines which
+of these two goals has a higher priority for Debian, not half of the 
+packages going into one direction and the other half into the other 
+direction.
+
+To make an example:
+
+In my hypothetical "udev gets a hard dependency on systemd as init 
+system" worst case, the best decision for the Debian systemd maintainers 
+for their own packages might be to deliver the latest systemd to their 
+users immediately.
+
+For anyone using another init system, this will be a huge pain until 
+some solution is found and implemented that provides a udev alternative
+also usable without systemd.
+
+> > Are in your opinion Debian's non-Linux ports part of the core
+> > functionality that we should try to support?
+> 
+> No, which is not the same thing as saying that they're not supported.
+> (More than 80% of the packages I maintain are similarly not part of the
+> core functionality we should try to support.)
+>...
+
+The following are two quite different options:
+1. support multiple init systems since the non-Linux ports are core
+   functionality of Debian
+2. support multiple init systems, without considering the non-Linux 
+   ports to be core functionality of Debian that has to be protected
+
+One major reason for people supporting multiple init systems is to allow 
+Debian to keep the non-Linux ports.[2] So they want 1., but might be 
+very surprised if it turns out what they actually got with their vote
+was 2., and that the non-Linux ports might anyway die in jessie+1.[3]
+
+And this does matter also since supporting multiple init systems will 
+be a lot more work than a one-time switch from sysvinit to a successor.
+
+
+cu
+Adrian
+
+[1] Assuming the new systemd release is not otherwise buggy.
+[2] There are also reasons why people might find 2. desirable, but it
+    should be clear whether they vote for 1. or 2.
+[3] It is not 100% certain that this would happen with 2., but that
+    is clear risk that IMHO has a pretty high probability.
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 09:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thomas Goirand <zigo@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 09:15:05 GMT) (full text, mbox, link).

+ +

Message #3771 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thomas Goirand <zigo@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: The tech ctte isn't considering OpenRC at all
+
Date: Sun, 19 Jan 2014 17:11:38 +0800
+
+
On Fri, 17 Jan 2014 20:41:32 -0800, Don Armstrong wrote:
+> I should point out that I have not extensively examined openrc
+
+I have to say that I'm really disappointed by the tech ctte attitude
+toward OpenRC in general.
+
+I pointed out to bdale (privately) as well that this was unacceptable.
+I've seen *many* quotes like this one:
+
+Fri, 17 Jan 2014 16:46:43 +0100, Christoph Anton Mitterer wrote:
+> I haven't really looked in depth at OpenRC or other solutions, since
+> from the descriptions made by other people, I think it's not
+> comparable to systemd/upstart.
+
+Christoph, you don't *think*, you've just *heard of* from others (which
+may be systemd or upstart supporters). Please learn to think by yourself!!!
+
+Unfortunately, it seems it's going to be the way OpenRC will be
+evaluated: because some people *pretended* that OpenRC wouldn't fit the
+bill, it's just discarded without even having a look at how it works,
+its features, and its implementation.
+
+That OpenRC isn't the best, I can agree to *read* that, even if this
+isn't my opinion. That it has less feature, I agree, but I don't think
+the tech ctte choice should be driven by the number of features, but by
+a set of requirements, and then choose the best implementation for them.
+
+But that OpenRC just hasn't been considered just because of rumors is
+really unacceptable.
+
+It is my strong opinion that, because OpenRC is the only one which has
+been ported to all Debian arch, and that because it has all the features
+*that we need* (if you include the plugin patch for s-vision and monit,
+which I'm currently evaluating and should be ready in days/weeks), and
+because of the way it is implemented (eg: very light and easy to
+understand/maintain), it is the best choice.
+
+Don, please do your work and evaluate properly OpenRC. Otherwise, step
+down and do not participate to the vote. Same goes for all tech ctte
+members please!
+
+On Fri, 17 Jan 2014 16:19:45 +0100, Josselin Mouette <joss@debian.org>:
+> That, I can definitely agree with. Although it is a shame that OpenRC
+> chose a non-declarative format.
+
+Joss, please stop posting stupid remarks about OpenRC. You don't know
+it, and you don't seem to want to know it. That's the 2nd post in a week
+that shows it, this is enough. OpenRC does have a declarative format, it
+is just not mandatory and you can continue to use init scripts if you
+like. Here's an example (from my blog, implementing the startup for
+rsyslogd):
+http://thomas.goirand.fr/blog/?p=147
+
+Note that the sheebang should be replaced by /sbin/openrc-run since
+runscript was renamed (because of clash with the program from minicom).
+If you don't call this declarative, then you aren't being honest.
+
+On Fri, 17 Jan 2014 16:19:45 +0100, Josselin Mouette <joss@debian.org>:
+> Oh, really?
+> Then can you explain why
+> https://bugs.gentoo.org/show_bug.cgi?id=391945
+> has not been marked as fixed?
+
+It is the view of the upstream maintainers that the corner case where
+this happens doesn't happen in real life, so that bug can be ignored.
+This has already been stated many times, and I'm sure you've heard about
+it. I thought we were not having the debate this way. It seems you love
+flame wars and can't help yourself. CAN YOU STOP NOW ???
+
+Cheers,
+
+Thomas Goirand (zigo)
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 09:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Pacho Ramos <pacho@gentoo.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 09:33:05 GMT) (full text, mbox, link).

+ +

Message #3776 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Pacho Ramos <pacho@gentoo.org>
+
To: Thomas Goirand <zigo@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: The tech ctte isn't considering OpenRC at all
+
Date: Sun, 19 Jan 2014 10:23:30 +0100
+
+
El dom, 19-01-2014 a las 17:11 +0800, Thomas Goirand escribió:
+> On Fri, 17 Jan 2014 20:41:32 -0800, Don Armstrong wrote:
+> > I should point out that I have not extensively examined openrc
+> 
+> I have to say that I'm really disappointed by the tech ctte attitude
+> toward OpenRC in general.
+> 
+> I pointed out to bdale (privately) as well that this was unacceptable.
+> I've seen *many* quotes like this one:
+> 
+[...]
+
+Maybe one option would be to use by default Systemd for Linux flavors
+and openRC for the BSD ports :/
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 10:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 10:03:04 GMT) (full text, mbox, link).

+ +

Message #3781 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sun, 19 Jan 2014 11:00:01 +0100
+
+
]] Adrian Bunk 
+
+> I already gave my hypothetical "udev gets a hard dependency on systemd 
+> as init system" worst case.
+> To make the worst case even worse, assume a new upstream version of 
+> systemd with this change gets released 2 weeks before the jessie freeze,
+> and gets uploaded into unstable immediately.[1]
+
+Then the systemd maintainer (i.e. me and the rest of the team) should be
+bopped on the head.
+
+I'd appreciate if your hypothetical scenarios aren't «let's assume that
+everyone are bonkers and do crazy stuff», since well, if they are, we
+need to fix that.  The problem then isn't that they're uploading
+packages which are not appropriate for the archive, it's that they don't
+understand why that is a problem.
+
+You can't regulate «don't be crazy», since if people want to, or don't
+understand what crazy means they will route around such a decision using
+technicalities.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 11:03:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 11:03:08 GMT) (full text, mbox, link).

+ +

Message #3786 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sun, 19 Jan 2014 02:59:01 -0800
+
+
Adrian Bunk <bunk@stusta.de> writes:
+> On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote:
+>> Adrian Bunk <bunk@stusta.de> writes:
+
+>>> The problem is different - with systemd there is a fast process going
+>>> on where frequently-used configurations stop working without systemd.
+
+>> Are you only thinking of logind with desktop environments here, or are
+>> you thinking of something else?
+
+>> I don't think this process is actually very fast (we've been arguing
+>> about this for at least a year), and I think you're overstating this
+>> case, but maybe I missed something.  If you're just referring to GNOME,
+>> one desktop environment currently switched over doesn't strike me as
+>> very fast, and whether that's the path forward for that desktop
+>> environment for jessie is to a large extent what we're debating here.
+
+> I am not only talking about GNOME, or only about logind.
+
+> I already gave my hypothetical "udev gets a hard dependency on systemd
+> as init system" worst case.  To make the worst case even worse, assume a
+> new upstream version of systemd with this change gets released 2 weeks
+> before the jessie freeze, and gets uploaded into unstable
+> immediately.[1]
+
+[...]
+
+I'm really not interested in discussing hypotheticals.  You said that
+there was a fast process towards frequently-used configurations that don't
+work without systemd.  I'm interested in concrete examples of this.  If
+all you have are hypotheticals, I question the accuracy of that statement
+and the usefulness of discussing them right now.
+
+> My point is that the CTTE decision has to cover such cases, to avoid in
+> this hypothetical even worse worst case huge flamewars and possibly even
+> a GR during the freeze delaying the release of jessie.
+
+I don't agree.  I don't think the TC decision needs to cover various
+hypotheticals, only likely scenarios that we can reasonably forsee and
+that we have some concrete reason to believe that the relevant maintainers
+won't be able to resolve them themselves.
+
+> The best way to avoid long-term major forks is when the Debian
+> maintainers make it clear to upstream that e.g. ConsoleKit codepaths
+> shouldn't be dropped upstream since that would make it harder for
+> Debian's non-Linux ports.
+
+Sure.  But upstream is also allowed to not care about Debian's non-Linux
+ports, just as no one requires Debian maintainers to do any work that they
+don't want to do.  We're all volunteers here.
+
+> And in the cases where it doesn't work, it is very likely that
+> supporting any non-systemd init system will imply that Debian will have
+> to maintain or at least adopt long-term major forks.
+
+For that package, indeed.
+
+The point here is that there are three possible outcomes to upstream
+making their software less portable (assuming we can't convince them to
+reverse that decision): we drop the software entirely, we fork it to add
+portability, or we make it available only on the architectures and
+configurations that upstream supports.
+
+All three of those are options, and Debian will continue to use all three
+approaches depending on the situation.  Sometimes, we'll even use
+combinations of several approaches there.  It doesn't do any good to try
+to make some general rule about what approach we're going to take in
+advance, since which of those three options is the most appropriate
+depends entirely on the specific circumstances.
+
+> No, I am not assuming bad faith.
+
+> But there will be cases where the goals like
+> 1. give users of systemd under Linux the best possible experience
+> 2. support non-Linux ports
+> 3. support other init systems
+> conflict.
+
+> What is better depends on which goal has a higher priority for you.
+
+> There shoud be a general project direction that clearly defines which of
+> these two goals has a higher priority for Debian, not half of the
+> packages going into one direction and the other half into the other
+> direction.
+
+I don't even agree with this.  I think it's perfectly reasonable for some
+Debian contributors to choose to put more of their time into giving users
+of the default init system on Linux the best possible experience, and
+other Debian contributors to concentrate on supporting non-Linux ports or
+other init systems, depending on what that individual maintainer feels is
+the most important and what they want to spend time on.
+
+The point of this bug is to choose a default init system.  With most of
+those choices come obvious benefits if we add native support for that init
+system to our packaging.  That doesn't mean anyone is obligated to do so.
+It does mean that they shouldn't stand in the way of other people doing
+so.
+
+Some packages are going to be converted to native support for the default
+init system quickly, some slowly, and different contributors will use
+different approaches.  That's fine.
+
+> The following are two quite different options:
+> 1. support multiple init systems since the non-Linux ports are core
+>    functionality of Debian
+> 2. support multiple init systems, without considering the non-Linux 
+>    ports to be core functionality of Debian that has to be protected
+
+> One major reason for people supporting multiple init systems is to allow 
+> Debian to keep the non-Linux ports.[2] So they want 1., but might be 
+> very surprised if it turns out what they actually got with their vote
+> was 2., and that the non-Linux ports might anyway die in jessie+1.[3]
+
+> And this does matter also since supporting multiple init systems will 
+> be a lot more work than a one-time switch from sysvinit to a successor.
+
+I understand what you're saying, I think, and I believe it's the point of
+wording that Ian and I have been discussing: what are we requiring
+maintainers to do when patches are submitted for a non-default init
+system?  I think I already said what my position on that is.  People
+should not get in the way of other people's work if possible.  And
+obviously for jessie people shouldn't drop sysvinit scripts.  I don't know
+if we're going to be able to decide right now if people will be able to
+drop sysvinit scripts post-jessie.  I think it may be better to wait and
+see what the landscape looks like then.
+
+I think this is a different question than dependencies on logind, because
+in that case we're dealing with upstream decisions to move strongly in a
+particular direction.  That's much different than most of the issues we'll
+run into with multiple init systems, where the configuration for different
+init systems is largely independent.
+
+Hopefully, logind will continue to work without systemd and people will
+volunteer to maintain the necessary packaging for that configuration, and
+none of this will be a problem.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 11:45:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 11:45:05 GMT) (full text, mbox, link).

+ +

Message #3791 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sun, 19 Jan 2014 13:42:40 +0200
+
+
On Sun, Jan 19, 2014 at 11:00:01AM +0100, Tollef Fog Heen wrote:
+> ]] Adrian Bunk 
+> 
+> > I already gave my hypothetical "udev gets a hard dependency on systemd 
+> > as init system" worst case.
+> > To make the worst case even worse, assume a new upstream version of 
+> > systemd with this change gets released 2 weeks before the jessie freeze,
+> > and gets uploaded into unstable immediately.[1]
+> 
+> Then the systemd maintainer (i.e. me and the rest of the team) should be
+> bopped on the head.
+> 
+> I'd appreciate if your hypothetical scenarios aren't «let's assume that
+> everyone are bonkers and do crazy stuff», since well, if they are, we
+> need to fix that.  The problem then isn't that they're uploading
+> packages which are not appropriate for the archive, it's that they don't
+> understand why that is a problem.
+
+What is bonkers and what is not is very subjective, and that's the 
+problem here.
+
+If I was a systemd maintainer I would consider it a reasonable option to 
+rather upload a new version of systemd that adds such a dependency to 
+udev instead of shipping an ancient systemd in the next release.
+
+Or would you want to ship systemd 204 in jessie if that would 
+hypothetically be the only option for providing logind for
+non-systemd in the jessie timeframe?
+
+> You can't regulate «don't be crazy», since if people want to, or don't
+> understand what crazy means they will route around such a decision using
+> technicalities.
+
+That's why in the case of Debian supporting multiple init systems (and 
+optionally additionally non-Linux ports) there has to be a strict policy 
+enforcing that this also stays supported.
+
+If you go bonkers tomorrow and add a dependency on systemd-sysv to udev,
+will that be considered an RC bug that will prevent your package from 
+ever reaching testing until a udev without that dependency will be in
+the archive? [1]
+
+If multiple init systems should be supported accordinng to the CTTE 
+decision, then the CTTE decision has to make it clear that "Yes" is
+the answer to that question.
+
+cu
+Adrian
+
+[1] Whether the dependency gets removed from udev or whether
+    a second (forked) version of udev is needed depends on
+    the technicalities.
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 11:54:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 11:54:08 GMT) (full text, mbox, link).

+ +

Message #3796 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Thomas Goirand <zigo@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: The tech ctte isn't considering OpenRC at all
+
Date: Sun, 19 Jan 2014 03:52:08 -0800
+
+
Thomas Goirand <zigo@debian.org> writes:
+> On Fri, 17 Jan 2014 20:41:32 -0800, Don Armstrong wrote:
+
+>> I should point out that I have not extensively examined openrc
+
+> I have to say that I'm really disappointed by the tech ctte attitude
+> toward OpenRC in general.
+
+The reason why I'm not investing the time at present to set up a system
+running OpenRC and writing init scripts for it is that I don't see what I
+would learn from that to lead me to displace upstart as my second choice.
+
+I realize that you're putting a lot of work into OpenRC packaging and you
+believe in the technology, and I think it may well be a great choice for
+non-Linux ports and, if we can manage the project-wide support, as an init
+system for people who want something much simpler and more familiar.  But
+it was way behind both systemd and upstart in terms of readiness in Debian
+going into this discussion, and the amount of catching up that's required
+here for it to displace upstart as my second choice just doesn't seem
+feasible for me.
+
+OpenRC has all of the same community momentum and logind integration
+concerns as upstart does, has far less documentation than upstart (compare
+openrc-run(8) to the Upstart Cookbook), is not as mature in Debian right
+now, and doesn't have the advantage of Ubuntu's significant testing and
+development of configurations in packages very similar to those in Debian.
+It's even more dependent on shell scripting for common problems than
+upstart is, which I consider a serious problem when trying to make simple
+things easy and complex things comprehensible.  And it otherwise suffers
+from many of the same drawbacks that upstart has relative to systemd.
+
+The two advantages it has are that it's significantly more portable than
+upstart, which I already decided wasn't a strong enough factor to be
+conclusive in my preference for the default Linux init system as I spelled
+out in my previous message, and it has a dependency-based system rather
+than an event-based system.  I do think upstart's model is dubious, and
+OpenRC's is closer to systemd, which I like better.  I think that may make
+it a better choice for the non-Linux ports in the long run.  But I don't
+think that's a strong enough advantage to overcome the other issues.
+
+In short, OpenRC is a very nice extension of traditional shell-based init
+scripts, but unless I'm missing some giant treasure trove of undocumented
+features, I don't see anything that I'm going to learn by working with it
+more that's going to change my mind about whether it should be the Linux
+default.
+
+You're understandably frustrated at people's misunderstandings, including
+mine.  I thought it was less ambitious than it is, and it has features
+that I thought were missing (although, to again point out that it's
+playing catch-up here, several of those are ones you're actively working
+on over the course of this discussion).  But note that the reason why
+there are so many misunderstandings has much more to do with the fact that
+there's *almost no documentation* than that we're being somehow unfair.
+My first approach to both systemd and upstart, and I know Ian's as well,
+was to read all the documentation that was available, and only then did I
+start experimenting with the things that I didn't entirely understand from
+the documentation.  I don't think that's an unreasonable approach, and I
+think the lack of documentation is a significant concern by itself, apart
+from the difficulties that causes for evaluation.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 12:18:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 12:18:05 GMT) (full text, mbox, link).

+ +

Message #3801 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Thomas Goirand <zigo@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: The tech ctte isn't considering OpenRC at all
+
Date: Sun, 19 Jan 2014 12:15:25 +0000
+
+
Thomas Goirand writes ("Bug#727708: The tech ctte isn't considering OpenRC at all"):
+> I have to say that I'm really disappointed by the tech ctte attitude
+> toward OpenRC in general.
+
+I'm sorry about that, but:
+
+The way I investigated both systems was by reading their documentation
+and playing about with them (on the VMs Steve helpfully provided).
+
+At the start of my investigations I asked where I could find the
+reference documentation and no-one answered.  And, OpenRC wasn't in
+sid.  So these things weren't possible.
+
+> But that OpenRC just hasn't been considered just because of rumors is
+> really unacceptable.
+
+The reason I haven't seriously considered OpenRC for the default is
+that it wasn't ready.
+
+Perhaps things have improved.  But I don't think it is necessarily the
+TC's job to go back and revisit OpenRC in these circumstances.  How
+mature a system is and how well-developed in Debian are relevant
+factors and it's not unreasonable to set a deadline, at which the
+state of the system in Debian will be the basis of our technical
+evaluation.
+
+
+On to specifics:
+
+Thomas, does OpenRC provide a means for do non-forking daemon
+startup ?
+
+By that I mean some arrangement whereby:
+
+ * The daemon does not double-fork; it runs in the foreground of
+   of its initial process.
+
+ * The daemon's parent process (part of the init system) keeps
+   track of it, so the init system knows whether the process
+   is still running.
+
+ * The daemon's stderr goes somewhere reasonable.
+
+If the answer to this question is "yes" then I will go and at least
+read the documentation.  If it's "no" then I have to say that I think
+(for me) OpenRC is failing to deal with the key underlying technical
+problem we have with daemons in sysvinit right now.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 12:24:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 12:24:09 GMT) (full text, mbox, link).

+ +

Message #3806 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sun, 19 Jan 2014 14:20:57 +0200
+
+
On Sun, Jan 19, 2014 at 02:59:01AM -0800, Russ Allbery wrote:
+> Adrian Bunk <bunk@stusta.de> writes:
+> > On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote:
+>...
+> > No, I am not assuming bad faith.
+> 
+> > But there will be cases where the goals like
+> > 1. give users of systemd under Linux the best possible experience
+> > 2. support non-Linux ports
+> > 3. support other init systems
+> > conflict.
+> 
+> > What is better depends on which goal has a higher priority for you.
+> 
+> > There shoud be a general project direction that clearly defines which of
+> > these two goals has a higher priority for Debian, not half of the
+> > packages going into one direction and the other half into the other
+> > direction.
+> 
+> I don't even agree with this.  I think it's perfectly reasonable for some
+> Debian contributors to choose to put more of their time into giving users
+> of the default init system on Linux the best possible experience, and
+> other Debian contributors to concentrate on supporting non-Linux ports or
+> other init systems, depending on what that individual maintainer feels is
+> the most important and what they want to spend time on.
+>  
+> The point of this bug is to choose a default init system.  With most of
+> those choices come obvious benefits if we add native support for that init
+> system to our packaging.  That doesn't mean anyone is obligated to do so.
+> It does mean that they shouldn't stand in the way of other people doing
+> so.
+> 
+> Some packages are going to be converted to native support for the default
+> init system quickly, some slowly, and different contributors will use
+> different approaches.  That's fine.
+
+Why do you want Debian to support multiple init systems in the first place?
+
+See also below.
+
+
+> > The following are two quite different options:
+> > 1. support multiple init systems since the non-Linux ports are core
+> >    functionality of Debian
+> > 2. support multiple init systems, without considering the non-Linux 
+> >    ports to be core functionality of Debian that has to be protected
+> 
+> > One major reason for people supporting multiple init systems is to allow 
+> > Debian to keep the non-Linux ports.[2] So they want 1., but might be 
+> > very surprised if it turns out what they actually got with their vote
+> > was 2., and that the non-Linux ports might anyway die in jessie+1.[3]
+> 
+> > And this does matter also since supporting multiple init systems will 
+> > be a lot more work than a one-time switch from sysvinit to a successor.
+> 
+> I understand what you're saying, I think, and I believe it's the point of
+> wording that Ian and I have been discussing: what are we requiring
+> maintainers to do when patches are submitted for a non-default init
+> system?  I think I already said what my position on that is.  People
+> should not get in the way of other people's work if possible.  And
+> obviously for jessie people shouldn't drop sysvinit scripts.  I don't know
+> if we're going to be able to decide right now if people will be able to
+> drop sysvinit scripts post-jessie.  I think it may be better to wait and
+> see what the landscape looks like then.
+> 
+> I think this is a different question than dependencies on logind, because
+> in that case we're dealing with upstream decisions to move strongly in a
+> particular direction.  That's much different than most of the issues we'll
+> run into with multiple init systems, where the configuration for different
+> init systems is largely independent.
+> 
+> Hopefully, logind will continue to work without systemd and people will
+> volunteer to maintain the necessary packaging for that configuration, and
+> none of this will be a problem.
+
+I think you missed my point.
+
+Assume a CTTE member wants that Debian does continue to have non-Linux 
+ports, and therefore wants Debian to make the extra efforts for 
+supporting a second init system besides systemd.
+
+What level of support (if any) would that guarantee for Debian's ports 
+to non-Linux kernels?
+
+
+Or more generally speaking:
+
+Supporting multiple init systems in the packages as well as all use 
+cases like switching the init system of a running system will be a big 
+effort from both init system maintainers and maintainers maintaining 
+packages with init scripts.
+
+What are the goal(s) you want to achieve with forcing the big additional 
+effort for supporting multiple init systems on Debian maintainers?
+
+And is that additional effort well-spent?
+Will these goal(s) be reached?
+
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 13:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Dmitry Yu Okunev <dyokunev@ut.mephi.ru>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 13:36:04 GMT) (full text, mbox, link).

+ +

Message #3811 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Dmitry Yu Okunev <dyokunev@ut.mephi.ru>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: The tech ctte isn't considering OpenRC at all
+
Date: Sun, 19 Jan 2014 17:33:01 +0400
+
+
[Message part 1 (text/plain, inline)]
+
Hello.
+
+On 01/19/2014 01:11 PM, Thomas Goirand wrote:
+> On Fri, 17 Jan 2014 16:19:45 +0100, Josselin Mouette <joss@debian.org>:
+>> Oh, really?
+>> Then can you explain why
+>> https://bugs.gentoo.org/show_bug.cgi?id=391945
+>> has not been marked as fixed?
+> 
+> It is the view of the upstream maintainers that the corner case where
+> this happens doesn't happen in real life, so that bug can be ignored.
+
+I want to add, that I've fixed the problem [1] on my local OpenRC copy.
+Waiting for answer from Gentoo side about my patch.
+
+[1] https://bugs.gentoo.org/show_bug.cgi?id=391945
+
+
+I'm only a debian user but let me put two cents in again. Here's a look
+from aside:
+
+"systemd" and "upstart" gives _extra_ features, but sacrificing:
+ - free community of init-system;
+ - UNIX philosophy accordance.
+
+There's a great lot of trash distributions like "ubuntu" or "fedora",
+that are pursuing their own goals and forcing variety software. Debian
+is the only universal binary distribution with big enough community that
+can be used with conservative UNIX users, who believes in free community
+and UNIX philosophy. IMO, software bundles (like "systemd") is a
+proprietary way.
+
+On the other hand OpenRC is really good solution supported by really
+free and professional community. If you don't like something in it,
+please, show corresponding bugreports, and OpenRC will likely fix that
+all (if that will be reasonable). I personally saw only one minor
+bugreport… and a lot of bugreports about "systemd".
+
+OpenRC has extended cgroups support in 0.12 and it has parallel boot
+support and all other and other reasonable features. And it's already in
+experimental repositories of Debian (but I don't see any problem to test
+OpenRC even if it's not in repositories).
+
+The fact that the committee didn't even consider OpenRC despite the
+community opinion is sad. I'm talking on forums with Debian users like
+me, and a lot of them really want OpenRC. We even cannot understand why
+OpenRC was been declined. Where's explanation of it's declination?
+
+Don't you see, that the OpenRC is really the 3rd variant? And the only
+one that is community driven. Or this's not an argument for Debian [1,
+2] anymore?
+
+[1] http://www.debian.org/intro/about
+[2] http://www.debian.org/intro/free
+
+
+P.S.: Sorry for my English.
+
+-- 
+Best regards, Dmitry,
+head of UNIX-tech department NRNU MEPhI,
+tel. 8 (495) 788-56-99, add. 8255
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 13:51:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 13:51:10 GMT) (full text, mbox, link).

+ +

Message #3816 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: Thomas Goirand <zigo@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: The tech ctte isn't considering OpenRC at all
+
Date: Sun, 19 Jan 2014 14:47:55 +0100
+
+
* Thomas Goirand (zigo@debian.org) [140119 10:15]:
+> Unfortunately, it seems it's going to be the way OpenRC will be
+> evaluated: because some people *pretended* that OpenRC wouldn't fit the
+> bill, it's just discarded without even having a look at how it works,
+> its features, and its implementation.
+
+That is - at least for me - not true: I look the same way at openrc as
+the others. This however doesn't prevent me from arriving at certain
+conclusions why I think one of the init systems is better than
+another.
+
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 13:57:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 13:57:05 GMT) (full text, mbox, link).

+ +

Message #3821 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: TC resolution Re: GR: Selecting the default init system for Debian
+
Date: Sun, 19 Jan 2014 13:53:03 +0000
+
+
Ian Jackson writes ("Re: GR: Selecting the default init system for Debian"):
+> Russ Allbery writes ("Re: GR: Selecting the default init system for Debian"):
+> > As a TC member, I dislike the supermajority requirement for the project to
+> > overturn a TC decision by GR, particularly in this case.  I think we would
+> > all be extremely unhappy if the TC voted one way on the default init
+> > system and the project then voted a different way by a 60% majority.
+> 
+> I agree.  I think that would be quite bad.  We could explicitly state
+> in our TC resolution that the TC decision can be vacated by General
+> Resolution on a simple majority.
+
+It seems to me that in the situation Russ describes it would be best
+for the GR's conclusion, rather than the TC's, to be de jure that of
+the project.
+
+I therefore intend to put into the drafts something along the lines I
+suggest there, unless anyone objects.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 14:03:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 14:03:05 GMT) (full text, mbox, link).

+ +

Message #3826 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: Adrian Bunk <bunk@stusta.de>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sun, 19 Jan 2014 14:00:31 +0000
+
+
On 19/01/14 12:20, Adrian Bunk wrote:
+> Why do you want Debian to support multiple init systems in the first place?
+
+I think because:
+
+* whichever is chosen as default, there will be some users who
+specifically don't like it, or specifically want something else
+(including major consumers like Ubuntu (Upstart), or Spotify (systemd),
+or Google (SysV))
+
+* the non-Linux ports may have no choice but to get some other init
+system working anyway (if systemd is chosen as the default on Linux - I
+am quite certain it would never be ported)
+
+* if people are going to be doing the above work anyway, let's make it
+available to everyone, Linux and non-Linux users alike
+
+* if the chosen init system turns out to be a disaster, we'd have an
+easy way out if we weren't fully reliant on it;  or maybe another init
+system comes along for jessie+1, better than anything we have now, we'd
+have more agility in being able to adopt it right away (not like this
+current situation)
+
+
+> What level of support (if any) would that guarantee for Debian's ports 
+> to non-Linux kernels?
+
+I don't think anyone can guarantee that in a volunteer project;  nobody
+can be forced to do the work if they don't want to.  Porters may have to
+work hard and restore any lost functionality they care enough about.  I
+imagine such problems will be RC-severity bugs, so it should be possible
+within existing practices to get patches applied or NMUd.
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 14:33:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thomas Goirand <zigo@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 14:33:10 GMT) (full text, mbox, link).

+ +

Message #3831 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thomas Goirand <zigo@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: logind working without systemd
+
Date: Sun, 19 Jan 2014 22:28:59 +0800
+
+
Sun, 19 Jan 2014 13:42:40 +0200, Russ Allbery
+> Hopefully, logind will continue to work without systemd and people
+> will volunteer to maintain the necessary packaging for that
+> configuration, and none of this will be a problem.
+
+I really wish you were right Russ. Because that's not what upstream is
+doing (since systemd 205, it's not the case), and Debian package
+maintainers have stated this as an argument in the favor of systemd.
+
+I would very much like the tech ctte to express itself on this topic on
+the final statement (whatever default init system is chosen).
+
+Thomas
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 15:09:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 15:09:12 GMT) (full text, mbox, link).

+ +

Message #3836 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sun, 19 Jan 2014 16:05:08 +0100
+
+
]] Adrian Bunk 
+
+> On Sun, Jan 19, 2014 at 11:00:01AM +0100, Tollef Fog Heen wrote:
+> > ]] Adrian Bunk 
+> > 
+> > > I already gave my hypothetical "udev gets a hard dependency on systemd 
+> > > as init system" worst case.
+> > > To make the worst case even worse, assume a new upstream version of 
+> > > systemd with this change gets released 2 weeks before the jessie freeze,
+> > > and gets uploaded into unstable immediately.[1]
+> > 
+> > Then the systemd maintainer (i.e. me and the rest of the team) should be
+> > bopped on the head.
+> > 
+> > I'd appreciate if your hypothetical scenarios aren't «let's assume that
+> > everyone are bonkers and do crazy stuff», since well, if they are, we
+> > need to fix that.  The problem then isn't that they're uploading
+> > packages which are not appropriate for the archive, it's that they don't
+> > understand why that is a problem.
+> 
+> What is bonkers and what is not is very subjective, and that's the 
+> problem here.
+
+No, it's not subjective.
+
+> If I was a systemd maintainer I would consider it a reasonable option to 
+> rather upload a new version of systemd that adds such a dependency to 
+> udev instead of shipping an ancient systemd in the next release.
+> 
+> Or would you want to ship systemd 204 in jessie if that would 
+> hypothetically be the only option for providing logind for
+> non-systemd in the jessie timeframe?
+
+That's not the point.  The point is that it's not reasonable to break
+other people's packages in a significant and work-intensive manner two
+weeks before release, which is your scenario.  There is no way that's
+ok.  On the other hand, trying to formalise exactly how much you can
+inconvenience somebody how far in advance of the release is a futile
+exercise.  Is requiring one other package to make a tiny change two
+years in advance of the freeze ok?  If so, how about one year?  One
+month?  20 days? etc.  Don't regulate it explicitly but tell people that
+they have to behave reasonably towards their fellow developers.
+
+If people have no idea what that means, we already have a problem and
+need to fix that.  If they disagree over the minutae, that's fine and we
+might need to decide exactly where the line goes in a few cases, but we
+can do that when the problem shows up, rather than try to antipacitate
+every case where it might go wrong.
+
+> > You can't regulate «don't be crazy», since if people want to, or don't
+> > understand what crazy means they will route around such a decision using
+> > technicalities.
+> 
+> That's why in the case of Debian supporting multiple init systems (and 
+> optionally additionally non-Linux ports) there has to be a strict policy 
+> enforcing that this also stays supported.
+> 
+> If you go bonkers tomorrow and add a dependency on systemd-sysv to udev,
+> will that be considered an RC bug that will prevent your package from 
+> ever reaching testing until a udev without that dependency will be in
+> the archive? [1]
+
+I sure hope so.  If nothing else because the package is uninstallable
+without manual override.  It'd break unrelated packages.  It'd probably
+break d-i.
+
+> If multiple init systems should be supported accordinng to the CTTE 
+> decision, then the CTTE decision has to make it clear that "Yes" is
+> the answer to that question.
+
+Regulating the way you are advocating means you're moving the Overton
+window on what's considered acceptable or borderline acceptable and so I
+really don't think that's a good idea.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 15:21:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 15:21:10 GMT) (full text, mbox, link).

+ +

Message #3841 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Mon, 20 Jan 2014 01:17:13 +1000
+
+
On 17 January 2014 03:52, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
+> What is Debian ?  In one respect, Debian is an operating system.  And
+> of course in another respect Debian is a community.
+> * Debian is a forum for cooperation and technical development.
+> * Debian, as a piece of software, tries to be all things to all
+>   people (within reason).
+
+So the original message referring this to the tech ctte was about
+deciding on "the default init system". Honestly, that seems like the
+least interesting part of this discussion to me; and I wonder if the
+ctte shouldn't consider answering some different, but related question
+that more directly addresses issues like packages depending on cgroups
+or logind. Something like:
+
+ a) 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.
+
+ b) maintainers should be aware systemd relies heavily on cgroups, and
+thus should be aware that requiring use of a systemd unit file for
+startup will likewise require their package to be configured to not
+build for non-Linux architectures.
+
+ c) logind or an equivalent service implementing the freedesktop.org
+systemd/logind api should be available under all supported init
+systems and architectures in Debian. It should be provided via a
+virtual package "fdo-logind" and packages (such as desktop managers)
+expecting logind to be available should Depend on fdo-logind
+
+ d) [are packages likely to start depending on
+localed/hostnamed/timedated/machined/??? in the same way as logind
+such that it would need to be available outside systemd for upstart to
+be a useful init?]
+
+ e) no init system in Debian should be marked as Essential:yes, or
+depended upon by any Essential:yes or Priority:required package except
+through the virtual package "init-system". All init packages should
+Provide: and Conflict: init-system. base-files should Depend:
+init-system.
+
+ f) all init systems Providing the init-system virtual package must
+support packages providing sysv style init scripts via update-rc.d.
+
+ g) packages that do not work with sysv must declare a Depends: on the
+init systems they do support, eg upstart | systemd
+
+ h) having examined the various current available init systems, the
+tech ctte considers [OpenRC] to be the best available init
+implementation at present, and so determines that the relevant
+maintainers, including the installer team and ftpmasters se it as the
+default init-system for new Debian installs. This decision becomes
+vacant should a general resolution specifying an alternative init
+system as the default pass with a simple majority prior to jessie's
+release.
+
+ i) all these decisions revert to advisory opinions after the release
+of jessie, and may then be changed by the usual methods of consensus
+driven policy development, and maintainer decisions, or by referring
+the issue to the tech ctte again.
+
+I think (a) and (b) are pretty non-controversial. (c) and (d) are
+required if we want to deal with new GNOME stuff and anything other
+than systemd probably, and don't seem very hard to either do or
+document. (e), (f) and (g) seem like a fairly straightforward of
+allowing for multiple init systems in Debian. I think something like
+(i) might be a good way of sunsetting tech ctte decisions so if
+there's an actual consensus in future, there's no need to get a
+pro-forma vote from the ctte to make changes in future. YMMV of
+course.
+
+In my ideal world, the tech ctte would work out good answers to all
+the bits above except (h) and get those added to policy, then propose
+various options for (h) as a GR themselves, with well argued
+rationales for each of the options along the lines of what's already
+been posted to the list. How much that conflicts with the "No detailed
+design work" portion of the ctte's mission statement is up for debate
+though. Why you'd have a *technical* committee and forbid them making
+sure the "details" are right doesn't make a lot of sense to me though.
+Fortunately I'm not on the tech ctte list, so I can look into details
+all I like ;)
+
+Cheers,
+aj
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 16:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 16:00:05 GMT) (full text, mbox, link).

+ +

Message #3846 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sun, 19 Jan 2014 17:56:47 +0200
+
+
On Sun, Jan 19, 2014 at 04:05:08PM +0100, Tollef Fog Heen wrote:
+> ]] Adrian Bunk 
+>...
+> > If I was a systemd maintainer I would consider it a reasonable option to 
+> > rather upload a new version of systemd that adds such a dependency to 
+> > udev instead of shipping an ancient systemd in the next release.
+> > 
+> > Or would you want to ship systemd 204 in jessie if that would 
+> > hypothetically be the only option for providing logind for
+> > non-systemd in the jessie timeframe?
+> 
+> That's not the point.  The point is that it's not reasonable to break
+> other people's packages in a significant and work-intensive manner two
+> weeks before release, which is your scenario.  There is no way that's
+> ok.  On the other hand, trying to formalise exactly how much you can
+> inconvenience somebody how far in advance of the release is a futile
+> exercise.  Is requiring one other package to make a tiny change two
+> years in advance of the freeze ok?  If so, how about one year?  One
+> month?  20 days? etc.  Don't regulate it explicitly but tell people that
+> they have to behave reasonably towards their fellow developers.
+>...
+
+The problem is not a question of weeks or years.
+
+It is about setting the goals that should be achieved before discussing 
+the way to reach them.
+
+Possible goals that require Debian to support multiple init systems 
+include:
+- allow everyone who dislikes systemd to have the full functionality
+  of Debian available with a different init system or
+- provide all/some major desktop environments with non-Linux ports or
+- allow non-Linux ports to be fully functional as server (but not
+  necessarily as desktop) or
+- ...
+
+Let me make an example where that affects you: [0]
+
+When I asked regarding switching the init system of a running system,
+Ian Jackson answered:
+  It seems obvious to me that if multiple ones are supported that there
+  has to be some way to get from using one to using a different one.
+
+So if anything is not working regarding switching a running system from 
+systemd to sysvinit for jessie,[1] then that will be a (likely RC) bug 
+in your package [2] that you as systemd maintainers will have to fix.
+
+Making you spend your efforts on supporting switching the init system 
+to and from systemd only makes sense when that results in actually 
+reaching a goal that is considered worth the effort.
+
+Supporting multiple init systems alone is not sufficient for achieving 
+any of the possible goals I've listed above, and the effort is only 
+worth it when there is a clear understanding of the goal(s) and the
+complete requirements for achieving these goal(s).
+
+cu
+Adrian
+
+[0] assuming the decision is "multiple init systems, including systemd"
+[1] it would clearly involve a reboot, but calling the right reboot(8)
+    can already be tricky
+[2] assuming the problem is not on the sysvinit side
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 17:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 17:18:04 GMT) (full text, mbox, link).

+ +

Message #3851 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: The tech ctte isn't considering OpenRC at all
+
Date: Sun, 19 Jan 2014 12:14:04 -0500
+
+
On Sun, Jan 19, 2014 at 6:52 AM, Russ Allbery wrote:
+> But
+> it was way behind both systemd and upstart in terms of readiness in Debian
+> going into this discussion, and the amount of catching up that's required
+> here for it to displace upstart as my second choice just doesn't seem
+> feasible for me.
+
+Shouldn't this be seen as reason to slow things down?  Using a
+bureaucratic quality like "readiness" to make a technical decision
+seems like a contradiction.
+
+Anyway, why is there so much rush? jessie is going to default to
+sysvinit no matter what.
+
+Why not let the project evolve its own solution in the meantime?  The
+TC could help that along more so by giving the project some guidelines
+to best avoid obstructing each others init system work.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 17:33:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 17:33:09 GMT) (full text, mbox, link).

+ +

Message #3856 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Thoughts/Summary on the init-system
+
Date: Sun, 19 Jan 2014 18:31:14 +0100
+
+
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 it to be done in systemd as well.
+
+
+Also the question did arise what programs are allowed to depend upon? Could
+some program say it needs one specific pid1-provider or runlevel-manager? 
+For the question of "could Y be required as a supervising daemon" (like
+cereal depends on runit) I think we all agree it is possible, as long as Y
+doesn't require to be alone on the system (i.e. it doesn't require to be
+able to exclusivly control ressources); this even isn't for me for the tech
+ctte to decide because I don't think someone asked us that question. For
+the runlevel-manager and pid1-provider, I don't think that programs should
+be allowed to require one exclusivly - of course, some advanced
+functionality might be restricted to some managers/providers, but the
+program should not be unnecessary limited and willing to integrate other
+runlevel-manager/pid1-provider to the same amount if they provide same
+functionality.
+
+
+
+Support of more than one pid1/runlevel-manager?
+
+This is one of the core questions. If we end up with an init system which
+only works on Linux, we need to support at least two (however perhaps on
+Linux only one and another one only on non-Linux). 
+
+Expecting that we could support all three realistically well is an
+expectation I am not sharing. However, I think we could have the
+expectation that our users should be able to exchanges those providers
+without the system totally falling to pieces or deinstalling core
+components of the system (like people could today - e.g. runinit could be
+used to name one not on the hotlist of many minds). I also think we should
+have the expectation that exchanging of initsystems should continue to be a
+possiblity (this is more a mindset-question - because of course as today it
+might mean that people would have to invest time into that, but I could
+consider many reasons for a debian derivative to use e.g. openRC as
+provider; as said I don't expect to be easily possible but we should still
+be welcoming people trying other init systems, and be happy about accepting
+patches when they're ready).
+
+So we could converge on one pid1/runlevel-manager only if we choose one
+which is (going to be) available on all platforms.
+
+
+
+Support of !linux platforms
+
+From a long-term perspektive our non-linux-platforms as well as the
+non-x86-linux platforms have done us very good in getting our code in good
+shape, and help even on the mainstream linux platforms to find bugs earlier
+/ better (e.g. hurd with removal of static buffers). For details see e.g.
+http://lists.debian.org/87txd35snd.fsf@windlord.stanford.edu
+
+For this reason, I consider it important to make sure our
+non-linux-platforms are reasonable well supported.
+
+
+
+
+Vendor lockin
+
+This is a question which is relevant for both Upstart and Systemd. Answers
+are different, but I'm not happy with either Upstart being so
+canonical-centric (yet?) and systemd pulling more and more parts of the
+base system into it.  The later gives me even more concerns, because it
+means that our current flexibility in some of these parts will be steadily
+going down in the long run (see e.g. the relation between kbd and systemd
+in Collins mail for what that means - we are trading parts of our quality
+for more systemd integration, and I'm not sure that this is always a good
+trade). In fact, systemd would look better to me if it would be less
+invasive.
+
+
+
+Implementation details
+
+For openrc, this is a moving target. When I looked at it first during the
+start of this discussion, it was not even in experimental (and still is not
+in unstable), and documentation was hard to get. This has improved but
+still it is worse then the others.  Also having a no-double-fork-setup for
+demons is something really useable, and I haven't seen any answer on that
+during time of writing this. I appreciate the work that had been put into
+openRC, and I believe openRC is a major improvement over sysv-rc, and will
+also continue to have a useful place in the linux/unix ecosystem. I
+recommend openRC developers to keep up their good work. However for Debian
+I think it will not be our default choice for the Linux-architectures.
+Sorry.
+
+
+For systemd / upstart I also refer here mostly to other mails, e.g.
+http://lists.debian.org/20140118044132.GD12912@teltox.donarmstrong.com
+
+Systemd and upstart both have made different decisions implementation wise,
+but in the end the core topics (e.g. service startup notification,
+dependencies vs events, format of configuration files, documentation) are
+reasonable well resolved, so that I don't think that makes a relevant
+difference for the decision. (For the service startup notification I
+would recommend both to support the other protocoll as well, but
+nothing which should be part of a resolution.)
+
+
+
+Logind support for !systemd-based systems
+
+Logind seems to become an vital part for any desktop service. I seriously
+hope it will be continued to be maintained in a way that doesn't require
+systemd (independend of how debian decides for the pid1-provider), even
+though since release 205 this is harder or needs to be forked. See e.g.
+http://lists.debian.org/52DBE12B.7040603@debian.org for details. I don't
+see how this would be part of a decision right now, but is an important
+detail. (Some more details about cgroups, linux-centrisms, problems of that
+etc are in
+http://lists.debian.org/CAJS_LCXTpS1xdY6OWf6eQWZ5JWUJcCJ0sio8KaDakqwv2k8S+g@mail.gmail.com
+- and thanks Anthony for your good mails in the current discussion).
+
+
+
+
+
+
+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.
+
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 18:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Metzler <ametzler@bebt.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 18:18:04 GMT) (full text, mbox, link).

+ +

Message #3861 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Metzler <ametzler@bebt.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts/Summary on the init-system
+
Date: Sun, 19 Jan 2014 19:15:26 +0100
+
+
On 2014-01-19 Andreas Barth <aba@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'
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 18:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 18:27:04 GMT) (full text, mbox, link).

+ +

Message #3866 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Sun, 19 Jan 2014 19:23:17 +0100
+
+
Le lundi 20 janvier 2014 à 01:17 +1000, Anthony Towns a écrit :
+>  c) logind or an equivalent service implementing the freedesktop.org
+> systemd/logind api should be available under all supported init
+> systems and architectures in Debian. It should be provided via a
+> virtual package "fdo-logind" and packages (such as desktop managers)
+> expecting logind to be available should Depend on fdo-logind
+
+I think this is the right approach for logind. This way, the only
+implementation would be systemd as PID1, but if the proponents of
+alternative init systems actually wrote another implementation, it would
+be available.
+
+The one thing that is not handled this way is versioning, because later
+versions of GNOME could require newer APIs.
+
+
+I also have to insist that GNOME 3.10+ *needs* a working logind even for
+basic functionality, and that starting with v205, logind *needs* systemd
+as PID 1. You might disagree with the implementation details that lead
+to this situation, but you should not expect either of these facts to
+change before jessie.
+
+This is why the idea to fully support more than one init system is never
+going to hold.
+      * Either we upgrade systemd to a recent version and have (at
+        least) GNOME depend on systemd as PID 1.
+      * Either we keep systemd at version 204, we don’t use it as PID 1
+        (because it would be madness to be so lagging in versions), we
+        find people willing to do long-term maintenance on the
+        components we use (probably Canonical), and we have this
+        discussion again for the next release when the reverse
+        dependencies require newer versions of systemd.
+      * Either we remove systemd from Debian with all its reverse
+        dependencies (including at least GNOME).
+
+Currently I have no idea of how (and by whom) any other option than
+those three would be implemented, making any decision stating otherwise
+untenable.
+
+Cheers,
+-- 
+.''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 18:30:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 18:30:09 GMT) (full text, mbox, link).

+ +

Message #3871 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: 727708@bugs.debian.org
+
Cc: Andreas Metzler <ametzler@bebt.de>
+
Subject: Re: Bug#727708: Thoughts/Summary on the init-system
+
Date: Sun, 19 Jan 2014 18:27:20 +0000
+
+
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.
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 18:45:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 18:45:09 GMT) (full text, mbox, link).

+ +

Message #3876 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: 727708@bugs.debian.org
+
Cc: Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: On diversity
+
Date: Sun, 19 Jan 2014 18:40:58 +0000
+
+
On 19/01/14 18:23, Josselin Mouette wrote:
+> I also have to insist that GNOME 3.10+ *needs* a working logind even for
+> basic functionality, and that starting with v205, logind *needs* systemd
+> as PID 1.
+
+Sorry if this has been already answered, but if that's the opinion of
+GNOME maintainers, isn't this okay (starting in jessie or jessie+1)?
+Have GNOME depend on logind and indirectly systemd-as-pid1, and just be
+unavailable on other init systems.  Much of GNOME would thus become
+linux-any and be removed from GNU/kFreeBSD, but there are still other
+desktop environments to choose from.
+
+That is, until/unless someone else can provide an alternate
+implementation of logind, or whatever else is needed, then it would
+become installable/usable again.
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 19:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 19:00:04 GMT) (full text, mbox, link).

+ +

Message #3881 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Sun, 19 Jan 2014 20:56:43 +0200
+
+
On Sun, Jan 19, 2014 at 07:23:17PM +0100, Josselin Mouette wrote:
+>...
+> I also have to insist that GNOME 3.10+ *needs* a working logind even for
+> basic functionality,
+>...
+
+Can you elaborate on where exactly upstream GNOME 3.10 has a hard 
+dependency on logind, and no alternative ConsoleKit codepath that
+could be used instead?
+
+> Cheers,
+
+Thanks
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 19:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to svante.signell@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 19:39:04 GMT) (full text, mbox, link).

+ +

Message #3886 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Svante Signell <svante.signell@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: gdm3 is still gravely buggy even in Linux!
+
Date: Sun, 19 Jan 2014 20:37:36 +0100
+
+
...
+> On Sun, Jan 19, 2014 at 07:23:17PM +0100, Josselin Mouette wrote:
+> >...
+> > I also have to insist that GNOME 3.10+ *needs* a working logind even for
+> > basic functionality,
+> >...
+> 
+> Can you elaborate on where exactly upstream GNOME 3.10 has a hard 
+> dependency on logind, and no alternative ConsoleKit codepath that
+> could be used instead?
+
+Regarding gnome there is still a grave bug on gdm3 wrt systemd-logind
+in GNU/Linux I have tried to report, making it unusable on up till now
+three boxes upgraded (and subsequently replaced by lightdm and xfce4).
+Maybe we should have a discussion about default desktop system too.
+
+I tried to reopen bug #727708 but failed, and have to find the time to
+submit a new bug report. Problem is that in order to submit a bug
+report with report-bug you need a working desktop, but when gdm3 is
+buggy, how to report when it is no longer installed.
+
+Just my few cents as a _very_ frustrated (no longer) gnome user.  
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 19:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 19:45:04 GMT) (full text, mbox, link).

+ +

Message #3891 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Michael Gilbert <mgilbert@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: The tech ctte isn't considering OpenRC at all
+
Date: Sun, 19 Jan 2014 11:42:57 -0800
+
+
Michael Gilbert <mgilbert@debian.org> writes:
+> On Sun, Jan 19, 2014 at 6:52 AM, Russ Allbery wrote:
+
+>> But it was way behind both systemd and upstart in terms of readiness in
+>> Debian going into this discussion, and the amount of catching up that's
+>> required here for it to displace upstart as my second choice just
+>> doesn't seem feasible for me.
+
+> Shouldn't this be seen as reason to slow things down?  Using a
+> bureaucratic quality like "readiness" to make a technical decision seems
+> like a contradiction.
+
+At some point we have to make a decision.  We picked now.  This time is
+not obviously worse than any other time.
+
+There's always going to be one more system, or one more project, or one
+more set of features, that might change the situation.  upstart developers
+want to add socket activation.  systemd is going to be integrating with
+kdbus.  The world is always going to change.  If we wait for everything to
+stop changing, we'll never make a decision at all.
+
+This argument has been ripping Debian apart for over a year, causing a lot
+of serious unhappiness, very unpleasant threads in debian-devel,
+frustrated maintainers, and maintainers who feel like they have to force
+the issue in order to continue with their work.  The absence of a decision
+is causing quite a lot of pain and is very demotivating to a lot of
+developers.  I don't want to just let that continue until people give up
+and find something else to do with their volunteer time.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 19:54:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to svante.signell@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 19:54:10 GMT) (full text, mbox, link).

+ +

Message #3896 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Svante Signell <svante.signell@gmail.com>
+
To: Steven Chamberlain <steven@pyro.eu.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: gdm3 is still gravely buggy even in Linux!
+
Date: Sun, 19 Jan 2014 20:52:30 +0100
+
+
On Sun, 2014-01-19 at 19:44 +0000, Steven Chamberlain wrote:
+> On 19/01/14 19:37, Svante Signell wrote:
+> > I tried to reopen bug #727708 but failed
+> 
+> Was that a typo?  That's the bug number of the Debian tech-ctte bug.
+
+Yes, bug number is 724731, sorry.
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 20:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 20:30:04 GMT) (full text, mbox, link).

+ +

Message #3901 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system resolution open questions
+
Date: Sun, 19 Jan 2014 12:27:09 -0800
+
+
I think you and I have some fundamental disagreements about how this
+decision-making process should work, so I'm not sure that we're going to
+reach some satisfactory conclusion to this discussion.  But I'll take
+another try at this from another angle and see if it helps.
+
+Adrian Bunk <bunk@stusta.de> writes:
+
+> I think you missed my point.
+
+> Assume a CTTE member wants that Debian does continue to have non-Linux
+> ports, and therefore wants Debian to make the extra efforts for
+> supporting a second init system besides systemd.
+
+> What level of support (if any) would that guarantee for Debian's ports
+> to non-Linux kernels?
+
+I largely agree with Tollef's response.  I don't think that viewing this
+as a "guarantee" is a useful way of looking at the issue.
+
+Let me provide a concrete example.  Right now, we have a kFreeBSD port
+that was, for wheezy, a technology preview, and for which we've generally
+applied a release architecture attitude towards bugs.  However, I maintain
+a package that is simply not available on kFreeBSD (OpenAFS).  It's not
+been ported, I personally don't have the knowledge to figure out how to
+turn the upstream FreeBSD kernel support into something that would work in
+Debian, and if no one else steps forward to do the work, it's very likely
+to continue to be unsupported.
+
+This hasn't caused anyone any angst or excitement, despite the fact that,
+in a concrete way, one of Debian's non-Linux ports is not as
+well-supported as its Linux ports.  There's a piece of software (one that
+is quite important to some of our users) that is missing.  And yet, the
+port is still useful to the people who care about it.
+
+Now, GNOME is obviously a much more significant and higher-profile piece
+of software, and there's also a difference between something that has
+never been supported and something that used to be supported but for which
+upstream has dropped support.  But the situations are more similar than
+different, I think.  See also the state of OpenJDK on kFreeBSD, which has
+been tentative for a while, but which again does not destroy the value of
+the port to the people who are using it.
+
+The short version is that the level of support will be whatever people
+have the time and inclination to achieve.
+
+Now, what I hear you saying is, roughly, that you don't think that level
+of support is worth the amount of work that would be required to maintain
+parallel init systems, switching between init systems, and so forth, and
+that either we should require a higher level of support than that, or we
+should drop the whole concept of supporting multiple init systems.
+
+You may be right that the level of effort is not worth it, which is one of
+the reasons why I'm hestitant to lay out a bunch of requirements in
+advance for Debian contributors to do a lot of work.  However, I think we
+disagree about whether we should decide this tradeoff in advance.
+
+I also think you're overstating the amount of effort involved for the
+typical package.  This is exactly why I didn't trust my intuition and
+actually went and did the work for one of my packages.  I found that it
+really wasn't that much work to support multiple init systems, and it's
+work that mostly only has to be done once, and it's work that someone else
+can easily contribute and the maintainer can just incorporate.
+
+Yes, it's a lot of work for the init systems themselves, and for some
+packages with complex setup requirements, particularly to support
+switching, but that's also easier to test and to develop, because someone
+who cares about the problem can join that maintenance team and extensively
+test that one package.  The work is isolated and easier to focus on.  Or
+those packages can be dropped on the port, depending on how important they
+seem.
+
+Also, just to expand on my previous example with another package: I am
+upstream for a different package (lbcd, as it turns out, which I also used
+as a test package for this discussion) that didn't have support for some
+of its kernel operations on FreeBSD.  It therefore failed to build on
+kFreeBSD, and life went on.  However, the lack of builds on all of
+Debian's platforms bothered me at an aesthetic level, even though no one
+ever asked for the package on kFreeBSD and so far as I could tell no one
+cared.  So, late last year, I took a few hours, did a bit of research,
+discovered that porting the package to kFreeBSD under a set of assumptions
+that are probably true of all Debian kFreeBSD systems wasn't actually
+hard, and ported it.  It's unlikely that anyone is going to care, but it
+made me feel good to do it, and it wasn't that much effort.
+
+This is exactly the sort of thing that Debian makes possible, and is
+exactly the sort of thing that I don't want to *rule out* proactively in a
+decision.  I think it would have been ridiculous to *force* me to port
+lbcd to kFreeBSD in some way (such as making it a requirement for lbcd to
+be in the archive).  But if the facilities are available (I used the
+porter system to test, for instance), some people will just spontaneously
+help because they want to.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 20:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 20:51:04 GMT) (full text, mbox, link).

+ +

Message #3906 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Thomas Goirand <zigo@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: logind working without systemd
+
Date: Sun, 19 Jan 2014 12:49:38 -0800
+
+
Thomas Goirand <zigo@debian.org> writes:
+> Sun, 19 Jan 2014 13:42:40 +0200, Russ Allbery
+
+>> Hopefully, logind will continue to work without systemd and people will
+>> volunteer to maintain the necessary packaging for that configuration,
+>> and none of this will be a problem.
+
+> I really wish you were right Russ. Because that's not what upstream is
+> doing (since systemd 205, it's not the case), and Debian package
+> maintainers have stated this as an argument in the favor of systemd.
+
+> I would very much like the tech ctte to express itself on this topic on
+> the final statement (whatever default init system is chosen).
+
+Here's the problem with doing that: what, exactly, do you think the TC can
+say, given our powers and given the hard rule in Debian that no one is
+going to be forced to do work they don't want to do?
+
+Here are some possibilities that would arguably be within the remit of the
+Technical Committee:
+
+* The lack of a logind that works without systemd as PID 1 is an RC bug in
+  systemd, so systemd will be removed from the archive if it doesn't
+  provide this feature.  This is just silly to say, since removing it from
+  the archive doesn't provide a logind that works without systemd, so this
+  doesn't achieve anything useful.
+
+* NMUs to revert systemd to version 205 or earlier are permitted if the
+  systemd maintainers try to upload a newer version where logind doesn't
+  work without systemd.  This is clearly not a defensible solution.  We
+  can't hold the package indefinitely at a back revision and lose security
+  support, etc.  It might make some sense if the hard dependency of logind
+  on systemd were a bug that would be fixed in a later version, but that
+  doesn't appear to be how upstream views the issue.
+
+* NMUs to fork logind to work without systemd are permitted and the
+  systemd maintainers may not revert them.  *Assuming* there is some
+  irreconcilable conflict between the systemd maintainers and the people
+  who want to do this work (and I don't think that's a correct
+  assumption), I don't understand why we would take this approach as
+  opposed to packaging a non-systemd implementation of logind separately
+  with the required Conflicts and so on, so that the individual
+  maintainers can work on things that they care about without having
+  constant tension over NMUs.
+
+* The systemd maintainers are required to cooperate with people who are
+  doing the work to make logind work without systemd so that they aren't
+  prevented from maintaining those packages.  I see no reason why the TC
+  should say this given that there's no sign that the systemd maintainers
+  would not do this voluntarily.  Obviously, *right now*, there are
+  reasons to wait to see how this whole discussion will resolve since
+  that's going to significantly change the priorities and shape of this
+  work, but I see no reason to believe people wouldn't be able to work
+  this out in some reasonable way without the TC involvement if people are
+  available to do this work.
+
+I don't see the point in the TC saying any of those things, and I think
+some of them are actively destructive.  Furthermore, I think all of them
+are very ethically questionable.  If I were the systemd maintainers, most
+of these statements would strike me as heavy-handed extortion: an attempt
+of the TC to work around section 2.1.1 of the constitution and force me to
+do work by holding something else I care about hostage unless I do that
+work.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 21:18:28 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 21:18:28 GMT) (full text, mbox, link).

+ +

Message #3911 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC resolution Re: GR: Selecting the default init + system for Debian
+
Date: Sun, 19 Jan 2014 13:17:49 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sun, Jan 19, 2014 at 01:53:03PM +0000, Ian Jackson wrote:
+> Ian Jackson writes ("Re: GR: Selecting the default init system for Debian"):
+> > Russ Allbery writes ("Re: GR: Selecting the default init system for Debian"):
+> > > As a TC member, I dislike the supermajority requirement for the project to
+> > > overturn a TC decision by GR, particularly in this case.  I think we would
+> > > all be extremely unhappy if the TC voted one way on the default init
+> > > system and the project then voted a different way by a 60% majority.
+
+> > I agree.  I think that would be quite bad.  We could explicitly state
+> > in our TC resolution that the TC decision can be vacated by General
+> > Resolution on a simple majority.
+
+> It seems to me that in the situation Russ describes it would be best
+> for the GR's conclusion, rather than the TC's, to be de jure that of
+> the project.
+
+> I therefore intend to put into the drafts something along the lines I
+> suggest there, unless anyone objects.
+
+No objection; I think that's the right way to go.
+
+Thanks,
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 21:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 21:57:04 GMT) (full text, mbox, link).

+ +

Message #3916 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Don Armstrong <don@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Sun, 19 Jan 2014 13:52:57 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Hi Don,
+
+On Sat, Jan 18, 2014 at 09:59:39AM -0800, Don Armstrong wrote:
+> On Sat, 18 Jan 2014, Ian Jackson wrote:
+> > Do you recognise that a decision to make systemd the only supported
+> > init would mean the end of non-Linux-based ports of Debian ?
+
+> Which is why I'm not proposing it at this juncture. However, moving to a
+> single supported init system with a defined interface is something that
+> I would like to see. 
+
+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?
+
+Given systemd upstream's oft-stated opinion that other kernels are
+irrelevant and that systemd should make the best use of available Linux
+features, the first of these seems exceedingly unlikely to come to pass. 
+Indeed, it seems to me that systemd and upstart have been subjected to a
+double standard in much of the discussion on this bug, where we are open to
+the possibility of someone porting systemd to kFreeBSD and/or Hurd (despite
+zero evidence of anyone even entertaining the idea of doing so), but short
+shrift is given to statements that upstart upstream are committed to
+addressing various feature gaps that the TC considers important.
+
+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.  Adopting
+systemd is in fact a very high barrier to consolidating around the same init
+system for all ports, unless we drop the non-Linux ports.  Maybe that's an
+important factor for Debian, maybe it's not; but I don't want us to be
+fooled into believing the choice of init system doesn't have an impact on
+whether that consolidation will happen.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 21:57:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 21:57:07 GMT) (full text, mbox, link).

+ +

Message #3921 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Keith Packard <keithp@keithp.com>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 19 Jan 2014 21:53:56 +0000
+
+
Keith Packard writes ("Bug#727708: init system discussion status"):
+> In contrast, upstart has a developer community limited to Canonical
+> employees and others who are able and willing to sign the onerous CLA
+> associated with that software. [...]
+
+You said on IRC that the CLA was an important factor for you.  I'm
+going to make an attempt to persuade you that this is not a big
+problem for Debian.
+
+Firstly, I should say that I think the CLA is utterly ridiculous.
+I want to be completely clear that like almost everyone else in this
+conversation, I would certainly not sign it.
+
+But: I think you overestimate the likelihood of Debian being on the
+losing end of a fork.
+
+If we adopt upstart as default in Debian, I expect we will accumulate
+a number of important (CLA-less, obviously) patches in the Debian
+package.  Debian will be an attractive place even for non-Debian users
+to submit patches for the precise reason that we don't insist on
+unjust copyright arrangements.  In fact, I would expect much of the
+serious development to take place in Debian's version.
+
+Finally, we shouldn't be afraid of the scenario where the Debian
+version ends up being de facto the upstream.  We have become the
+upstream for numerous programs of comparable size.  And, to put my
+time where my mouth is, I'm willing to step up and contribute patches
+and help maintain the Debian upstart package.  Personaly I think
+upstart has the right approach and I think improving it sounds like
+fun.
+
+Like Andi, I think the risk to our autonomy from upstream is much
+lower in the case of upstart than systemd.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 19 Jan 2014 22:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 19 Jan 2014 22:03:04 GMT) (full text, mbox, link).

+ +

Message #3926 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Don Armstrong <don@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Sun, 19 Jan 2014 21:59:21 +0000
+
+
Don Armstrong writes ("Bug#727708: Thoughts on Init System Debate"):
+> On Sat, 18 Jan 2014, Ian Jackson wrote:
+> > Do you recognise that a decision to make systemd the only supported
+> > init would mean the end of non-Linux-based ports of Debian ?
+> 
+> Which is why I'm not proposing it at this juncture. However, moving to a
+> single supported init system with a defined interface is something that
+> I would like to see. 
+
+If you want that, and you want to keep the non-Linux ports, then I
+think you have to pick upstart as the single supported system.
+
+If we pick systemd as the default now, it will be very difficult to
+change our mind later.  So you need to decide now which you think is
+more important: the non-Linux ports, or systemd as the single init
+system for Debian.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 00:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 00:03:04 GMT) (full text, mbox, link).

+ +

Message #3931 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, Don Armstrong <don@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Sun, 19 Jan 2014 16:58:57 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> Don Armstrong writes ("Bug#727708: Thoughts on Init System Debate"):
+>> However, moving to a single supported init system with a defined
+>interface is something that I would like to see. 
+>
+> If you want that, and you want to keep the non-Linux ports, then I
+> think you have to pick upstart as the single supported system.
+
+Look, I completely understand your position with respect to systemd
+upstream's attitude about portability patches, but I don't entirely
+understand how that leads to an "upstart is the only answer" conclusion.
+
+For example, given your note about what would cause you to re-consider
+OpenRC earlier today, I can't help but wonder about the relative
+development effort required to add non-forking daemon support to OpenRC
+as compared to the effort required to add kfreebsd and hurd support to
+upstart?  The fact that OpenRC has reportedly already booted on both
+kfreebsd and hurd systems certainly intrigues *me*, and copying either
+the systemd or upstart approaches to non-forking daemon support in OpenRC
+might be plausible?
+
+Perhaps that still wouldn't leave a solution you would personally vote
+above upstart, but suggesting the only options are "pick upstart or bail
+on non-Linux kernels" just doesn't ring true to me.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 00:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Matthias Klumpp <mak@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 00:15:04 GMT) (full text, mbox, link).

+ +

Message #3936 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Matthias Klumpp <mak@debian.org>
+
To: Bdale Garbee <bdale@gag.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Mon, 20 Jan 2014 01:12:36 +0100
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+>
+> Don Armstrong writes ("Bug#727708: Thoughts on Init System Debate"):
+>> However, moving to a single supported init system with a defined
+>interface is something that I would like to see.
+>
+> If you want that, and you want to keep the non-Linux ports, then I
+> think you have to pick upstart as the single supported system.
+Please note that upstart is not yet ported to !Linux systems, and has
+never run on any (yet). It makes only light use of Linux kernel
+features, but due to the CLA we would depend on Canonical or people
+willing to sign it to port it to !Linux kernels, which is not really a
+nice thing.
+Also, Canonical as being Linux-only has less interest in !Linux ports.
+OpenRC is already working on BSD (and maybe someone might make it read
+systemd service files some time in the future - the syntax is
+declarative, so alternative systemd implementations are theoretically
+possible)[1]
+Cheers,
+    Matthias
+
+[1]: I know that that stuff does not exist yet and should therefore
+not be counted as an argument in favour/against anything. But it is an
+interesting opportunity.
+
+-- 
+I welcome VSRE emails. See http://vsre.info/
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 00:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 00:33:04 GMT) (full text, mbox, link).

+ +

Message #3941 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Steven Chamberlain <steven@pyro.eu.org>, 727708@bugs.debian.org
+
Cc: 727708@bugs.debian.org, Andreas Metzler <ametzler@bebt.de>
+
Subject: Re: Bug#727708: Thoughts/Summary on the init-system
+
Date: Mon, 20 Jan 2014 00:22:55 -0008
+
+
[Message part 1 (text/plain, inline)]
+
On Sun, Jan 19, 2014 at 10:27 AM, Steven Chamberlain 
+<steven@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
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 00:39:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 00:39:10 GMT) (full text, mbox, link).

+ +

Message #3946 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Matthias Klumpp <mak@debian.org>, 727708@bugs.debian.org
+
Cc: Bdale Garbee <bdale@gag.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Mon, 20 Jan 2014 00:28:20 -0008
+
+
[Message part 1 (text/plain, inline)]
+
On Sun, Jan 19, 2014 at 4:12 PM, Matthias Klumpp <mak@debian.org> wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+>> 
+>>  Don Armstrong writes ("Bug#727708: Thoughts on Init System Debate"):
+>>>  However, moving to a single supported init system with a defined
+>>> 
+>> interface is something that I would like to see.
+>> 
+>>  If you want that, and you want to keep the non-Linux ports, then I
+>>  think you have to pick upstart as the single supported system.
+>> 
+> Please note that upstart is not yet ported to !Linux systems, and has
+> never run on any (yet). It makes only light use of Linux kernel
+> features, but due to the CLA we would depend on Canonical or people
+> willing to sign it to port it to !Linux kernels, which is not really a
+> nice thing.
+> 
+
+I think Ian actually mentioned that a Debian specific, no-CLA patch set 
+could be used to port to other architectures to avoid the CLA. I think 
+that would be a little annoying, especially for Upstart maintainers, 
+but it is theoretically possible.
+
+Cheers,
+--
+Cameron Norman
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 00:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 00:51:04 GMT) (full text, mbox, link).

+ +

Message #3951 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Sun, 19 Jan 2014 16:48:45 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> Firstly, I should say that I think the CLA is utterly ridiculous.
+> I want to be completely clear that like almost everyone else in this
+> conversation, I would certainly not sign it.
+
+It's divisive, and has already managed to fragment the community into
+two camps. As Kay said (in google+, alas):
+
+        https://plus.google.com/u/0/+KaySievers/posts/C3chC26khpq
+
+The development of systemd was, at least in part, due to the CLA. The
+result was that the bulk of ongoing init system work moved away from
+upstart and towards systemd.
+
+Free software developers gain value in proportion to the number of
+people sharing and using their code. Failing to enter into a CLA limits
+the potential market for contributions.
+
+I feel that having the Debian community endorse software where a CLA is
+involved will tacitly encourage developers to enter into those
+agreements so that their work can be published as widely as possible.
+
+Personally, I would like us to take a principled stand against
+corporate-sponsored CLA-restricted software projects as I feel they do
+not follow the spirit of the DFSG, even as they follow the letter. They
+remind me too strongly of Animal Farm.
+
+> Like Andi, I think the risk to our autonomy from upstream is much
+> lower in the case of upstart than systemd.
+
+Certainly the fraction of Debian influence in upstart would be
+dramatically larger than our influence could be in systemd as so many
+fewer people outside of Debian are working on upstart than systemd.
+
+A significant benefit of systemd is precisely that a lot of other people
+are working on it, and appear willing to continue working on it. The
+best way to make Debian gain relevance and importance there will be to
+increase the number of Debian developers actively participating in
+improving it.
+
+If autonomy from other distributions was an explicit Debian goal, then
+we'd presumably be spending a lot more time cleaning up the Hurd instead
+of collaborating with others on Linux.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 00:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 00:54:04 GMT) (full text, mbox, link).

+ +

Message #3956 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Matthias Klumpp <mak@debian.org>, 727708@bugs.debian.org
+
Cc: Bdale Garbee <bdale@gag.com>
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Sun, 19 Jan 2014 16:51:35 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Jan 20, 2014 at 01:12:36AM +0100, Matthias Klumpp wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> > Don Armstrong writes ("Bug#727708: Thoughts on Init System Debate"):
+> >> However, moving to a single supported init system with a defined
+> >> interface is something that I would like to see.
+
+> > If you want that, and you want to keep the non-Linux ports, then I
+> > think you have to pick upstart as the single supported system.
+> Please note that upstart is not yet ported to !Linux systems, and has
+> never run on any (yet).
+
+Not true.  Upstart has been ported to kfreebsd, and has successfully booted
+to a getty.
+
+  https://lists.debian.org/debian-bsd/2014/01/msg00164.html
+
+There seem to be some kinks to work out before it's entirely stable, and
+probably a fair amount of integration work before it's usable for booting to
+multiuser, but upstart does run on kfreebsd now.
+
+This has even been mentioned on this bug:
+
+  https://lists.debian.org/debian-ctte/2014/01/msg00258.html
+
+While I realize there are a lot of threads to keep up with in this
+discussion, it would help everyone with the task of keeping up to not have
+outdated information repeated unnecessarily ;)
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 02:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 02:33:05 GMT) (full text, mbox, link).

+ +

Message #3961 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Thomas Goirand <zigo@debian.org>
+
Subject: Re: Bug#727708: The tech ctte isn't considering OpenRC at all
+
Date: Sun, 19 Jan 2014 18:29:35 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Thomas Goirand writes ("Bug#727708: The tech ctte isn't considering OpenRC at all"):
+>> But that OpenRC just hasn't been considered just because of rumors is
+>> really unacceptable.
+>
+> The reason I haven't seriously considered OpenRC for the default is
+> that it wasn't ready.
+>
+> Perhaps things have improved.  But I don't think it is necessarily the
+> TC's job to go back and revisit OpenRC in these circumstances.  How
+> mature a system is and how well-developed in Debian are relevant
+> factors and it's not unreasonable to set a deadline, at which the
+> state of the system in Debian will be the basis of our technical
+> evaluation.
+>
+>
+> On to specifics:
+>
+> Thomas, does OpenRC provide a means for do non-forking daemon
+> startup ?
+[...]
+
+Ian, quoting from your previous evaluation of upstart
+(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1499):
+
+,----
+| [...]
+| upstart's minimalism is very appealing to me.
+| 
+| It does, however, have a number of missing features.  Those I have in
+| mind are:
+|   - ability to log daemon output to syslog
+|   - multiple socket activation (systemd socket activation protocol)
+|   - socket activation for IPv6 (and datagram sockets)
+| 
+| Of these Russ rightly points out that lack of IPv6 support is rather
+| poor; it is arguably not suitable for release in jessie without this.
+| 
+| However, crucially, these are all simple matters of programming,
+| without difficult design decisions.  They IMO don't reveal structural
+| problems with upstart's approach to things.
+| [...]
+| I therefore conclude that the default init system for jessie should be
+| upstart.
+`----
+
+I don't see how this is consistent with what you say about
+OpenRC. Either the lack of features isn't a problem if they can in
+principle be implemented in the future (in that case, upstart and OpenRC
+are both viable candidates), or hypothetical features do not matter (in
+that case this should also hold for upstart).
+
+
+I'm not saying that the existing OpenRC and upstart features are on par,
+but outright rejecting OpenRC just because of missing features does not
+seem fair to me when you at the same time consider the missing upstart
+features as irrelevant because they can still be implemented.
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 04:18:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 04:18:05 GMT) (full text, mbox, link).

+ +

Message #3966 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Anthony Towns <aj@erisian.com.au>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Sun, 19 Jan 2014 20:15:05 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
+
+>  d) [are packages likely to start depending on
+> localed/hostnamed/timedated/machined/??? in the same way as logind
+> such that it would need to be available outside systemd for upstart to
+> be a useful init?]
+
+GNOME certainly uses these interfaces already.  Whether they should be
+considered a "dependency" or not is probably something that should be left
+to the maintainers' discretion.  But I think they should certainly be
+handled the same way as logind, generally - with a dependency on some
+virtual package that other implementations could provide (or that can be
+provided by a binary package from systemd source that doesn't depend on pid
+1 - since these dbus services all work fine on non-systemd systems, and
+there's no technical reason that should ever change given the function of
+the services in question).
+
+> I think (a) and (b) are pretty non-controversial. (c) and (d) are
+> required if we want to deal with new GNOME stuff and anything other
+> than systemd probably, and don't seem very hard to either do or
+> document. (e), (f) and (g) seem like a fairly straightforward of
+> allowing for multiple init systems in Debian. I think something like
+> (i) might be a good way of sunsetting tech ctte decisions so if
+> there's an actual consensus in future, there's no need to get a
+> pro-forma vote from the ctte to make changes in future. YMMV of
+> course.
+
+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.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 04:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 04:33:04 GMT) (full text, mbox, link).

+ +

Message #3971 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org, Anthony Towns <aj@erisian.com.au>
+
Subject: Re: Bug#727708: On diversity
+
Date: Sun, 19 Jan 2014 20:29:23 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
+
+>> I think (a) and (b) are pretty non-controversial. (c) and (d) are
+>> required if we want to deal with new GNOME stuff and anything other
+>> than systemd probably, and don't seem very hard to either do or
+>> document. (e), (f) and (g) seem like a fairly straightforward of
+>> allowing for multiple init systems in Debian. I think something like
+>> (i) might be a good way of sunsetting tech ctte decisions so if there's
+>> an actual consensus in future, there's no need to get a pro-forma vote
+>> from the ctte to make changes in future. YMMV of course.
+
+> 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.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 05:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 05:54:04 GMT) (full text, mbox, link).

+ +

Message #3976 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Mon, 20 Jan 2014 15:51:20 +1000
+
+
On 20 January 2014 14:29, Russ Allbery <rra@debian.org> wrote:
+> Steve Langasek <vorlon@debian.org> writes:
+>> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
+>>> I think (a) and (b) are pretty non-controversial. (c) and (d) are
+>>> required if we want to deal with new GNOME stuff and anything other
+>>> than systemd probably, and don't seem very hard to either do or
+>>> document. (e), (f) and (g) seem like a fairly straightforward of
+>>> allowing for multiple init systems in Debian. I think something like
+>>> (i) might be a good way of sunsetting tech ctte decisions so if there's
+>>> an actual consensus in future, there's no need to get a pro-forma vote
+>>> from the ctte to make changes in future. YMMV of course.
+>> 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.
+
+Personally, I'm still not really clear on where the ctte is leaning
+wrt supporting multiple init systems; if the idea is that [OpenRC]
+becomes the new default, and declares itself as Essential:yes, and the
+Debian maintainers of [systemd and upstart] say "okay, I give up, I'm
+going to work on [OpenRC] now", it doesn't seem like there'd be much
+need for policy work. Obviously, switch the init systems around as
+appropriate. I believe I've seen comments along those lines from both
+systemd and upstart maintainers should upstart or systemd be chosen as
+the default, but maybe I'm mistaken. I'm pretty sure I've seen
+numerous comments that Debian should only support one init system (per
+kernel, at any rate), which would make the Essential:yes part make
+sense. To me that seems like it would be a bad outcome (even if we
+adopted upstart everywhere and abandoned sysvrc, systemd and openrc
+entirely; it would still make it unduly difficult to experiment with
+the next next-generation init systems in a Debian environment). I'd
+expect the tech ctte's decision to be prescriptive enough that it's
+clear what non-default-init-system maintainers and users should do,
+post-apocalypse, I guess.
+
+On a practical note, having a quick look at the policy list, it seems
+like that's not actually crazy active/responsive at present either
+(long overdue updates to menu policy and triggers documentation are
+the only topics this month?), so relying on -policy for detail work
+doesn't seem like it would actually work out in a timely fashion?
+
+Honestly, I was a bit surprised that Steve thinks the above's a good
+idea, given I wrote it from the (my) perspective of wanting to support
+multiple init systems within Debian; and my understanding is his
+opinion is that that's kind-of nuts. I think that's pretty great
+through, especially in that it affirms my naive faith that drilling
+down into technical details is a good way of achieving consensus
+amongst people with very different goals and political/philosophical
+stances... ;)
+
+Cheers,
+aj
+
+-- 
+Anthony Towns <aj@erisian.com.au>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 06:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 06:09:04 GMT) (full text, mbox, link).

+ +

Message #3981 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Anthony Towns <aj@erisian.com.au>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Sun, 19 Jan 2014 22:07:20 -0800
+
+
Anthony Towns <aj@erisian.com.au> writes:
+
+> To me that seems like it would be a bad outcome (even if we adopted
+> upstart everywhere and abandoned sysvrc, systemd and openrc entirely; it
+> would still make it unduly difficult to experiment with the next
+> next-generation init systems in a Debian environment). I'd expect the
+> tech ctte's decision to be prescriptive enough that it's clear what
+> non-default-init-system maintainers and users should do,
+> post-apocalypse, I guess.
+
+For as long as they're interested in making the effort, try to get as many
+packages as possible supported under their init system, particularly in
+advance of the point at which we might start dropping sysvinit scripts
+that currently provide the common denominator across all the systems.
+Obviously, to the extent that this can reuse work done for the default
+init system, that's going to make this much easier.  That means that
+implementing the key integration features of the default init system will
+make things much easier (for example, things like the notification
+protocol, non-forking daemon startup, and possibly socket activation).
+
+It's going to be particularly important to have good docs for maintainers
+to write configuration for the non-default init system, since a lot of
+maintainers aren't going to be able to easily test, so you want people to
+be able to write things that work without a lot of debugging.  Obviously,
+that includes Policy.
+
+> On a practical note, having a quick look at the policy list, it seems
+> like that's not actually crazy active/responsive at present either (long
+> overdue updates to menu policy and triggers documentation are the only
+> topics this month?), so relying on -policy for detail work doesn't seem
+> like it would actually work out in a timely fashion?
+
+Policy is in general not horribly healthy right now, but as I mentioned in
+passing earlier in this huge thread, I'm committing to shephard the Policy
+work for this decision through and try to help with the documentation and
+specifics.  I can't do that and participate in this discussion at the same
+time, though, since this is basically eating all my Debian time at the
+moment.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 06:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 06:27:04 GMT) (full text, mbox, link).

+ +

Message #3986 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Anthony Towns <aj@erisian.com.au>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: On diversity
+
Date: Sun, 19 Jan 2014 22:24:11 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Jan 20, 2014 at 03:51:20PM +1000, Anthony Towns wrote:
+> Honestly, I was a bit surprised that Steve thinks the above's a good
+> idea, given I wrote it from the (my) perspective of wanting to support
+> multiple init systems within Debian; and my understanding is his
+> opinion is that that's kind-of nuts. I think that's pretty great
+> through, especially in that it affirms my naive faith that drilling
+> down into technical details is a good way of achieving consensus
+> amongst people with very different goals and political/philosophical
+> stances... ;)
+
+:)
+
+So to expand on where I'm coming from:  I think that it's important to
+choose a default for jessie, and that it's important that this not be
+sysvinit; and I think whatever init system we choose for jessie will wind up
+having a significant boost in momentum within Debian which will give it
+staying power for a long time to come, and the non-default init systems will
+receive little if any attention.  But I don't think the TC decision should
+be a *permanent* one; as you say, there's always a next next-generation to
+think about.  So I think we shouldn't have any particular init system marked
+as Essential: yes.  Indeed, sysvinit being marked Essential: yes was an
+obstacle for upstart in Debian for quite a while; less so for systemd
+because the systemd maintainers made the expedient - but IMHO technically
+undesirable - decision to split all conflicting files into a separate
+package.
+
+So that's to e).  f) is the sort of thing I think should be time limited to
+jessie; g) seems obviously correct as far as it goes, but I think we might
+quibble on the details of what packages are allowed to do this and why,
+because one of the important features of Debian is that you can install
+nearly anything from the archive together on the same system.  Having
+packages with mutually incompatible dependencies on specific init systems
+would undermine this badly.
+
+And c) and d) are completely aligned with what I've been arguing (perhaps
+poorly) that should be done with logind integration, because it's relevant
+even if we don't adopt upstart as the default, as long as we want to have
+non-Linux ports going forward.
+
+So while I don't want to encourage the project to divide its efforts across
+multiple different init systems in jessie, I think the particular points you
+raise here are good ones, and I would only quibble on some of the minor
+details.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 07:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Pacho Ramos <pacho@gentoo.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 07:18:05 GMT) (full text, mbox, link).

+ +

Message #3991 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Pacho Ramos <pacho@gentoo.org>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Cc: Anthony Towns <aj@erisian.com.au>, Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: On diversity
+
Date: Mon, 20 Jan 2014 08:15:13 +0100
+
+
Have you think in having a Systemd team in Debian taking care of
+providing support for its packages? That way, people should be able to
+run it in some weeks and, as soon as existing init.d files are not
+dropped, people won't lose support for that (apart of the cases like
+GNOME that needs systemd running to work better)
+
+That is the way we went on Gentoo and looks to work well: we started
+from openRC only setup, when we needed better systemd support along our
+portage tree due Gnome 3.8 requirements, we (Gentoo systemd team)
+started to work in adding systemd support and unit files to our
+packages, that way, our maintainers weren't forced to run systemd to
+test their unit files work fine and test both systems themselves.
+
+We now have a working Systemd setup and, for our BSD ports, people still
+have openRC support (even not being able to run all features of GNOME
+but... much more cannot be done on that since
+http://www.gentoo.org/proj/en/desktop/gnome/openrc-settingsd.xml isn't
+enough to not lose any features since 3.8)
+
+From my perspective, I would support both setups: systemd (due it being
+required by more upstreams along the time, and, *in my personal
+opinion*, I think it works pretty well) and another one for BSDs and
+people hating so much Systemd (I would choose openRC... but since I come
+from Gentoo and know about it more than about upstart... ;))
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 07:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 07:21:04 GMT) (full text, mbox, link).

+ +

Message #3996 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Don Armstrong <don@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Sun, 19 Jan 2014 23:18:26 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Hi Don,
+
+On Fri, Jan 17, 2014 at 08:41:32PM -0800, Don Armstrong wrote:
+> Systemd's socket-based activation and cgroup based tracking are
+> technically superior to upstart, even though the latter causes problems
+> with portability to non-linux systems. However, if we were to decide on
+> upstart, we could have just a single init system everywhere, which would
+> be beneficial.[3]
+
+<snip>
+
+> I should point out that I have not extensively examined openrc, nor have
+> I taken into account planned features and development in either systemd
+> or upstart which could sway my opinion.
+
+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.
+
+Thanks,
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 07:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 07:36:04 GMT) (full text, mbox, link).

+ +

Message #4001 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Mon, 20 Jan 2014 08:27:47 +0100
+
+
]] Steve Langasek 
+
+> GNOME certainly uses these interfaces already.  Whether they should be
+> considered a "dependency" or not is probably something that should be left
+> to the maintainers' discretion.  But I think they should certainly be
+> handled the same way as logind, generally - with a dependency on some
+> virtual package that other implementations could provide (or that can be
+> provided by a binary package from systemd source that doesn't depend on pid
+> 1 - since these dbus services all work fine on non-systemd systems, and
+> there's no technical reason that should ever change given the function of
+> the services in question).
+
+I'm willing to look at adding virtual packages for those once we
+actually see alternative implementations happening.  Adding them because
+somebody might, maybe, possibly add them somewhere down the line sounds
+premature.
+
+As for whether they should work with non-pid1 or not, it's also a
+question about what we (the systemd maintainers) want to support.  The
+daemons currently don't require systemd as pid1, but given all the flak
+over maybe making logind require systemd as pid1 there is a very strong
+incentive to not make those implementations work with another init.  The
+CTTE here and in the past (see NM) views regressions as much more
+serious than lacking implementations.
+
+I think this is pretty sad and gives maintainers perverse incentives,
+since there's not really any graceful way to say «this will no longer
+be/is no longer supported» without risking being struck down.  It's a
+somewhat separate discussion from the whole «what should be the default
+init system» discussion, but it's one we (as a project) should be having
+at some point.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 08:36:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thomas Goirand <zigo@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 08:36:11 GMT) (full text, mbox, link).

+ +

Message #4006 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thomas Goirand <zigo@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: The tech ctte isn't considering OpenRC at all
+
Date: Mon, 20 Jan 2014 16:33:00 +0800
+
+
On 01/19/2014 08:15 PM, Ian Jackson wrote:
+> How mature a system is and how well-developed in Debian are relevant
+> factors
+
+If we're making a competition of how long has an given init system been
+in Debian, then for sure, OpenRC looses. However, on all the tests I
+did, I see no major issue with OpenRC. Could you point to specific
+issues that you've encountered? Otherwise, what do you have in mind
+exactly, apart from "this is too new, so I don't trust it and therefore
+refuse to even try it"?
+
+> and it's not unreasonable to set a deadline, at which the
+> state of the system in Debian will be the basis of our technical
+> evaluation.
+
+What's difficult for the TC, is that your decision also impacts the
+future, not only the present. Only considering what we have right now
+isn't unfortunately enough.
+
+I do hope that you are also considering the possible outcomes of current
+developments, and paths which has been taken by upstream. I believe it
+has been the case already, for example, logind, udev, gnome, etc. and
+their future support (using this or that init system) has been part of
+this discussion.
+
+It doesn't seem reasonable to just ignore future plans, and incoming
+features which are currently in active development (see below about
+s-vision patch, which I believe is a very good example illustrating what
+I'm saying here).
+
+On 01/19/2014 08:15 PM, Ian Jackson wrote:
+>  * The daemon does not double-fork; it runs in the foreground of
+>    of its initial process.
+
+Something like start-stop-daemon then? :)
+
+See also the command_background directive (in the man openrc-run).
+
+On 01/19/2014 08:15 PM, Ian Jackson wrote:
+>  * The daemon's parent process (part of the init system) keeps
+>    track of it, so the init system knows whether the process
+>    is still running.
+
+First, OpenRC isn't stateless like sysv-rc to begin with (try
+"rc-status" to see what daemon is running). Status are kept in
+/run/openrc/started using symlinks to /etc/init.d, and OpenRC uses
+(optionally) cgroups to shutdown daemons, if that's what you ask.
+
+Then, the answer to this question is even more definitively "yes", if
+you use this patch:
+https://github.com/qnikst/openrc/compare/s-vision
+
+which uses monit for the process supervision. If you don't know monit,
+well this probably means you haven't played much with servers. Monit has
+been in Debian since 2002. It is a very mature tool which is great on
+the server side. One of the very cool feature of Monit, is that it
+includes email reports (so you know a daemon actually crashed), and
+actual service functionality testing (like, is apache returning "hello
+world!" when querying this URL, for example...), which none of the other
+init system (to the best of my knowledge) implements yet. It is to me a
+far more superior approach than just checking for a daemon to be just
+"running" (but maybe crashed in a CPU-burn loop...).
+
+I'm talking about a *working patch* here, not just "future plans". If I
+didn't add it as a debian/patches add-on, this is because version 0.13
+of OpenRC is supposed to be out soon, and it's my understanding that it
+would be including it. So I do prefer to wait for the new upstream
+release, but it's going to be there soon. Not taking this into account
+isn't, IMO, reasonable.
+
+On 01/19/2014 08:15 PM, Ian Jackson wrote:
+>  * The daemon's stderr goes somewhere reasonable.
+
+Hum... By default, I honestly don't know what would be the behavior of a
+daemon doing some output to stderr. However, I believe it'd be really
+trivial to do in the command= statement of a runscript. Something like:
+
+command="foo >/var/log/foo.log 2>&1"
+
+or using the command_arg directive should be enough (I haven't tested,
+but this seems reasonable).
+
+Thomas Goirand (zigo)
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 09:21:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 09:21:10 GMT) (full text, mbox, link).

+ +

Message #4011 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Thomas Goirand <zigo@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: The tech ctte isn't considering OpenRC at all
+
Date: Mon, 20 Jan 2014 01:17:13 -0800
+
+
Thomas Goirand <zigo@debian.org> writes:
+
+> Then, the answer to this question is even more definitively "yes", if
+> you use this patch:
+> https://github.com/qnikst/openrc/compare/s-vision
+
+> which uses monit for the process supervision. If you don't know monit,
+> well this probably means you haven't played much with servers. Monit has
+> been in Debian since 2002. It is a very mature tool which is great on
+> the server side.
+
+monit is a fine tool, but it's really orthogonal to the question of what
+an init system should do.  It's essentially an event-based monitoring tool
+that, as you say, can monitor various aspects of a service apart from just
+whether it's running and trigger arbitrary actions on that basis.  It will
+work with any init system; in fact, normally it's configured to run init
+scripts.
+
+I don't see it as a substitute for the init system tracking accurate state
+and PID of its daemons.  The point of knowing the state of daemons isn't
+only to be able to restart them when they die, although that's certainly
+important and one gets that effectively for free once one has state
+tracking.  It's to ensure that everything else the init system is managing
+stays consistent and is in a known state for features such as
+dependencies.  If service A depends on service B, and you try to start
+service B, you want the init system to know that service A has crashed and
+isn't currently running so that it can take the correct actions.  And, of
+course, the init system needs to know the correct PID to send various
+signals to for such things as stop and refresh actions.
+
+Now, you could possibly use monit as the component that does that.  But it
+just moves the problem to figuring out how to do proper non-forking
+startup and startup notification to monit instead of the init system.
+
+I didn't recall monit having direct support for that, and I just now
+reviewed the documentation and still don't see that documented.  Does
+monit now support something like the systemd startup notification protocol
+or the upstart expect stop protocol?
+
+> One of the very cool feature of Monit, is that it includes email reports
+> (so you know a daemon actually crashed), and actual service
+> functionality testing (like, is apache returning "hello world!" when
+> querying this URL, for example...), which none of the other init system
+> (to the best of my knowledge) implements yet. It is to me a far more
+> superior approach than just checking for a daemon to be just "running"
+> (but maybe crashed in a CPU-burn loop...).
+
+Service functionality testing is a nice feature for what monit is trying
+to do, but it's somewhat less helpful in the context of the init system.
+
+When configured by the local sysadmin, deciding that Apache is running if
+something is responding on port 80 is fine, since the sysadmin knows
+that's the only thing they're running on port 80.  But the init system
+needs to have more accurate tracking than that, for exactly the same
+reason that Debian Policy says that init scripts should not stop random
+other processes that happen to have the same executable name as the daemon
+the init script is supposed to be managing.  (Something that a lot of our
+init scripts currently probably don't handle correctly, since doing this
+properly without starting processes in the foreground using the strategies
+used by either upstart or systemd can be quite tricky, although
+start-stop-daemon tries to provide proper tools.)
+
+There's definitely a place for monit in an overall systems architecture,
+along with a way for monit to tell the init system "hey, you might think
+this thing is running, but based on the additional probes I've been
+configured to try, I think it's actually hosed."  But it's not solving
+quite the same problem.
+
+> On 01/19/2014 08:15 PM, Ian Jackson wrote:
+>>  * The daemon's stderr goes somewhere reasonable.
+
+> Hum... By default, I honestly don't know what would be the behavior of a
+> daemon doing some output to stderr. However, I believe it'd be really
+> trivial to do in the command= statement of a runscript. Something like:
+
+> command="foo >/var/log/foo.log 2>&1"
+
+> or using the command_arg directive should be enough (I haven't tested,
+> but this seems reasonable).
+
+The problem with just redirecting output to a log file is that now that
+log file is impossible to rotate safely, since you can't rename foo.log
+and tell the daemon to re-open a new file by that name.  In other words,
+this is a great way to run a production server out of disk space, as I
+have done multiple times in the past by using a technique like this and
+not thinking it through.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 11:27:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 11:27:09 GMT) (full text, mbox, link).

+ +

Message #4016 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Keith Packard <keithp@keithp.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Mon, 20 Jan 2014 11:23:39 +0000
+
+
Keith Packard writes ("Re: Bug#727708: init system discussion status"):
+> I feel that having the Debian community endorse software where a CLA is
+> involved will tacitly encourage developers to enter into those
+> agreements so that their work can be published as widely as possible.
+
+I can see the force of this point.
+
+Could we address this by adding something explicit to the TC
+resolution ?
+
+  N. We are firmly opposed to Canonical's upstart Contributor Licence
+     Agreement.
+
+     As with any other program in Debian whose upstream has
+     controversial copyright practices, the Debian project will
+     continue accept and deploy useful patches whose contributors
+     decline to enter into unfair copyright agreements.
+
+     We recommend that Debian contributors do not sign the CLA, even
+     when contributing changes which might be widely useful.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 11:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 11:33:04 GMT) (full text, mbox, link).

+ +

Message #4021 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Nikolaus Rath <Nikolaus@rath.org>, + 727708@bugs.debian.org
+
Cc: Thomas Goirand <zigo@debian.org>
+
Subject: Re: Bug#727708: The tech ctte isn't considering OpenRC at all
+
Date: Mon, 20 Jan 2014 11:28:43 +0000
+
+
Nikolaus Rath writes ("Bug#727708: The tech ctte isn't considering OpenRC at all"):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > Thomas, does OpenRC provide a means for do non-forking daemon
+> > startup ?
+> [...]
+> 
+> Ian, quoting from your previous evaluation of upstart
+> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1499):
+...
+> I don't see how this is consistent with what you say about
+> OpenRC. Either the lack of features isn't a problem if they can in
+> principle be implemented in the future (in that case, upstart and OpenRC
+> are both viable candidates), or hypothetical features do not matter (in
+> that case this should also hold for upstart).
+
+Firstly, non-forking daemon startup and supervision is less of a
+feature and more of a design decision.  I think that doing it from
+scratch in a system which doesn't have it at all involves a lot of
+design decisions and a fair amount of programming work.
+
+Secondly, the features I list as missing for upstart are not IMO
+anywhere near as important.
+
+If you think OpenRC will soon have non-forking daemon startup, then
+excellent.  Can you explain to me how it will work ?
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 11:33:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 11:33:08 GMT) (full text, mbox, link).

+ +

Message #4026 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve Langasek <vorlon@debian.org>, + 727708@bugs.debian.org
+
Cc: Anthony Towns <aj@erisian.com.au>
+
Subject: Re: Bug#727708: On diversity
+
Date: Mon, 20 Jan 2014 11:30:11 +0000
+
+
Steve Langasek writes ("Bug#727708: On diversity"):
+> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
+> > I think (a) and (b) are pretty non-controversial. (c) and (d) are
+> > required if we want to deal with new GNOME stuff and anything other
+> > than systemd probably, and don't seem very hard to either do or
+> > document. (e), (f) and (g) seem like a fairly straightforward of
+> > allowing for multiple init systems in Debian. I think something like
+> > (i) might be a good way of sunsetting tech ctte decisions so if
+> > there's an actual consensus in future, there's no need to get a
+> > pro-forma vote from the ctte to make changes in future. YMMV of
+> > course.
+> 
+> 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 reolution if
+> there's not a consensus for it.
+
+I lost track of all these (a)..(i).  But I wouldn't say that it's not
+worth fleshing something out just because there's a lack of consensus.
+The final resolution is not going to be a consensus decision anyway.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 11:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 11:39:04 GMT) (full text, mbox, link).

+ +

Message #4031 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve Langasek <vorlon@debian.org>, + 727708@bugs.debian.org
+
Cc: Don Armstrong <don@debian.org>
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Mon, 20 Jan 2014 11:34:35 +0000
+
+
Steve Langasek writes ("Bug#727708: Thoughts on Init System Debate"):
+> On Fri, Jan 17, 2014 at 08:41:32PM -0800, Don Armstrong wrote:
+...
+> > I should point out that I have not extensively examined openrc, nor have
+> > I taken into account planned features and development in either systemd
+> > or upstart which could sway my opinion.
+> 
+> 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.
+
+This is a very good question.
+
+Don, seriously, if there is something I could go and implement or fix
+in upstart that would convince you, that would be a lot easier and
+more fun than arguing on the internet.
+
+It might also demonstrate how easy it is to work on.  (NB at the time
+of writing I have not looked at the upstart code other than to glance
+at a couple of screenfuls' worth to estimate the code density when I
+did a wc.)
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 11:57:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 11:57:13 GMT) (full text, mbox, link).

+ +

Message #4036 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Thomas Goirand <zigo@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: The tech ctte isn't considering OpenRC at all
+
Date: Mon, 20 Jan 2014 11:56:30 +0000
+
+
Thomas Goirand writes ("Bug#727708: The tech ctte isn't considering OpenRC at all"):
+> On 01/19/2014 08:15 PM, Ian Jackson wrote:
+> >  * The daemon does not double-fork; it runs in the foreground of
+> >    of its initial process.
+> 
+> Something like start-stop-daemon then? :)
+
+Err, no, becase...
+
+> See also the command_background directive (in the man openrc-run).
+
+(http://manpages.debian.net/cgi-bin/man.cgi?query=openrc-run&apropos=0&sektion=0&manpath=Debian+experimental&format=html&locale=en
+  => Sorry, no data found for `openrc-run'.
+I dgit cloned the package from experimental and used `man -l'.
+Perhaps manpages.debian.net isn't working or hasn't updated yet.)
+
+> On 01/19/2014 08:15 PM, Ian Jackson wrote:
+> >  * The daemon's parent process (part of the init system) keeps
+> >    track of it, so the init system knows whether the process
+> >    is still running.
+> 
+> First, OpenRC isn't stateless like sysv-rc to begin with (try
+> "rc-status" to see what daemon is running). Status are kept in
+> /run/openrc/started using symlinks to /etc/init.d, and OpenRC uses
+> (optionally) cgroups to shutdown daemons, if that's what you ask.
+
+Having looked at the FM for openrc-run, no, this is not what I meant
+by a non-forking daemon startup.
+
+I meant that the long-running process's parent is some kind of
+supervisor process which will respond to information about its child's
+process lifecycle (using SIGCHLD, waitpid).  (And that the
+long-running process inherits, and does not close, a sensible stderr.)
+
+And I don't think cgroups is the right answer.
+
+> Then, the answer to this question is even more definitively "yes", if
+> you use this patch:
+> https://github.com/qnikst/openrc/compare/s-vision
+
+You're suggesting then to use monit.  Are you saying that all of the
+daemons in Debian ought to be converted to run under monit and that
+this should be the default mode of operation ?
+
+I just read the monit(1) manpage and saw this:
+
+ | Monit detaches from the console, puts itself in the background and
+ | runs continuously, monitoring each specified service and then goes
+ | to sleep for the given poll interval, wakes up and start monitoring
+ | again in an endless cycle.
+
+This is probably great for a server system monitoring setup.  But it's
+not really how an init system has to work.  Also, monit has a lot of
+functionality which has nothing to do with init system.
+
+Also I saw this in the section on service entry keywords:
+
+ | pidfile         Specify the  process pidfile. Every
+ |                 process must create a pidfile with its
+ |                 current process id. This statement should only
+ |                 be used in a process service entry.
+
+Are you _sure_ monit doesn't expect daemons to fork ?  Why does it
+need a pidfile ?
+
+> On 01/19/2014 08:15 PM, Ian Jackson wrote:
+> >  * The daemon's stderr goes somewhere reasonable.
+> 
+> Hum... By default, I honestly don't know what would be the behavior of a
+> daemon doing some output to stderr. However, I believe it'd be really
+> trivial to do in the command= statement of a runscript. Something like:
+> 
+> command="foo >/var/log/foo.log 2>&1"
+> 
+> or using the command_arg directive should be enough (I haven't tested,
+> but this seems reasonable).
+
+Oh god, please no more of this kind of thing.  My inittabs are already
+full of it and this is what I'm trying to get rid of.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 12:03:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andres Freund <andres@anarazel.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 12:03:07 GMT) (full text, mbox, link).

+ +

Message #4041 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andres Freund <andres@anarazel.de>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Cc: Don Armstrong <don@debian.org>
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Mon, 20 Jan 2014 12:50:29 +0100
+
+
On 2014-01-19 23:18:26 -0800, 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.
+
+Showing some progress on issues like
+https://bugs.launchpad.net/upstart/+bug/447654 would excite me far much
+more than promises about future features. Not fixing issues described as
+"a fundamental design flaw" by upstart's original author for several
+years, without an inkling of progress, is what's causing doubts about
+upstarts health, at least for me.
+
+Greetings,
+
+Andres Freund
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 14:03:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 14:03:12 GMT) (full text, mbox, link).

+ +

Message #4046 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: TC endorsement, political aspects
+
Date: Mon, 20 Jan 2014 13:58:36 +0000
+
+
Enrico Zini writes ("Re: GR: Selecting the default init system for Debian"):
+> On Sun, Jan 19, 2014 at 03:26:31PM +0000, Ian Jackson wrote:
+> > The main objections to some of the upstreams' behaviours are,
+> > basically, "they don't care what anyone else thinks, and are trying to
+> > impose their will by various means".  If that's the case, further
+> > imprecations aren't likely to make any difference.
+> 
+> What I had in mind was the concern that a technical choice from Debian
+> may be seen as a political endorsement, too, which may make the choice
+> much more loaded.
+
+Yes.
+
+> I would imagine that among these four options, the middle two would be
+> far less polarising:
+>  - we will use systemd, and way to go Lennart!
+>  - we will use systemd, although we are concerned about Lennart
+>  - we will use upstart, although we are concerned about Canonical
+>  - we will use upstart, and way to go Canonical!
+
+I think this is a good idea.  I have written a draft paragraph about
+the Canonical upstart CLA, in my most recent message to Keith.
+
+At the risk of feeding the horrible energy beast I think I need to try
+to propose some wording about these troublesome aspects of systemd.
+Here's a suggested text to accompany versions of the resolution which
+specify systemd as default.
+
+  N.  We are very concerned about the systemd upstream's history of
+      claiming control of wide areas of functionality.  We are also
+      worried by the vigorous adoption campaign one of whose key
+      strategies appears to be making systemd mandatory for various
+      other software, even where the benefits of such tight coupling
+      are minimal or alternative approaches such as operation with
+      reduced functionality would be entirely feasible.
+
+      In this context the systemd project's apparent lack of
+      prioritisation of the legitimate divergence of wishes and goals
+      on the part of its downstreams is especially worrying.
+
+      Our selection of systemd as default is made despite these
+      worries.  We reiterate Debian's commitment to diversity of
+      approaches and to the freedom of our downstreams and users to
+      make their own choices.
+
+The last sentence can only make sense in the context of a resolution
+supporting multiple init systems for the foreseeable future.
+
+> [feel free to quote me in public anyway you see fit; I'm replying
+> privately because I'm concerned about giving even more food to this
+> topic, which I perceive as a vast and long lasting energy drain for
+> Debian]
+
+Quite (as I said to Enrico).
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 14:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to piruthiviraj natarajan <piruthiviraj@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 14:27:04 GMT) (full text, mbox, link).

+ +

Message #4051 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: piruthiviraj natarajan <piruthiviraj@gmail.com>
+
To: 727708@bugs.debian.org
+
Date: Mon, 20 Jan 2014 19:54:59 +0530
+
+
[Message part 1 (text/plain, inline)]
+
I think people should read this from Lennart about some basic insights of
+what to look for in a Init system which has not been discussed in this
+thread.
+
+https://plus.google.com/u/0/+LennartPoetteringTheOneAndOnly/posts/ip8e1DqJdxT
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 17:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 17:45:04 GMT) (full text, mbox, link).

+ +

Message #4056 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: TC endorsement, political aspects
+
Date: Mon, 20 Jan 2014 09:40:46 -0800
+
+
Ian Jackson wrote:
+> Enrico Zini writes ("Re: GR: Selecting the default init system for Debian"):
+> > I would imagine that among these four options, the middle two would be
+> > far less polarising:
+> >  - we will use systemd, and way to go Lennart!
+> >  - we will use systemd, although we are concerned about Lennart
+> >  - we will use upstart, although we are concerned about Canonical
+> >  - we will use upstart, and way to go Canonical!
+
+All four of those seem wildly outside the TC's purview.  This list of
+options omits the two least polarising options of all:
+
+- we will use systemd
+- we will use upstart
+
+Specifying technical details of how systemd or upstart should integrate
+with Debian, where absolutely necessary (as opposed to leaving it to
+maintainer judgement) falls within the scope of a TC resolution, and
+some of that will be necessary in both of the draft resolutions (to
+specify timelines for integration in jessie and jessie+1, transition
+plans for sysvinit, etc).  However, endorsement or admonishment of
+specific package upstreams seems well outside what the TC should be
+resolving.
+
+> At the risk of feeding the horrible energy beast I think I need to try
+> to propose some wording about these troublesome aspects of systemd.
+> Here's a suggested text to accompany versions of the resolution which
+> specify systemd as default.
+> 
+>   N.  We are very concerned about the systemd upstream's history of
+>       claiming control of wide areas of functionality.  We are also
+>       worried by the vigorous adoption campaign one of whose key
+>       strategies appears to be making systemd mandatory for various
+>       other software, even where the benefits of such tight coupling
+>       are minimal or alternative approaches such as operation with
+>       reduced functionality would be entirely feasible.
+> 
+>       In this context the systemd project's apparent lack of
+>       prioritisation of the legitimate divergence of wishes and goals
+>       on the part of its downstreams is especially worrying.
+> 
+>       Our selection of systemd as default is made despite these
+>       worries.  We reiterate Debian's commitment to diversity of
+>       approaches and to the freedom of our downstreams and users to
+>       make their own choices.
+> 
+> The last sentence can only make sense in the context of a resolution
+> supporting multiple init systems for the foreseeable future.
+
+First of all, I'd like to point out the obvious problem with having
+chunks of the systemd resolution written by folks who have made it clear
+they do not favor that resolution.  It seems rather unlikely to me that
+a statement like this will suddenly change someone's vote who would
+otherwise not have voted for systemd, and it would not surprise me at
+all if someone of the folks who *do* intend to vote for systemd would
+find the above statement off-putting.
+
+This text in particular is inaccurate, and assumes bad faith on the part
+of both the systemd maintainers and systemd upstream, almost to the
+point of offensiveness.
+
+Taking it point by point:
+
+>   N.  We are very concerned about the systemd upstream's history of
+>       claiming control of wide areas of functionality.  We are also
+>       worried by the vigorous adoption campaign one of whose key
+>       strategies appears to be making systemd mandatory for various
+>       other software, even where the benefits of such tight coupling
+>       are minimal or alternative approaches such as operation with
+>       reduced functionality would be entirely feasible.
+
+- systemd upstream has not "claimed control of wide areas of
+  functionality"; it has incorporated functionality where it can provide
+  better integration with the rest of the system.  And that
+  functionality is generally provided in discrete chunks, most of which
+  are not mandatory.  If you're seeing them more widely used, perhaps
+  that's because they're *useful*.
+
+- The phrasing is such that it's not clear whether this is complaining
+  about systemd's general goal of being more widely adopted or about the
+  specific issue of increasing dependencies on systemd.  I'll assume the
+  more charitable wording, since there's absolutely nothing wrong with a
+  piece of software trying vigorously to be adopted, and this statement
+  should not imply otherwise.  For the latter point, see the next item.
+
+- Making systemd mandatory for other software is not merely a tactic
+  "vigorous adoption campaign"; whether you're willing to acknowledge it
+  or not, it's being done in cases where there are legitimate technical
+  benefits to depending on systemd and its components.  This is one of
+  the points where your proposal assumes bad faith.
+
+- If "alternative approaches such as operation with reduced
+  functionality would be entirely feasible.", feel free to write and
+  maintain those alternatives; don't expect systemd to maintain
+  alternatives to *itself* because you don't want to use systemd.  Why
+  would the systemd developers or maintainers want to do extra work to
+  encourage non-use of systemd?  I certainly wouldn't expect the upstart
+  developers to go out of their way to support systems not running
+  upstart, beyond that needed to allow smooth transitions from another
+  init system to upstart.
+
+>       In this context the systemd project's apparent lack of
+>       prioritisation of the legitimate divergence of wishes and goals
+>       on the part of its downstreams is especially worrying.
+
+Speaking as someone who has followed the development of systemd since it
+was created, the systemd maintainers have taken quite a bit of care to
+work with downstreams who have varying needs.  The components of systemd
+have accomodated areas of distribution divergence and aided in smooth
+transitions, even in areas of gratuitous divergence (e.g. distributions
+using different configuration files for the same thing).  systemd has
+tried to adopt the best technical solutions from a variety of
+distributions; for instance, using /etc/hostname from Debian and
+changing Fedora and other distributions to match.  (Lest you think
+systemd will make Debian always conform to Fedora rather than the other
+way around...)
+
+In short, systemd has put a great deal of prioritization on the needs of
+its downstreams.  And if Debian becomes one of those downstreams, I
+fully expect to see Debian's needs taken into account.  In particular,
+if Debian has a solution that works *better* than one in systemd (rather
+than just working *differently*), I'd fully expect to see systemd
+adapting to work with that solution, and potentially helping Debian
+spread that solution to other distributions as well.
+
+That said, systemd is *also* working to harmonize areas of gratuitous
+divergence in distributions, where there's no reason other than
+hysterical rasins to continue being different.  And that's a feature,
+not a bug.  In those areas, Debian ought to take part in the discussions
+about which approach to adopt, and then support a careful transition to
+that approach.  It's reasonable to expect Debian, systemd, and other
+distributions to cooperate with each other; it's not reasonable to
+expect systemd to do all the adapting, which is what the text you posted
+seems to assume.
+
+
+Now, with that spirit of future cooperation in mind, I would suggest
+something more like the following, if and only if this is deemed
+important enough to form part of the systemd resolution and the systemd
+proponents are in favor of it as well.  Also note the use of
+[non-binding advice brackets].
+
+[
+- The Technical Committee encourages Debian maintainers of systemd and
+  other packages to work with their upstreams, downstreams, and
+  counterparts in other distributions, to achieve the best possible
+  integration between systemd and Debian.  In particular, we would
+  recommend avoiding gratuitous divergences from existing Debian
+  behavior and expectations, as well as avoiding gratuitous divergences
+  from upstream systemd behavior.  In cases where the those two differ,
+  we encourage collaboration to determine the best possible solution for
+  both upstream and Debian, to provide for smooth transitions for any
+  resulting changes, and to accommodate users of other init systems
+  where reasonably possible.
+]
+
+Personally, I believe this falls in the area of "package maintainers
+should already know this and do this anyway".  However, if there's a
+consensus that the TC resolution needs to say something about this, and
+in particular if none of the TC members favoring systemd would object to
+voting for a resolution that included it, then I'd suggest something
+closer to the above as a clear statement of *cooperation*, rather than a
+demand that systemd conform to Debian (discounting the possibility that
+Debian could ever change to adopt what might be better alternatives).
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 17:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Didier 'OdyX' Raboud" <odyx@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 17:51:05 GMT) (full text, mbox, link).

+ +

Message #4061 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Didier 'OdyX' Raboud" <odyx@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Mon, 20 Jan 2014 18:47:39 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Hi Ian,
+
+Le lundi, 20 janvier 2014, 11.34:35 Ian Jackson a écrit :
+> Don, seriously, if there is something I could go and implement or fix
+> in upstart that would convince you, that would be a lot easier and
+> more fun than arguing on the internet.
+> 
+> It might also demonstrate how easy it is to work on.
+
+If technical committee members begin to race on feature parity by 
+getting involved with the code themselves in order to influence the 
+others' opinions [0], then it feels to me that we're really out of facts 
+to discuss about and that it's probably time to stop rehashing the 
+arguments in circles and lean towards getting this difficult decision 
+voted upon and decided.
+
+At this point, it appears (to me) from the (awfully long) bug thread 
+that the members' positions have matured with lots of work behind them 
+and are therefore quite unlikely to change. Therefore, the next uphill 
+challenge is to get to an uncontroversial ballot which would allow this 
+decision-process to end; certainly not more attempts at convincing 
+others that one's camp is right (or the other one's wrong by all means).
+
+Now, it is certainly a very hard decision for the technical committee to 
+take, but as consensus will not emerge, the only way to take that 
+decision is to resort to vote.
+
+Cheers,
+
+OdyX
+
+[0] "If you disagree with the choice of A because it has feature B
+     missing, let me take N hours to implement it! Now you can't
+     disagree with A anymore, so we have a majority for A"
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 20 Jan 2014 18:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 20 Jan 2014 18:33:04 GMT) (full text, mbox, link).

+ +

Message #4066 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Cc: Keith Packard <keithp@keithp.com>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Mon, 20 Jan 2014 19:30:15 +0100
+
+
* Ian Jackson (ijackson@chiark.greenend.org.uk) [140120 12:27]:
+> Keith Packard writes ("Re: Bug#727708: init system discussion status"):
+> > I feel that having the Debian community endorse software where a CLA is
+> > involved will tacitly encourage developers to enter into those
+> > agreements so that their work can be published as widely as possible.
+> 
+> I can see the force of this point.
+> 
+> Could we address this by adding something explicit to the TC
+> resolution ?
+> 
+>   N. We are firmly opposed to Canonical's upstart Contributor Licence
+>      Agreement.
+> 
+>      As with any other program in Debian whose upstream has
+>      controversial copyright practices, the Debian project will
+>      continue accept and deploy useful patches whose contributors
+>      decline to enter into unfair copyright agreements.
+> 
+>      We recommend that Debian contributors do not sign the CLA, even
+>      when contributing changes which might be widely useful.
+
+Though I personally agree with all those sentences I think for an
+official tech ctte resolution I prefer to not have the last sentence
+there (or move the "not" in front of "recommend", because that's not
+as active as that).
+
+Perhaps something as: "We do not endorse the use of licenses such as
+CLA, even if the software as distributed by Debian is Free Software
+and can be distributed and modified as usual." (or so).
+
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 21 Jan 2014 00:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 21 Jan 2014 00:33:05 GMT) (full text, mbox, link).

+ +

Message #4071 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Cc: Keith Packard <keithp@keithp.com>
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Mon, 20 Jan 2014 16:28:01 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Jan 20, 2014 at 11:23:39AM +0000, Ian Jackson wrote:
+> Keith Packard writes ("Re: Bug#727708: init system discussion status"):
+> > I feel that having the Debian community endorse software where a CLA is
+> > involved will tacitly encourage developers to enter into those
+> > agreements so that their work can be published as widely as possible.
+
+> I can see the force of this point.
+
+> Could we address this by adding something explicit to the TC
+> resolution ?
+
+>   N. We are firmly opposed to Canonical's upstart Contributor Licence
+>      Agreement.
+
+>      As with any other program in Debian whose upstream has
+>      controversial copyright practices, the Debian project will
+>      continue accept and deploy useful patches whose contributors
+>      decline to enter into unfair copyright agreements.
+
+>      We recommend that Debian contributors do not sign the CLA, even
+>      when contributing changes which might be widely useful.
+
+I would prefer to see more neutral wording, something to the effect of:
+
+      The Technical Committee does not endorse the use of a CLA by the
+      upstart project, which causes barriers to contributions from the wider
+      Free Software community, and this decision is not a recommendation
+      that Debian contributors sign the CLA.
+
+I.e., rather than a positive recommendation to contributors about what
+licensing agreements they should choose to engage in (which I don't think
+it's the TC's place to do), a softer call-out to make it clear that this is
+not an endorsement of CLAs.
+
+But perhaps this doesn't satisfy Keith's concern.  (Perhaps neither wording
+does.)
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 21 Jan 2014 01:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 21 Jan 2014 01:12:05 GMT) (full text, mbox, link).

+ +

Message #4076 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Steve Langasek <vorlon@debian.org>, Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Mon, 20 Jan 2014 17:08:33 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Steve Langasek <vorlon@debian.org> writes:
+
+> I would prefer to see more neutral wording, something to the effect
+> of:
+
+I didn't mean that the TC decision should mention the CLA. I don't think
+that's an appropriate place for this kind of statement.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 21 Jan 2014 02:18:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 21 Jan 2014 02:18:10 GMT) (full text, mbox, link).

+ +

Message #4081 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Thomas Goirand <zigo@debian.org>
+
Subject: Re: Bug#727708: The tech ctte isn't considering OpenRC at all
+
Date: Mon, 20 Jan 2014 18:15:18 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Nikolaus Rath writes ("Bug#727708: The tech ctte isn't considering OpenRC at all"):
+>> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+>> > Thomas, does OpenRC provide a means for do non-forking daemon
+>> > startup ?
+>> [...]
+>> 
+>> Ian, quoting from your previous evaluation of upstart
+>> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1499):
+> ...
+>> I don't see how this is consistent with what you say about
+>> OpenRC. Either the lack of features isn't a problem if they can in
+>> principle be implemented in the future (in that case, upstart and OpenRC
+>> are both viable candidates), or hypothetical features do not matter (in
+>> that case this should also hold for upstart).
+>
+> Firstly, non-forking daemon startup and supervision is less of a
+> feature and more of a design decision.  I think that doing it from
+> scratch in a system which doesn't have it at all involves a lot of
+> design decisions and a fair amount of programming work.
+>
+> Secondly, the features I list as missing for upstart are not IMO
+> anywhere near as important.
+
+I see, thanks for the clarification. To me implementing non-forking
+startup in OpenRC seems about the same amount of work as implementing
+systemd-style socket activation in upstart. 
+
+> If you think OpenRC will soon have non-forking daemon startup, then
+> excellent.  Can you explain to me how it will work ?
+
+I don't think OpenRC is a good candidate for the default init and I
+don't know about any plans to implement non-forking startup, so I'd
+rather not do that. My actual goal was to have you reconsider the weight
+you put on not-yet-implemented-but-easy-to-do features in upstart :-).
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 21 Jan 2014 03:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 21 Jan 2014 03:12:05 GMT) (full text, mbox, link).

+ +

Message #4086 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Andres Freund <andres@anarazel.de>
+
Cc: 727708@bugs.debian.org, Steve Langasek <vorlon@debian.org>, Don Armstrong <don@debian.org>
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Mon, 20 Jan 2014 19:09:51 -0800
+
+
Andres Freund <andres@anarazel.de> writes:
+> On 2014-01-19 23:18:26 -0800, 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.
+>
+> Showing some progress on issues like
+> https://bugs.launchpad.net/upstart/+bug/447654 would excite me far
+> much more than promises about future features. Not fixing issues
+> described as "a fundamental design flaw" by upstart's original author
+> for several years, without an inkling of progress, is what's causing
+> doubts about upstarts health, at least for me.
+
+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), yet the mountall
+manpage still says
+
+       This  is  a  temporary  tool  until  init(8) itself gains the necessary
+       flexibility to perform this processing; you  should  not  rely  on  its
+       behaviour.
+
+Yet no replacement is in sight even after more than 5 years.
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 21 Jan 2014 04:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 21 Jan 2014 04:18:04 GMT) (full text, mbox, link).

+ +

Message #4091 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC endorsement, political aspects
+
Date: Mon, 20 Jan 2014 21:15:11 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I think this is a good idea.  I have written a draft paragraph about
+> the Canonical upstart CLA, in my most recent message to Keith.
+>
+> At the risk of feeding the horrible energy beast I think I need to try
+> to propose some wording about these troublesome aspects of systemd.
+
+I'm not convinced that either of these belong in a formal TC decision.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 21 Jan 2014 04:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 21 Jan 2014 04:57:04 GMT) (full text, mbox, link).

+ +

Message #4096 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Andres Freund <andres@anarazel.de>, 727708@bugs.debian.org, + Don Armstrong <don@debian.org>
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Mon, 20 Jan 2014 20:53:14 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Jan 20, 2014 at 07:09:51PM -0800, Nikolaus Rath wrote:
+> Andres Freund <andres@anarazel.de> writes:
+> > On 2014-01-19 23:18:26 -0800, 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.
+
+> > Showing some progress on issues like
+> > https://bugs.launchpad.net/upstart/+bug/447654 would excite me far
+> > much more than promises about future features. Not fixing issues
+> > described as "a fundamental design flaw" by upstart's original author
+> > for several years, without an inkling of progress, is what's causing
+> > doubts about upstarts health, at least for me.
+
+> 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.
+
+If members of the TC feel this is worthy of further discussion, I will
+elaborate; but I suspect this isn't likely to be a major point of interest
+that would sway anyone in either direction, so won't spend the effort on it
+if there's no need.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 21 Jan 2014 08:27:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to David Balch <david@balch.co.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 21 Jan 2014 08:27:08 GMT) (full text, mbox, link).

+ +

Message #4101 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: David Balch <david@balch.co.uk>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: Don Armstrong <don@debian.org>, 727708@bugs.debian.org, + Andres Freund <andres@anarazel.de>
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Tue, 21 Jan 2014 08:26:12 +0000
+
+
[Message part 1 (text/plain, inline)]
+
On 21 Jan 2014 04:57, "Steve Langasek" <vorlon@debian.org> 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 <https://plus.google.com/+KaySievers/posts/C3chC26khpq#z13jjz3zyofuv3122230ufubgwvfv1myv04#1390263990323502>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.
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 21 Jan 2014 11:58:43 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Matthias Urlichs <matthias@urlichs.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 21 Jan 2014 11:58:43 GMT) (full text, mbox, link).

+ +

Message #4106 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Matthias Urlichs <matthias@urlichs.de>
+
To: 727708@bugs.debian.org
+
Subject: upstadt vs. systemd: events vs. dependencies
+
Date: Tue, 21 Jan 2014 12:27:01 +0100
+
+
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
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 21 Jan 2014 13:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Lucas Nussbaum <lucas@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 21 Jan 2014 13:06:04 GMT) (full text, mbox, link).

+ +

Message #4111 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Lucas Nussbaum <lucas@debian.org>
+
To: Matthias Urlichs <matthias@urlichs.de>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstadt vs. systemd: events vs. dependencies
+
Date: Tue, 21 Jan 2014 14:00:30 +0100
+
+
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.GA23897@riva.ucam.org (search for
+"event")
+the subthread starting with
+http://lists.debian.org/87sit9puow.fsf@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.50c8@mx.google.com
+and
+http://lists.debian.Org/CAJS_LCUGaM6JS8Ec-73z30+_h8yW+HqSqfqVvHVh=ykPqn+XQw@mail.gmail.com (and its sub-thread)
+
+Also, http://lists.debian.org/7y52zuuaw.fsf@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
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 21 Jan 2014 17:27:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 21 Jan 2014 17:27:08 GMT) (full text, mbox, link).

+ +

Message #4116 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Wed, 22 Jan 2014 03:23:32 +1000
+
+
On 20 January 2014 14:29, Russ Allbery <rra@debian.org> wrote:
+> Steve Langasek <vorlon@debian.org> 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% satisfy me personally, and I think they're
+pretty minimally controversial ideas? YMMV. 100% is an approximation.
+
+I think given all the discussion, providing some specific /advice/ on
+how to go forward beyond "hey, X wins!" is a good idea and not too
+prescriptive. YMMV, again, obviously. The above are the things I think
+are important and valid issues to address based on the discussion I've
+seen; and I don't think the advice above would actually be terribly
+controversial. YMMV on that too, of course.
+
+Comparing with Ian's draft in in the tech-ctte git:
+ - non-Linux ports is left up in the air
+ - requiring sysvinit scripts and whether that's an RC bug or not is
+left as someone-else's-problem as part of [init-minimal-compatability]
+ - depending on a specific init is left to maintainer's discretion;
+modulo patches/NMUs
+ - providing native support is left up in the air; modulo patches/NMUs
+ - my "reasonable" test for patches is more restrictive -- if upstream
+don't accept code changes, the maintainer can consider it unreasonable
+ - [7-11] in Ian's proposal seem "prescriptive" to me, so aren't
+addressed in the above for that reason
+
+Again, YMMV, FWIW etc. It seemed an interesting intellectual exercise
+to make it less prescriptive, and I think the result's somewhat
+interesting. Feel free to build on it, tear it apart or ignore it as
+appropriate. :)
+
+Cheers,
+aj
+
+-- 
+Anthony Towns <aj@erisian.com.au>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 21 Jan 2014 18:09:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 21 Jan 2014 18:09:09 GMT) (full text, mbox, link).

+ +

Message #4121 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: Anthony Towns <aj@erisian.com.au>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>, debian-bugs-dist@lists.debian.org, + Technical Committee <debian-ctte@lists.debian.org>
+
Subject: Re: Bug#727708: On diversity
+
Date: Tue, 21 Jan 2014 18:04:04 +0000 (UTC)
+
+
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
+-- 
+<Natureshadow> Warum ist MirWebseite eigentlich so cool?  <mirabilos> weil ich
+ich sie geschrieben habe  <Natureshadow> Hast du sie geschrieben oder geforkt?
+<mirabilos> geschrieben, from scratch  <Natureshadow> Ach, deshalb finde ich
+auch so selten Bugs dadrin. Irgendwie hast du Recht.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 21 Jan 2014 18:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 21 Jan 2014 18:51:04 GMT) (full text, mbox, link).

+ +

Message #4126 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org, + Philipp Kern <pkern@debian.org>, + Thorsten Glaser <tg@mirbsd.de>
+
Subject: Re: Bug#727708: On diversity
+
Date: Tue, 21 Jan 2014 18:49:57 +0000
+
+
(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.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 21 Jan 2014 21:24:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 21 Jan 2014 21:24:10 GMT) (full text, mbox, link).

+ +

Message #4131 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Tue, 21 Jan 2014 13:21:54 -0800
+
+
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
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 21 Jan 2014 21:27:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 21 Jan 2014 21:27:05 GMT) (full text, mbox, link).

+ +

Message #4136 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts on Init System Debate
+
Date: Tue, 21 Jan 2014 13:25:22 -0800
+
+
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"
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 22 Jan 2014 08:39:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Vincent Bernat <bernat@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 22 Jan 2014 08:39:05 GMT) (full text, mbox, link).

+ +

Message #4141 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Vincent Bernat <bernat@debian.org>
+
To: Lucas Nussbaum <lucas@debian.org>
+
Cc: Matthias Urlichs <matthias@urlichs.de>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: upstadt vs. systemd: events vs. dependencies
+
Date: Wed, 22 Jan 2014 09:36:50 +0100
+
+
[Message part 1 (text/plain, inline)]
+
 ❦ 21 janvier 2014 14:00 CET, Lucas Nussbaum <lucas@debian.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". :-)
+
+The fact that Upstart's proponents didn't outline important bugs in
+Upstart may also been seen as "one aspect didn't get the attention it
+should get". In the different final positions of the TC in favor of
+Upstart, we don't see mentions of those important bugs:
+
+ https://bugs.launchpad.net/upstart/+bug/516713
+ https://bugs.launchpad.net/upstart/+bug/447654
+ https://bugs.launchpad.net/upstart/+bug/406397
+
+As Matthias, I wanted to point those out since a long time: how can we
+choose Upstart when there are critical bugs that remain unfixed for
+years?
+
+I particularly hate the last one that bite me several times: you make
+one mistake ("expect fork" instead of "expect daemon") and you need to
+either reboot your system or know this script:
+
+ https://github.com/ion1/workaround-upstart-snafu
+
+Colin proposed to never use "expect fork" and "expect daemon", but they
+exist and our users will write Upstart jobs to start their scripts,
+daemons, workers, etc.
+-- 
+ /* Am I fucking pedantic or what? */
+	2.2.16 /usr/src/linux/drivers/scsi/qlogicpti.h
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 22 Jan 2014 09:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 22 Jan 2014 09:21:04 GMT) (full text, mbox, link).

+ +

Message #4146 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: Vincent Bernat <bernat@debian.org>, 727708@bugs.debian.org
+
Cc: Lucas Nussbaum <lucas@debian.org>, + Matthias Urlichs <matthias@urlichs.de>
+
Subject: Re: Bug#727708: upstadt vs. systemd: events vs. dependencies
+
Date: Wed, 22 Jan 2014 09:17:59 +0000
+
+
On Wed, Jan 22, 2014 at 09:36:50AM +0100, Vincent Bernat wrote:
+> I particularly hate the last one that bite me several times: you make
+> one mistake ("expect fork" instead of "expect daemon") and you need to
+> either reboot your system or know this script:
+> 
+>  https://github.com/ion1/workaround-upstart-snafu
+> 
+> Colin proposed to never use "expect fork" and "expect daemon", but they
+> exist and our users will write Upstart jobs to start their scripts,
+> daemons, workers, etc.
+
+Allow me to elaborate slightly: my preference here would be to change
+all existing jobs so that those two expect verbs are no longer needed,
+and then compile them entirely out of Upstart.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 23 Jan 2014 01:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 23 Jan 2014 01:57:04 GMT) (full text, mbox, link).

+ +

Message #4151 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Thu, 23 Jan 2014 03:54:38 +0200
+
+
On Thu, 2014-01-16 at 17:00 -0800, Russ Allbery wrote:
+> Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
+> > I think the divergence has gone too far in things like non-Linux ports.
+> > They have had an overall negative effect on people working on Linux
+> > within Debian and people creating derivatives.
+> 
+> I have to take exception to this.  There has been a great deal of
+> *concern* from people over the past two years that the non-Linux ports
+> *might* have a negative effect on Linux in the context of this particular
+> discussion.
+
+I consider the effect on the init system decision process so far to
+already be an example of actual negative effects. Even if it does not
+ultimately lead to an inferior system being chosen for Linux (which
+would be a major harm), the portion of discussion that has been about
+non-Linux ports has been completely out of proportion compared to their
+potential benefit/importance, has made the decision process harder, and
+has made it more difficult for anyone else to follow the discussion or
+form an informed opinion based on it.
+
+>   But, in the meantime, the non-Linux porters have been
+> first-class Debian contributors over the years.  They have not
+> substantially gotten in the way of Debian's processes, certainly no more
+> than any Linux port to a more obscure architecture,
+
+I don't have any numbers, but I would be surprised if that "no more
+than" were true. The kernel and compiler already abstract away most of
+hardware differences, and ignoring toolchain issues, I'd expect most of
+hardware-specific failures to be things that could be considered general
+bugs in the software even on platforms where it works. By comparison,
+changes required by kernel differences are generally not positive on
+other platforms.
+
+>  and they have
+> contributed a great many improvements to our software.
+> 
+> For example, I think special thanks should go to the Hurd porters for
+> extended, thankless work on removing static buffers from the code in the
+> archive.  They were doing so because some of the constants used to size
+> those buffers are not portable to the Hurd, but using static buffers to
+> store paths and related strings is often incorrect regardless of its
+> portability, and can even be a security issue depending on how the code is
+> written.  The Hurd porters have provided reasonable patches that can go
+> back to upstream and result in objectively more robust software.  I have
+
+Those are probably among the most useful patches, but I think they're
+still very minor, and not worth the maintainer work adding distro-
+specific patches in Debian (as opposed to letting it become part of
+upstream code). Most changes will not be useful on other kernels.
+
+There are also other costs. For example, kFreeBSD issues have prevented
+testing migration of packages. Even if systemd is chosen as Linux init,
+will everyone packaging daemons or other software interacting with init
+for Debian be expected to remember guidelines or even do things
+differently because of issues that only matter for non-Linux?
+
+"zgrep -i kfreebsd /usr/share/doc/*/changelog.Debian.gz" shows over 1000
+different matches just on this machine. Of course some of those packages
+could be maintained by people who personally really wanted to work on
+kFreeBSD regardless of its value, but I doubt the majority is. IMO
+justifying that amount of work, and claiming that kFreeBSD has not had a
+negative effect, requires showing some concrete benefit.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 23 Jan 2014 02:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 23 Jan 2014 02:15:04 GMT) (full text, mbox, link).

+ +

Message #4156 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: On diversity
+
Date: Wed, 22 Jan 2014 18:10:07 -0800
+
+
Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
+
+> I consider the effect on the init system decision process so far to
+> already be an example of actual negative effects.
+
+Fair enough.  You're certainly entitled to your opinion.  I don't agree
+with you, and I think it's unlikely either of us are going to change each
+other's mind, on this or on the other points you mention.
+
+I would really appreciate it if you would stop reiterating your position
+on non-Linux ports in this bug, though.  I think everyone who has read
+either this mailing list or debian-devel is, at this point, well aware of
+your position, and has heard all of your arguments.  Restating them just
+provokes more argument, none of which has any possibility of changing
+anyone's mind, and hence is simply noise from the perspective of this
+discussion.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 25 Jan 2014 17:57:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 25 Jan 2014 17:57:09 GMT) (full text, mbox, link).

+ +

Message #4161 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Anthony Towns <aj@erisian.com.au>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: On diversity
+
Date: Sat, 25 Jan 2014 19:52:20 +0200
+
+
On Wed, Jan 22, 2014 at 03:23:32AM +1000, Anthony Towns wrote:
+>...
+>   [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.
+>...
+>   [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.
+>...
+
+IMHO in init-crossgrades the "init systems other than the default should"
+has to be replaced with "all init systems have to".
+
+Not being able to switch away from the default init system (that you are 
+e.g. getting with a fresh installation) would completely undermine your 
+goal of allowing users to easily switch init systems.
+
+And "should" sounds too optional - if "switching init systems" is 
+considered important, then that has to be a requirement for any
+init system for being shipped in a release.
+
+> Cheers,
+> aj
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 25 Jan 2014 21:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to svante.signell@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 25 Jan 2014 21:45:04 GMT) (full text, mbox, link).

+ +

Message #4166 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Svante Signell <svante.signell@gmail.com>
+
To: 727708@bugs.debian.org
+
Cc: debian-devel <debian-devel@lists.debian.org>
+
Subject: openrc: Updated patches making openrc work properly on Debian + GNU/Hurd
+
Date: Sat, 25 Jan 2014 22:44:14 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Whatever you have decided about Linux only, this is relevant
+information. Debian is about versatility in the Unix/Posix way, not any
+proprietary locked-in thing. If you continue this track Debian will no
+longer be a "Universal operating system". And users will choose to go
+for a FREE SOFTWARE solution (not a locked-in one)!
+
+Package: openrc
+Version: 0.12.4+20131230-7
+Severity: important
+Tags: patch
+Usertags: hurd
+
+Hi, the recent patches 0100-GNU-Hurd_PATH_MAX_and_defined.patch and
+0110-GNU-Hurd_add-missing-files.patch enables a successful build of
+openrc for GNU/Hurd. However, to make it work properly 0110-* has to be
+modified, and #721917 to be applied! Attached is an updated patch of 
+0110-GNU-Hurd_add-missing-files.patch.
+
+Of course some minor things, like mount parameters still has to be
+modified, but the basic functionality is there :)
+
+Thanks!
+
+
+
[0110-GNU-Hurd_add-missing-files.patch (text/x-patch, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 26 Jan 2014 02:30:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to md@Linux.IT (Marco d'Itri):
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 26 Jan 2014 02:30:14 GMT) (full text, mbox, link).

+ +

Message #4171 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: md@Linux.IT (Marco d'Itri)
+
Cc: 727708@bugs.debian.org, debian-devel <debian-devel@lists.debian.org>
+
Subject: Re: openrc: Updated patches making openrc work properly on Debian + GNU/Hurd
+
Date: Sun, 26 Jan 2014 03:29:28 +0100
+
+
[Message part 1 (text/plain, inline)]
+
On Jan 25, Svante Signell <svante.signell@gmail.com> wrote:
+
+> Whatever you have decided about Linux only, this is relevant
+> information. Debian is about versatility in the Unix/Posix way, not any
+No, it's not. Next.
+
+-- 
+ciao,
+Marco
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 26 Jan 2014 03:12:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to piruthiviraj natarajan <piruthiviraj@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 26 Jan 2014 03:12:10 GMT) (full text, mbox, link).

+ +

Message #4176 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: piruthiviraj natarajan <piruthiviraj@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: linux is not about choice
+
Date: Sun, 26 Jan 2014 08:39:01 +0530
+
+
[Message part 1 (text/plain, inline)]
+
This thing about 'Linux/Debian is all about choice' reminds me of the
+famous post I read in the past about choice.
+
+http://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 26 Jan 2014 16:42:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 26 Jan 2014 16:42:05 GMT) (full text, mbox, link).

+ +

Message #4181 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: piruthiviraj natarajan <piruthiviraj@gmail.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: linux is not about choice
+
Date: Sun, 26 Jan 2014 16:27:15 +0000 (UTC)
+
+
piruthiviraj natarajan dixit:
+
+>This thing about 'Linux/Debian is all about choice' reminds me of the
+>famous post I read in the past about choice.
+>
+>http://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html
+
+That is about Fedora, and about Linux, but *not* about Debian.
+
+Debian only has got so far *because* it allows everyone to choose
+which software to use for a particular task, be it editor or desktop
+environment or, as there was a famous joke, some particular implementa‐
+tion of a multi-port serial controller something.
+
+bye,
+//mirabilos
+-- 
+<Natureshadow> Warum ist MirWebseite eigentlich so cool?  <mirabilos> weil ich
+ich sie geschrieben habe  <Natureshadow> Hast du sie geschrieben oder geforkt?
+<mirabilos> geschrieben, from scratch  <Natureshadow> Ach, deshalb finde ich
+auch so selten Bugs dadrin. Irgendwie hast du Recht.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 26 Jan 2014 20:24:21 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Pouar <thepouar@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 26 Jan 2014 20:24:21 GMT) (full text, mbox, link).

+ +

Message #4186 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Pouar <thepouar@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Go with Upstart
+
Date: Sun, 26 Jan 2014 14:23:02 -0600
+
+
[Message part 1 (text/plain, inline)]
+
Actually systemd might be better than upstart.
+-- 
+Pouar
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 27 Jan 2014 16:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 27 Jan 2014 16:54:04 GMT) (full text, mbox, link).

+ +

Message #4191 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: init system gr override - formal resolution proposal
+
Date: Mon, 27 Jan 2014 16:52:12 +0000
+
+
I hereby propose the following resolution:
+
+  1. The Technical Committee does not wish any resolutions it passes
+     about the init system question(s) to stand in the face of any
+     contrary view expressed by a majority of the Developers in a
+     General Resolution.
+
+  2. Accordingly, all TC decisions (past and future) related to init
+     systems, which do not specify otherwise, should be read as
+     including the following rider:
+       | This decision is automatically vacated by any contrary
+       | General Resolution which passes by a simple majority.
+       | In that case the General Resolution takes effect and
+       | the whole of this decision is to be taken as withdrawn by the
+       | TC (i.e. as if the TC had explicitly withdrawn it by a
+       | subsequent TC resolution).
+
+Please send comments, or formal amendment proposals, by 2014-01-28
+17:00 UTC.  I will call a vote on some version(s) then.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 27 Jan 2014 16:54:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 27 Jan 2014 16:54:07 GMT) (full text, mbox, link).

+ +

Message #4196 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Mon, 27 Jan 2014 16:52:34 +0000
+
+
Bdale Garbee writes ("Re: call for votes on default Linux init system for jessie"):
+> For the same reason that I didn't include the GR over-ride.  I don't
+> think of this as the final word on the issue.
+
+I find this deeply unconvincing.  I am very disappointed that you
+haven't changed your mind on pressing on with this vote.
+
+I guess it falls to me to act unilaterally too.
+
+>  That bug log has already
+> become quite long.  Clearly the result of this ballot should be at least
+> referenced there.
+
+I don't think that's good enough.
+
+> I'll mention that it was pointed out to me on IRC that some people might
+> be tracking the issue by subscribing to the bug in the BTS, which I
+> just didn't think about.
+
+Quite!
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 27 Jan 2014 17:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 27 Jan 2014 17:03:04 GMT) (full text, mbox, link).

+ +

Message #4201 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: multiple init systems - formal resolution proposal
+
Date: Mon, 27 Jan 2014 16:59:03 +0000
+
+
I hereby propose the following resolution:
+
+   1. Support for sysvinit is mandatory in jessie.
+
+   2. Debian intends to support multiple init systems, for the
+      foreseeable future, and so long as their respective communities
+      and code remain healthy.  Nothing outside of an init system's
+      implementation may require a specific init system to be pid 1.
+
+Please send comments, or formal amendment proposals, by 2014-01-28
+17:00 UTC.  I will call a vote on some version(s) then.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 27 Jan 2014 17:09:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 27 Jan 2014 17:09:09 GMT) (full text, mbox, link).

+ +

Message #4206 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: multiple init systems - formal resolution proposal
+
Date: Mon, 27 Jan 2014 17:04:00 +0000
+
+
Ian Jackson writes ("multiple init systems - formal resolution proposal"):
+> I hereby propose the following resolution:
+> 
+>    1. Support for sysvinit is mandatory in jessie.
+> 
+>    2. Debian intends to support multiple init systems, for the
+>       foreseeable future, and so long as their respective communities
+>       and code remain healthy.  Nothing outside of an init system's
+>       implementation may require a specific init system to be pid 1.
+> 
+> Please send comments, or formal amendment proposals, by 2014-01-28
+> 17:00 UTC.  I will call a vote on some version(s) then.
+
+I would like to make a procedural comment here.  I think it is rather
+wrong to be voting on the interlinked questions of support for
+multiple systems, and what the default should be, in separate
+resolutions.  TC members should have the ability to rank "only X"
+against "X and others" in a different order to "only Y" vs "Y and
+others".
+
+However, Bdale's approach has meant that this is the only way forward
+for me.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 27 Jan 2014 17:30:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 27 Jan 2014 17:30:15 GMT) (full text, mbox, link).

+ +

Message #4211 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Mon, 27 Jan 2014 09:17:52 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I hereby propose the following resolution:
+
+>    1. Support for sysvinit is mandatory in jessie.
+
+I agree with this in principle, but I think this loses quite a bit of
+nuance and is likely, phrased in that way, to be used as a stick to beat
+maintainers with in ways that aren't helpful.  I'd rather wait until we
+decide what the default will be and then try to work out exactly what sort
+of sysvinit support we want given that.  The details of any future support
+plan are going to vary.
+
+>    2. Debian intends to support multiple init systems, for the
+>       foreseeable future, and so long as their respective communities
+>       and code remain healthy.  Nothing outside of an init system's
+>       implementation may require a specific init system to be pid 1.
+
+I will probably be voting against this.  I don't think it makes sense to
+constrain what we put in the archive in quite this way, as was previously
+discussed on this bug.  If some piece of software has no upstream support
+for other init systems, I would rather have that software packaged for the
+init system that it does support than not permitted to be in Debian at
+all.
+
+Major packages or packages with higher than optional priority are possibly
+another matter, as possibly are packages which work fine with other init
+systems but whose maintainers don't want to add support, but I think
+making this sort of flat statement is too constraining.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 27 Jan 2014 17:33:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 27 Jan 2014 17:33:09 GMT) (full text, mbox, link).

+ +

Message #4216 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Mon, 27 Jan 2014 17:32:08 +0000
+
+
Russ Allbery writes ("Bug#727708: multiple init systems - formal resolution proposal"):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > I hereby propose the following resolution:
+> >    1. Support for sysvinit is mandatory in jessie.
+> 
+> I agree with this in principle, but I think this loses quite a bit of
+> nuance and is likely, phrased in that way, to be used as a stick to beat
+> maintainers with in ways that aren't helpful.  I'd rather wait until we
+> decide what the default will be and then try to work out exactly what sort
+> of sysvinit support we want given that.  The details of any future support
+> plan are going to vary.
+
+I am not willing to wait.  I think it is too important to make this
+clear right away.  Otherwise the main default decision risks a
+stampede to create "facts on the ground".
+
+> >    2. Debian intends to support multiple init systems, for the
+> >       foreseeable future, and so long as their respective communities
+> >       and code remain healthy.  Nothing outside of an init system's
+> >       implementation may require a specific init system to be pid 1.
+> 
+> I will probably be voting against this.  [...]
+
+I take it then that you have no wording changes which would change
+your mind.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 27 Jan 2014 17:39:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 27 Jan 2014 17:39:11 GMT) (full text, mbox, link).

+ +

Message #4221 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Mon, 27 Jan 2014 18:35:34 +0100
+
+
Le lundi 27 janvier 2014 à 16:59 +0000, Ian Jackson a écrit : 
+> I hereby propose the following resolution:
+> 
+>    1. Support for sysvinit is mandatory in jessie.
+> 
+>    2. Debian intends to support multiple init systems, for the
+>       foreseeable future, and so long as their respective communities
+>       and code remain healthy.  Nothing outside of an init system's
+>       implementation may require a specific init system to be pid 1.
+
+Since this resolution would override the will of each maintainer to make
+his package depend on whatever init system the software depends on, it
+requires a 3:1 majority according to Constitution §6.1.4.
+
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 27 Jan 2014 17:39:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 27 Jan 2014 17:39:15 GMT) (full text, mbox, link).

+ +

Message #4226 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Mon, 27 Jan 2014 09:36:07 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Russ Allbery writes:
+
+>>>    2. Debian intends to support multiple init systems, for the
+>>>       foreseeable future, and so long as their respective communities
+>>>       and code remain healthy.  Nothing outside of an init system's
+>>>       implementation may require a specific init system to be pid 1.
+
+>> I will probably be voting against this.  [...]
+
+> I take it then that you have no wording changes which would change
+> your mind.
+
+Not on point 2, no.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 27 Jan 2014 17:51:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 27 Jan 2014 17:51:07 GMT) (full text, mbox, link).

+ +

Message #4231 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Josselin Mouette <joss@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Mon, 27 Jan 2014 17:48:26 +0000
+
+
Josselin Mouette writes ("Bug#727708: multiple init systems - formal resolution proposal"):
+> Le lundi 27 janvier 2014 à 16:59 +0000, Ian Jackson a écrit : 
+> > I hereby propose the following resolution:
+> > 
+> >    1. Support for sysvinit is mandatory in jessie.
+> > 
+> >    2. Debian intends to support multiple init systems, for the
+> >       foreseeable future, and so long as their respective communities
+> >       and code remain healthy.  Nothing outside of an init system's
+> >       implementation may require a specific init system to be pid 1.
+> 
+> Since this resolution would override the will of each maintainer to make
+> his package depend on whatever init system the software depends on, it
+> requires a 3:1 majority according to Constitution §6.1.4.
+
+No, because this is exercising our power to set technical policy,
+6.1.1.  I will send an updated version.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 27 Jan 2014 17:57:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 27 Jan 2014 17:57:10 GMT) (full text, mbox, link).

+ +

Message #4236 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Mon, 27 Jan 2014 17:53:25 +0000
+
+
Ian Jackson writes ("Bug#727708: multiple init systems - formal resolution proposal"):
+> I hereby propose the following resolution:
+> 
+>    1. Support for sysvinit is mandatory in jessie.
+
+I hereby propose and accept an amendment to add a new rubric paragraph
+0, and I also propose and do NOT accept an amendment to delete
+paragraph 2, so as to result in the following proposal:
+
+ == both versions ==
+
+   0. We exercise our power to set policy, Constitution 6.1.1:
+
+   1. Support for sysvinit is mandatory in jessie.
+
+ == version "multiple" only ==
+
+   2. Debian intends to support multiple init systems, for the
+      foreseeable future, and so long as their respective communities
+      and code remain healthy.  Nothing outside of an init system's
+      implementation may require a specific init system to be pid 1.
+
+ == resolution proposal ends ==
+
+I'm expecting, although I have left it unsaid, that the policy
+maintainers would implement this by writing suitable specific wording
+in the policy manual.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 27 Jan 2014 17:57:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 27 Jan 2014 17:57:13 GMT) (full text, mbox, link).

+ +

Message #4241 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Mon, 27 Jan 2014 18:54:52 +0100
+
+
Le lundi 27 janvier 2014 à 17:48 +0000, Ian Jackson a écrit : 
+> Josselin Mouette writes ("Bug#727708: multiple init systems - formal resolution proposal"):
+> > Since this resolution would override the will of each maintainer to make
+> > his package depend on whatever init system the software depends on, it
+> > requires a 3:1 majority according to Constitution §6.1.4.
+> 
+> No, because this is exercising our power to set technical policy,
+> 6.1.1.  I will send an updated version.
+
+Oh well, you can of course add non-implementable clauses to the policy.
+But I trust the release team to accept the necessary exceptions for the
+system to actually work.
+
+In which case, if you wish to override them at that point, it will
+require a 3:1 majority.
+
+kthxbye,
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 27 Jan 2014 22:51:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 27 Jan 2014 22:51:11 GMT) (full text, mbox, link).

+ +

Message #4246 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system gr override - formal resolution proposal
+
Date: Mon, 27 Jan 2014 15:48:44 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I hereby propose the following resolution:
+>
+>   1. The Technical Committee does not wish any resolutions it passes
+>      about the init system question(s) to stand in the face of any
+>      contrary view expressed by a majority of the Developers in a
+>      General Resolution.
+>
+>   2. Accordingly, all TC decisions (past and future) related to init
+>      systems, which do not specify otherwise, should be read as
+>      including the following rider:
+>        | This decision is automatically vacated by any contrary
+>        | General Resolution which passes by a simple majority.
+>        | In that case the General Resolution takes effect and
+>        | the whole of this decision is to be taken as withdrawn by the
+>        | TC (i.e. as if the TC had explicitly withdrawn it by a
+>        | subsequent TC resolution).
+>
+> Please send comments, or formal amendment proposals, by 2014-01-28
+> 17:00 UTC.  I will call a vote on some version(s) then.
+
+I would strongly prefer you time-bound such a resolution.  Burdening all
+*future* technical committees with an exception to the constitution they
+must remember and handle seems unkind.  
+
+An easy change would be to replace "(past and future)" with "prior to
+the jessie release", or similar?
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 27 Jan 2014 23:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 27 Jan 2014 23:00:05 GMT) (full text, mbox, link).

+ +

Message #4251 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Mon, 27 Jan 2014 15:56:27 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I hereby propose the following resolution:
+>
+>    1. Support for sysvinit is mandatory in jessie.
+>
+>    2. Debian intends to support multiple init systems, for the
+>       foreseeable future, and so long as their respective communities
+>       and code remain healthy.  Nothing outside of an init system's
+>       implementation may require a specific init system to be pid 1.
+
+I'm not comfortable with a mandate that packages may not require a
+specific init system as pid 1.  
+
+While the case that has been discussed repeatedly recently involves
+GNOME and systemd, this text as written at least begs the question of
+what defines "outside of an init system". 
+
+I understand and sympathize strongly with what you're trying to
+accomplish here, I'm just not convinced (yet?) that this is the right
+way to proceed.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 27 Jan 2014 23:24:04 GMT) (full text, mbox, link).

+ +

Message #4254 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Tue, 28 Jan 2014 00:18:09 +0100
+
+
Hi,
+
+Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Ian Jackson writes ("Bug#727708: multiple init systems - formal resolution proposal"):
+>> I hereby propose the following resolution:
+>> 
+>>    1. Support for sysvinit is mandatory in jessie.
+>
+> I hereby propose and accept an amendment to add a new rubric paragraph
+> 0, and I also propose and do NOT accept an amendment to delete
+> paragraph 2, so as to result in the following proposal:
+>
+>  == both versions ==
+>
+>    0. We exercise our power to set policy, Constitution 6.1.1:
+
+6.1.1 states "In each case the usual maintainer of the relevant software
+or documentation makes decisions initially, however; see 6.3(5).".
+
+So in this case the Policy editors should make the decision
+initially. The ctte can then override them, but would require a 3:1
+majority (unless the Policy editors defer the issue under 6.1.3).
+
+>    1. Support for sysvinit is mandatory in jessie.
+
+This is a "should" currently (Policy 9.3.2). Do you plan to change this
+to a "must"?
+
+Would git-daemon-run violate this? Note that git-daemon-run provides
+sysvinit integration.
+
+>  == version "multiple" only ==
+>
+>    2. Debian intends to support multiple init systems, for the
+>       foreseeable future, and so long as their respective communities
+>       and code remain healthy.  Nothing outside of an init system's
+>       implementation may require a specific init system to be pid 1.
+
+It's unclear if reduced functionality (or in the extreme case no
+functionality) would satisfy this.
+
+Would a gnome-session-systemd package that requires systemd violate
+this (if gnome-session is also available)? If yes, what is the reason
+for forbidding people from trying out new things?
+
+Ansgar
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 27 Jan 2014 23:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Keith Packard" <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 27 Jan 2014 23:33:04 GMT) (full text, mbox, link).

+ +

Message #4259 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Keith Packard" <keithp@keithp.com>
+
To: 727708@bugs.debian.org
+
Subject: Upstart and the CLA
+
Date: Mon, 27 Jan 2014 15:29:44 -0800
+
+
[Message part 1 (text/plain, inline)]
+
+I've been asked by a couple of people for my thoughts on how the upstart
+CLA has impacted my position about the default init system for Debian.
+
+I think it's pretty clear the upstart CLA was the most damaging at the
+very start of the project. As Kay and Lennart have intimated elsewhere,
+the upstart CLA was a very real and important reason for the genesis of
+systemd as a separate project instead of a series of improvements for
+upstart. Without the upstart CLA, there would be no systemd, and we
+would not be discussing which init system to switch to as we would have
+all switched to upstart a long time ago.
+
+If the upstart CLA were to disappear today, then future collaboration
+would be dramatically eased, and upstart would become a full member of
+the free software ecosystem. However, we cannot go back and fix the
+damage caused by the CLA at the start of the project. Most of the larger
+community has been working hard on systemd since it started and it has
+made enormous progress. Upstart has been improving as well, but at a
+slower pace commensurate with developer effort.
+
+In my analysis of the proposed replacements as a member of the
+tech-ctte, I tried to ignore the political issues (including the CLA)
+and focus purely on technical merits of the proposals. What I found was
+that both upstart and systemd were a huge improvement over our existing
+init system, and that either would be a good move for the Debian project
+on Linux. However, on balance, I believe that systemd is a better
+replacement for sysvinit than upstart for the majority of Debian uses today.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 00:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 00:21:04 GMT) (full text, mbox, link).

+ +

Message #4264 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Cc: secretary@debian.org
+
Subject: New draft of the decision part [Re: call for votes on default Linux + init system for jessie]
+
Date: Mon, 27 Jan 2014 16:18:36 -0800
+
+
On Mon, 27 Jan 2014, Don Armstrong wrote:
+> I think we should break the bigger question into this question plus
+> additional advice for transition after we resolve this issue, but for me
+> to vote things above FD, we should allow for a simple majority GR to
+> vacate this decision.
+
+Here is a first stab at this. I've taken some inspiration from Ian's
+draft, but I don't believe we need to have a separate decision on this,
+unless there is a strong objection from someone to allowing it to be
+overridden.
+
+Secretary: I think our intention is clear, but if any of the language is
+unclear, or if we should directly allow ourselves to be overridden under
+§4.1.5 or similar, please let us know.
+
+
+===DRAFT ONLY===
+
+1. If the project by General Resolution determines that an init(1)
+should be the default for jessie for Linux architectures, that default
+is automatically the decision of the Technical Committee.
+
+2. The default init(1) in jessie for Linux architectures will be
+
+A. systemd
+
+B. upstart
+
+C. openrc
+
+D. sysvinit
+
+E. Further Discussion
+
+
+===END DRAFT===
+
+This is
+http://anonscm.debian.org/gitweb/?p=collab-maint/debian-ctte.git;f=727708_initsystem/draft_initsystem_only_dla.txt;hb=HEAD
+
+CTTE members, feel free to propose amendments or change directly.
+
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+Le temps est un grand maître, dit-on; le malheur est qu'il soit un
+maître inhumain qui tue ses élèves.
+Time is a great teacher, but unfortunately it kills all its pupils.
+ -- Hector Berlioz
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 01:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 01:57:04 GMT) (full text, mbox, link).

+ +

Message #4269 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Mon, 27 Jan 2014 20:54:13 -0500
+
+
On Mon, Jan 27, 2014 at 11:59 AM, Ian Jackson wrote:
+>    2. Debian intends to support multiple init systems, for the
+>       foreseeable future, and so long as their respective communities
+>       and code remain healthy.  Nothing outside of an init system's
+>       implementation may require a specific init system to be pid 1.
+
+I think the push back you're seeing about this is because the second
+sentence imposes a fairly significant constraint on the project.
+
+Say gnome ultimately requires systemd, and something else in the
+meantime happens to be pid 1, that sentence really gets in the way.
+Why not avoid impeding progress and just let gnome do what it needs to
+work the way it wants, which would involve depending on the right
+stuff to make systemd its pid 1?
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 02:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 02:57:04 GMT) (full text, mbox, link).

+ +

Message #4274 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: 727708@bugs.debian.org, debian-curiosa@lists.debian.org
+
Subject: init system discussion - the highlights (was: Bug#727708: init system gr override - formal resolution proposal)
+
Date: Mon, 27 Jan 2014 18:52:45 -0800
+
+
Bdale Garbee <bdale@gag.com> writes:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+>
+>> I hereby propose the following resolution:
+>>
+>>   1. The Technical Committee does not wish any resolutions it passes
+>>      about the init system question(s) to stand in the face of any
+>>      contrary view expressed by a majority of the Developers in a
+>>      General Resolution.
+>>
+>>   2. Accordingly, all TC decisions (past and future) related to init
+>>      systems, which do not specify otherwise, should be read as
+>>      including the following rider:
+>>        | This decision is automatically vacated by any contrary
+>>        | General Resolution which passes by a simple majority.
+>>        | In that case the General Resolution takes effect and
+>>        | the whole of this decision is to be taken as withdrawn by the
+>>        | TC (i.e. as if the TC had explicitly withdrawn it by a
+>>        | subsequent TC resolution).
+>>
+>> Please send comments, or formal amendment proposals, by 2014-01-28
+>> 17:00 UTC.  I will call a vote on some version(s) then.
+>
+> I would strongly prefer you time-bound such a resolution.  Burdening all
+> *future* technical committees with an exception to the constitution they
+> must remember and handle seems unkind.  
+
+Wow, this is amazing.
+
+I'm trying to keep track of all the interesting stuff that has happened
+here so far to preserve it for the future. Is there anything noteworthy
+that I missed? So far I have (not strictly chronological):
+
+* The Debian CTTE is asked to decide about the default init system for
+  Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708)
+
+* Off the 8 CTTE members, 2 are starting to dive down into a technical
+  comparison, writing about 98% of all messages sent by ctte members on
+  this topic (FIXME: number is just a guess, need to do proper counting)
+
+* One ctte member is appaled by the reaction of the systemd developers
+  and maintainers to his suggestion regarding a daemon startup
+  notification method. He then creates and refers a second issue to the
+  ctte: the design of a daemon readiness protocol
+  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733452#1501)
+
+* A ctte member states that the "outright attacks [..] assuming not only
+  bad faith but malicious motives among other people in the free
+  software community" that he sees in the messages of another ctte
+  member are "deeply disturbing"
+  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2443).
+
+* A ctte member devotes a lengthy email to describing how "the GNOME
+  Team has a pattern of failing to engage constructively with the rest
+  of the project around crucial integration issues", and that therefore
+  the ctte should not let its decision be influenced by "assertions that
+  GNOME upstream is tethering itself to a specific init
+  system". (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2638)
+
+* The ctte chair asks to "try *very* hard to keep [disrespectful
+  sentences] out of the TC discussion".
+  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2468)
+
+* The ctte members one by one announce their preferences, resulting in a
+  theoretical (no formal vote was called) 4:4 draw between upstart and
+  systemd. All of 3 Ubuntu (or former Ubuntu) developers in the ctte
+  declare their support for upstart.
+
+* A debian developer finds a "fairly challeging conflict of interest"
+  after a ctte member and Canoncial-employed maintainer of upstart
+  states that decision for systemd "would leave Canonical confronting
+  some hard questions about whether to continue investing in upstart
+  development".
+  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2810)
+  
+* An attempt to draft a resolution gets stuck.
+
+* A GR is proposed on debian-vote. The option to defer the decision to
+  the ctte seems to get the most vocal support.
+  (XXX)
+
+* Some ctte members offer to implement specific functions in their
+  preferred init system in an attempt to sway others to their position.
+  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#4031)
+  
+* The ctte chair calls for vote on the default init system in a ~10 line
+  message without prior discussion of the resolution. The call for votes
+  is not send to the ctte bug, but the ctte mailing list.
+  (xxx)
+  
+* A ctte member is offended by calling for votes on this resolution
+  without discussing it first, and asks the other members to vote with
+  "further discussion" because the resolution did not specify that it
+  could be overturned by a GR with simple majority.
+  (XXX)
+  
+* A ctte resolution to declare that all future ctte decisions relating
+  to the init system will be automatically overruled by GRs with simple
+  majority is proposed. The author states he will call for votes after a
+  discussion period of one day.
+  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#4191)
+
+* A ctte resolution asserting that sysv init support is mandatory and
+  that no package may depend on a specific init system is proposed. The
+  author states he will call for votes after a discussion period of one
+  day. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#4201)
+
+* A fourth ctte resolution draft is posted, this time asking for the
+  default init system while explicitly specfying that a GR will override
+  the choice with simple majority.
+  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#4264)
+
+
+(F'up2 debian-curiosa)
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 04:27:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Chris.Knadle@coredump.us:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 04:27:05 GMT) (full text, mbox, link).

+ +

Message #4279 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Chris Knadle <Chris.Knadle@coredump.us>
+
To: debian-ctte@lists.debian.org, Nikolaus Rath <Nikolaus@rath.org>, 727708@bugs.debian.org
+
Cc: debian-curiosa@lists.debian.org
+
Subject: Re: Bug#727708: init system discussion - the highlights (was: Bug#727708: init system gr override - formal resolution proposal)
+
Date: Mon, 27 Jan 2014 23:23:04 -0500
+
+
On Monday, January 27, 2014 18:52:45 Nikolaus Rath wrote:
+> Bdale Garbee <bdale@gag.com> writes:
+> > Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> >> I hereby propose the following resolution:
+> >>   1. The Technical Committee does not wish any resolutions it passes
+> >>   
+> >>      about the init system question(s) to stand in the face of any
+> >>      contrary view expressed by a majority of the Developers in a
+> >>      General Resolution.
+> >>   
+> >>   2. Accordingly, all TC decisions (past and future) related to init
+> >>   
+> >>      systems, which do not specify otherwise, should be read as
+> >>      
+> >>      including the following rider:
+> >>        | This decision is automatically vacated by any contrary
+> >>        | General Resolution which passes by a simple majority.
+> >>        | In that case the General Resolution takes effect and
+> >>        | the whole of this decision is to be taken as withdrawn by the
+> >>        | TC (i.e. as if the TC had explicitly withdrawn it by a
+> >>        | subsequent TC resolution).
+> >> 
+> >> Please send comments, or formal amendment proposals, by 2014-01-28
+> >> 17:00 UTC.  I will call a vote on some version(s) then.
+> > 
+> > I would strongly prefer you time-bound such a resolution.  Burdening all
+> > *future* technical committees with an exception to the constitution they
+> > must remember and handle seems unkind.
+> 
+> Wow, this is amazing.
+> 
+> I'm trying to keep track of all the interesting stuff that has happened
+> here so far to preserve it for the future. Is there anything noteworthy
+> that I missed?
+
+I'll just mention that the proposal of switching out the default init system 
+in jessie+1 sounds a bit scary, as it will change a basic administration 
+interface in the middle of a Stable support period.  Probably the most 
+interesting scenarios with this involve servers running unattended upgrades.
+
+[And while it's perhaps not the best time to mention the above, it's been on 
+my mind for a few days, so I'm "getting it over with".]
+
+As for the TC discussion, it should not be surprising that there is 
+contention, especially if the TC is a representative microcosm of
+[debian-devel] where likewise there was contention on this issue.  Personally 
+I'm more pleased by the work of looking into the code, documentation, 
+considerations of community and licensing, and so on, than not.  It's a lot of 
+work to evaluate all of this, and I appreciate the effort each of the TC 
+members has put in.  [And likewise all of those outside the TC that were 
+evaluating the choices, regardless of whether doing so loudly or silently.]
+
+IMHO the main reason this bug was referred to the TC was to remove ambiguity 
+and so that a choice could be made to allow focusing effort.  Regardless of 
+whether it's the right choice, the project needs an answer, so ironically 
+having a choice -- any of the three choices -- may be more important than 
+having the "best" choice -- especially since what's "best" is exactly where 
+the most contention lies.
+
+  -- Chris
+
+--
+Chris Knadle
+Chris.Knadle@coredump.us
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 05:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 05:57:04 GMT) (full text, mbox, link).

+ +

Message #4284 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Cc: debian-curiosa@lists.debian.org
+
Subject: Re: Bug#727708: init system discussion - the highlights
+
Date: Tue, 28 Jan 2014 06:55:45 +0100
+
+
]] Chris Knadle 
+
+> I'll just mention that the proposal of switching out the default init system 
+> in jessie+1 sounds a bit scary, as it will change a basic administration 
+> interface in the middle of a Stable support period.  Probably the most 
+> interesting scenarios with this involve servers running unattended upgrades.
+
+That's not what jessie+1 means.  jessie+1 is the release after jessie.
+If you're running unattended upgrades from one stable release to the
+next without proper testing first you can expect to run into some
+trouble.
+
+(Most of the basic administration interfaces don't change, though.  You
+can still use service to start/stop services, for instance.)
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 06:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 06:27:04 GMT) (full text, mbox, link).

+ +

Message #4289 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Ansgar Burchardt <ansgar@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Tue, 28 Jan 2014 08:23:55 +0200
+
+
On Tue, Jan 28, 2014 at 12:18:09AM +0100, Ansgar Burchardt wrote:
+>...
+> >  == version "multiple" only ==
+> >
+> >    2. Debian intends to support multiple init systems, for the
+> >       foreseeable future, and so long as their respective communities
+> >       and code remain healthy.  Nothing outside of an init system's
+> >       implementation may require a specific init system to be pid 1.
+> 
+> It's unclear if reduced functionality (or in the extreme case no
+> functionality) would satisfy this.
+> 
+> Would a gnome-session-systemd package that requires systemd violate
+> this (if gnome-session is also available)?
+>...
+
+You are forgetting the best technical solution, which is what 
+gnome-session is actually implementing at the moment:
+
+  session_tracking="systemd (with fallback to ConsoleKit)" [1]
+
+
+> Ansgar
+
+cu
+Adrian
+
+[1] copied from the gnome-session configure.ac
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 06:42:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 06:42:05 GMT) (full text, mbox, link).

+ +

Message #4294 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Michael Gilbert <mgilbert@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Tue, 28 Jan 2014 08:40:01 +0200
+
+
On Mon, Jan 27, 2014 at 08:54:13PM -0500, Michael Gilbert wrote:
+> On Mon, Jan 27, 2014 at 11:59 AM, Ian Jackson wrote:
+> >    2. Debian intends to support multiple init systems, for the
+> >       foreseeable future, and so long as their respective communities
+> >       and code remain healthy.  Nothing outside of an init system's
+> >       implementation may require a specific init system to be pid 1.
+> 
+> I think the push back you're seeing about this is because the second
+> sentence imposes a fairly significant constraint on the project.
+> 
+> Say gnome ultimately requires systemd, and something else in the
+> meantime happens to be pid 1, that sentence really gets in the way.
+> Why not avoid impeding progress and just let gnome do what it needs to
+> work the way it wants, which would involve depending on the right
+> stuff to make systemd its pid 1?
+
+Claiming that the scope would be limited to GNOME is already factually 
+incorrect as of today in experimental.
+
+NetworkManager and PolicyKit can be compiled with support for logind, or 
+with support for ConsoleKit+upower.
+In experimental, they do support only logind.
+
+That's an example where such a policy that requires either a non-systemd 
+logind replacement, or runtime detection of logind and sensible 
+fallbacks like in gnome-session, has to be in place to secure that 
+supporting multiple init systems is actually true in practice. [1]
+
+> Best wishes,
+> Mike
+
+cu
+Adrian
+
+[1] That's ignoring the possibility that a non-systemd logind 
+    replacement with sufficient functionality for all software following 
+    the latest logind features might show up one day - but without such 
+    a policy such a non-systemd logind would not be a prerequisite for 
+    these packages to move from experimental to unstable and testing.
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 07:12:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 07:12:04 GMT) (full text, mbox, link).

+ +

Message #4299 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Michael Gilbert <mgilbert@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Tue, 28 Jan 2014 09:09:56 +0200
+
+
On Tue, Jan 28, 2014 at 08:40:01AM +0200, Adrian Bunk wrote:
+>...
+> [1] That's ignoring the possibility that a non-systemd logind 
+>     replacement with sufficient functionality for all software following 
+>     the latest logind features might show up one day - but
+>,,,
+
+Please ignore this part of [1] - I botched proof-reading my email after 
+rewriting it.
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 07:18:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Vincent Bernat <bernat@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 07:18:10 GMT) (full text, mbox, link).

+ +

Message #4304 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Vincent Bernat <bernat@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: Ansgar Burchardt <ansgar@debian.org>, 727708@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Tue, 28 Jan 2014 08:14:33 +0100
+
+
[Message part 1 (text/plain, inline)]
+
 ❦ 28 janvier 2014 07:23 CET, Adrian Bunk <bunk@stusta.de> :
+
+> You are forgetting the best technical solution, which is what 
+> gnome-session is actually implementing at the moment:
+>
+>   session_tracking="systemd (with fallback to ConsoleKit)" [1]
+
+Sure, the best technical solution is to rely on an unmaintained
+component.
+-- 
+Write and test a big program in small pieces.
+            - The Elements of Programming Style (Kernighan & Plauger)
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 07:21:04 GMT) (full text, mbox, link).

+ +

Message #4307 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Tue, 28 Jan 2014 08:16:22 +0100
+
+
Adrian Bunk <bunk@stusta.de> writes:
+> On Tue, Jan 28, 2014 at 12:18:09AM +0100, Ansgar Burchardt wrote:
+>>...
+>> >  == version "multiple" only ==
+>> >
+>> >    2. Debian intends to support multiple init systems, for the
+>> >       foreseeable future, and so long as their respective communities
+>> >       and code remain healthy.  Nothing outside of an init system's
+>> >       implementation may require a specific init system to be pid 1.
+>> 
+>> It's unclear if reduced functionality (or in the extreme case no
+>> functionality) would satisfy this.
+>> 
+>> Would a gnome-session-systemd package that requires systemd violate
+>> this (if gnome-session is also available)?
+>>...
+>
+> You are forgetting the best technical solution, which is what 
+> gnome-session is actually implementing at the moment:
+>
+>   session_tracking="systemd (with fallback to ConsoleKit)" [1]
+
+No. My question isn't about logind, but about using a user systemd
+session to supervise processes started by the session. IIRC both GNOME
+and KDE were mentioned to consider this feature.
+
+Ansgar
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 08:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 08:54:04 GMT) (full text, mbox, link).

+ +

Message #4312 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Tue, 28 Jan 2014 09:52:24 +0100
+
+
Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit : 
+> Adrian Bunk <bunk@stusta.de> writes:
+> >
+> > You are forgetting the best technical solution, which is what 
+> > gnome-session is actually implementing at the moment:
+> >
+> >   session_tracking="systemd (with fallback to ConsoleKit)" [1]
+> 
+> No. My question isn't about logind, but about using a user systemd
+> session to supervise processes started by the session. IIRC both GNOME
+> and KDE were mentioned to consider this feature.
+
+I wouldn’t worry much about such features, at least not for jessie. They
+will most likely be fallbacks, and in the unlikely case they are at
+build time, we could always put the two binaries in the same package
+with dynamic detection, thus working around this requirement.
+
+The real problem is logind. The requirement proposed by Ian is not
+implementable:
+http://lists.debian.org/1390155797.29928.17.camel@tomoe
+
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 11:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 11:42:04 GMT) (full text, mbox, link).

+ +

Message #4317 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 11:39:51 +0000
+
+
Bdale Garbee writes ("call for votes on default Linux init system for jessie"):
+>   The default init system for Linux architectures in jessie should be
+> 
+>   1.  systemd
+> 
+>   2.  upstart
+> 
+>   3.  openrc
+> 
+>   4.  sysvinit (no change)
+> 
+>   5.  requires further discussion.
+
+It looks like this is going to be voted down or withdrawn, thanks, and
+everyone is agreed that there should be a rider about GRs.  I'll
+therefore comment on the substance.
+
+I don't want to pass a resolution specifying the default without also
+answering the other two, related, contentious questions:
+
+  Q1: Do we intend to support multiple systems long-term, or do we
+  intend to settle on a single system, probably in jessie+1 ?
+
+  Q2: Is it OK for packages to depend on a specific init system as
+  pid 1 ?
+
+There are two reasons why I want to decide these questions in the same
+vote.
+
+Firstly, as I have said, TC members should be able to express the
+preference "only X, X by default but also others, Y by default but
+also others, Y", which is a perfectly reasonable one but which cannot
+be expressed by a concurrent ballots (and holding the ballots
+sequentially in situations like this can be a way of manipulating the
+result).
+
+Secondly, making a decision on the default without clearly stating a
+requirement for support for multiple systems risks a situation where
+partisans for the winning system create "facts on the ground" which
+make it difficult to support multiple systems.
+
+
+I think there are the following three reasonable answers to Q1/Q2
+taken together.
+
+i.   Q1: Multiple in >jessie
+     Q2: Requiring specific init is forbidden
+
+ii.  Q1: Multiple in >jessie
+     Q2: Requiring default init is permitted
+
+iii. Q1: Single in jessie+1
+     Q2: Requiring default init is permitted
+
+Of these (ii) would cause the non-default inits to rot.  Unless anyone
+thinks this is a useful option I don't think we should vote on it.
+
+
+So that leaves my text from yesterday:
+
+   M. Debian intends to support multiple init systems, for the
+      foreseeable future, and so long as their respective communities
+      and code remain healthy.  Software outside of an init system's
+      implementation may not require a specific init system to be
+      pid 1, although degraded operation is tolerable.
+
+vs something like:
+
+   O. Debian intends to converge on one init system; in jessie+1,
+      packages may require that the default init system is in use.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 11:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 11:54:04 GMT) (full text, mbox, link).

+ +

Message #4322 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 11:50:19 +0000
+
+
Ian Jackson writes ("Bug#727708: call for votes on default Linux init system for jessie"):
+> Bdale Garbee writes ("call for votes on default Linux init system for jessie"):
+> >   The default init system for Linux architectures in jessie should be
+> > 
+> >   D.  systemd
+> > 
+> >   U.  upstart
+> > 
+> >   R.  openrc
+> > 
+> >   V.  sysvinit (no change)
+> > 
+> >   F.  requires further discussion.
+
+I have lettered these.
+
+> So that leaves my text from yesterday:
+> 
+>    M. Debian intends to support multiple init systems, for the
+>       foreseeable future, and so long as their respective communities
+>       and code remain healthy.  Software outside of an init system's
+>       implementation may not require a specific init system to be
+>       pid 1, although degraded operation is tolerable.
+
+(I forgot to say, I edited that a bit.)
+
+> vs something like:
+> 
+>    O. Debian intends to converge on one init system; in jessie+1,
+>       packages may require that the default init system is in use.
+
+If we are I to vote now, I would like to see on the ballot at least:
+   DM  systemd by default, but also others
+   DO  systemd only in jessie+1
+   UM  upstart by default, but also others
+   UO  upstart only in jessie+1
+   RM  openrc by default, but also others
+   VM  sysvinit by default, but also others
+
+I don't think RO and VO make much sense.
+
+Does my text for "O" correctly represent the views of those who want
+us to converge on a single system ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 11:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 11:57:04 GMT) (full text, mbox, link).

+ +

Message #4327 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 11:52:34 +0000
+
+
Ian Jackson writes ("Re: Bug#727708: call for votes on default Linux init system for jessie"):
+> > So that leaves my text from yesterday:
+> > 
+> >    M. Debian intends to support multiple init systems, for the
+> >       foreseeable future, and so long as their respective communities
+> >       and code remain healthy.  Software outside of an init system's
+> >       implementation may not require a specific init system to be
+> >       pid 1, although degraded operation is tolerable.
+> 
+> (I forgot to say, I edited that a bit.)
+
+I hope this rephrasing is good enough to satisfy the quibbles which
+come up every time about this.  If any of the TC members feel that
+there is a better way to put this requirement I would be happy to hear
+it.
+
+For the avoidance of doubt, this is to be fleshed out into policy
+where the details can be dealt with.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 12:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Olav Vitters <ovitters@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 12:27:04 GMT) (full text, mbox, link).

+ +

Message #4332 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Olav Vitters <ovitters@gmail.com>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Tue, 28 Jan 2014 13:24:12 +0100
+
+
On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette <joss@debian.org> wrote:
+> Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
+>> No. My question isn't about logind, but about using a user systemd
+>> session to supervise processes started by the session. IIRC both GNOME
+>> and KDE were mentioned to consider this feature.
+>
+> I wouldn't worry much about such features, at least not for jessie. They
+> will most likely be fallbacks, and in the unlikely case they are at
+> build time, we could always put the two binaries in the same package
+> with dynamic detection, thus working around this requirement.
+
+Fallback is intended, so for near future you'd be ok. Longer term, I
+expect almost no maintenance to occur from GNOME side, so be prepared
+to handle the maintenance if nobody else does. Though I guess it'll be
+like ConsoleKit case: I'm warning, but nothing happens :-(
+
+> The real problem is logind. The requirement proposed by Ian is not
+> implementable:
+> http://lists.debian.org/1390155797.29928.17.camel@tomoe
+
+IMO other init systems should provide the interfaces which GNOME
+requires. It is not up to GNOME to provide these. That or takeup
+ConsoleKit maintenance (or logind alternative), but despite warning
+about and requesting this in January 2012, not much has happened.
+
+So I think the proposal should be turned around: Init systems should
+ensure that they meet the changing requirements of the rest of the
+stack. Aside from this we're open to discuss things with
+distributions. For logind case I approached various times (obviously
+not knowing Debian) and we warned and requested feedback. Initially
+via our distributor-list, but also reached out to debian-devel. Any
+practical answer and/or discussion is very welcome. The lack of any
+answer means we'll continue to do what we think is best.
+
+To be clear: Any answer like "it should just work across init systems"
+for me is not a practical answer as it ignores all the issues we're
+facing with this. That said, we don't rely on systemd. If there's
+functionality that we really want, need or makes our lives much
+easier, then I don't see how you can demand us to do double or triple
+work. The burden should be placed correctly, not with us.
+
+I'm quite saddened by lack of response to e.g. ConsoleKit/logind btw,
+it's been 2 years already!!
+
+Regards,
+Olav (GNOME release team dude for the people who don't know)
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 14:03:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Chris.Knadle@coredump.us:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 14:03:15 GMT) (full text, mbox, link).

+ +

Message #4337 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Chris Knadle <Chris.Knadle@coredump.us>
+
To: debian-ctte@lists.debian.org, Tollef Fog Heen <tfheen@err.no>, 727708@bugs.debian.org
+
Cc: debian-curiosa@lists.debian.org
+
Subject: Re: Bug#727708: init system discussion - the highlights
+
Date: Tue, 28 Jan 2014 09:01:01 -0500
+
+
On Tuesday, January 28, 2014 06:55:45 Tollef Fog Heen wrote:
+> ]] Chris Knadle
+> 
+> > I'll just mention that the proposal of switching out the default init
+> > system in jessie+1 sounds a bit scary, as it will change a basic
+> > administration interface in the middle of a Stable support period. 
+> > Probably the most interesting scenarios with this involve servers running
+> > unattended upgrades.
+>
+> That's not what jessie+1 means.  jessie+1 is the release after jessie.
+
+I was indeed thinking of a point release, so I mistook jessie+1 as
+"jessie + .1".  Now it makes sense, as the release after jessie is not yet 
+named.
+
+Thanks.
+
+  -- Chris
+
+--
+Chris Knadle
+Chris.Knadle@coredump.us
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 14:30:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 14:30:05 GMT) (full text, mbox, link).

+ +

Message #4342 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 28 Jan 2014 06:17:32 -0800
+
+
On Tue, 28 Jan 2014, Ian Jackson wrote:
+> >    M. Debian intends to support multiple init systems, for the
+> >       foreseeable future, and so long as their respective communities
+> >       and code remain healthy.  Software outside of an init system's
+> >       implementation may not require a specific init system to be
+> >       pid 1, although degraded operation is tolerable.
+
+I still don't think the last sentence of this paragraph completely
+handles the cases where someone can legitimately depend on a specific
+init system or specific init system interface.
+
+If we're supporting multiple init systems, then software which doesn't
+support multiple init systems which could feasibly do so is buggy. If
+patches to fix it appear and aren't applied, then people can appeal to
+the CTTE. It's not necessary or feasible for us to anticipate every
+single technical wrinkle and delay making a decision to do so.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+Taxes are not levied for the benefit of the taxed.
+ -- Robert Heinlein _Time Enough For Love_ p250
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 14:30:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 14:30:08 GMT) (full text, mbox, link).

+ +

Message #4347 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 28 Jan 2014 05:51:07 -0800
+
+
On Tue, 28 Jan 2014, Ian Jackson wrote:
+>   Q1: Do we intend to support multiple systems long-term, or do we
+>   intend to settle on a single system, probably in jessie+1 ?
+> 
+>   Q2: Is it OK for packages to depend on a specific init system as
+>   pid 1 ?
+
+[...]
+
+> Firstly, as I have said, TC members should be able to express the
+> preference "only X, X by default but also others, Y by default but
+> also others, Y", which is a perfectly reasonable one but which cannot
+> be expressed by a concurrent ballots
+
+The only reason to interlink these questions is if the ordering of
+someone's preference on the init system question is dependent on their
+preference on these two questions. If that's the case, then whoever
+feels that way should propose a draft which includes an option which
+handles that particular case.
+ 
+> Secondly, making a decision on the default without clearly stating a
+> requirement for support for multiple systems risks a situation where
+> partisans for the winning system create "facts on the ground" which
+> make it difficult to support multiple systems.
+
+This presupposes bad faith, and even if it were so, such behavior would
+still be possible even if we voted in a single decision.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+The computer allows you to make mistakes faster than any other
+invention, with the possible exception of handguns and tequila
+ -- Mitch Ratcliffe
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 14:30:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 14:30:11 GMT) (full text, mbox, link).

+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 14:42:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 14:42:05 GMT) (full text, mbox, link).

+ +

Message #4357 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Don Armstrong <don@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 14:38:12 +0000
+
+
Don Armstrong writes ("Bug#727708: call for votes on default Linux init system for jessie"):
+> On Tue, 28 Jan 2014, Ian Jackson wrote:
+> > >    M. Debian intends to support multiple init systems, for the
+> > >       foreseeable future, and so long as their respective communities
+> > >       and code remain healthy.  Software outside of an init system's
+> > >       implementation may not require a specific init system to be
+> > >       pid 1, although degraded operation is tolerable.
+> 
+> I still don't think the last sentence of this paragraph completely
+> handles the cases where someone can legitimately depend on a specific
+> init system or specific init system interface.
+
+Would you care to suggest an alternative wording ?
+
+> If we're supporting multiple init systems, then software which doesn't
+> support multiple init systems which could feasibly do so is buggy. If
+> patches to fix it appear and aren't applied, then people can appeal to
+> the CTTE. It's not necessary or feasible for us to anticipate every
+> single technical wrinkle and delay making a decision to do so.
+
+I agree with this.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 14:51:29 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 14:51:29 GMT) (full text, mbox, link).

+ +

Message #4362 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 09:46:14 -0500
+
+
On Tue, Jan 28, 2014 at 8:51 AM, Don Armstrong wrote:
+> On Tue, 28 Jan 2014, Ian Jackson wrote:
+>>   Q1: Do we intend to support multiple systems long-term, or do we
+>>   intend to settle on a single system, probably in jessie+1 ?
+>>
+>>   Q2: Is it OK for packages to depend on a specific init system as
+>>   pid 1 ?
+>
+> [...]
+>
+>> Firstly, as I have said, TC members should be able to express the
+>> preference "only X, X by default but also others, Y by default but
+>> also others, Y", which is a perfectly reasonable one but which cannot
+>> be expressed by a concurrent ballots
+>
+> The only reason to interlink these questions is if the ordering of
+> someone's preference on the init system question is dependent on their
+> preference on these two questions. If that's the case, then whoever
+> feels that way should propose a draft which includes an option which
+> handles that particular case.
+>
+>> Secondly, making a decision on the default without clearly stating a
+>> requirement for support for multiple systems risks a situation where
+>> partisans for the winning system create "facts on the ground" which
+>> make it difficult to support multiple systems.
+>
+> This presupposes bad faith, and even if it were so, such behavior would
+> still be possible even if we voted in a single decision.
+
+Even if the TC acts with the purest of motives, there is always a
+certain subset of observers likely to assume the worst and ascribe a
+bad faith motive.
+
+It is better to head that off by making the TCs intention and thought
+process abundantly clear.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 15:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 15:06:04 GMT) (full text, mbox, link).

+ +

Message #4367 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: Michael Gilbert <mgilbert@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Tue, 28 Jan 2014 14:57:41 +0000 (UTC)
+
+
Michael Gilbert dixit:
+
+>Why not avoid impeding progress and just let gnome do what it needs to
+>work the way it wants, which would involve depending on the right
+
+Excuse me, why is GNOME, specifically, being allowed to “do what it
+wants”, in this case? Imagine other software with a more-or-less
+legitimate dependency on, meh idk, upstart for example.
+
+No.
+
+
+bye,
+//mirabilos
+-- 
+<Natureshadow> Warum ist MirWebseite eigentlich so cool?  <mirabilos> weil ich
+ich sie geschrieben habe  <Natureshadow> Hast du sie geschrieben oder geforkt?
+<mirabilos> geschrieben, from scratch  <Natureshadow> Ach, deshalb finde ich
+auch so selten Bugs dadrin. Irgendwie hast du Recht.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 15:06:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 15:06:08 GMT) (full text, mbox, link).

+ +

Message #4372 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: Olav Vitters <ovitters@gmail.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Tue, 28 Jan 2014 15:01:58 +0000 (UTC)
+
+
Olav Vitters dixit:
+
+>IMO other init systems should provide the interfaces which GNOME
+>requires. It is not up to GNOME to provide these. That or takeup
+
+There is a lot wrong with that statement.
+
+Imagine you’re working on/with a software FOO that is not yet
+packaged in Debian. Say it comes from the Macintosh world, so
+it does not build out-of-the-box.
+
+Common sense states that you need to port it to the Debian OS
+instead of Debian providing those Macintosh-specific APIs FOO
+uses.
+
+GNOME is not special.
+
+bye,
+//mirabilos
+-- 
+22:59⎜<Vutral> glaub ich termkit is kompliziert | glabe nicht das man
+damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil
+zuviel bilder │ wie ein spiel | 23:00⎜<Vutral> die meisten raffen auch
+nicht mehr von windows | 23:01⎜<Vutral> bilderbücher sind ja auch nich
+wirklich verbreitet als erwachsenen literatur	‣ who needs GUIs thus?
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 16:06:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 16:06:05 GMT) (full text, mbox, link).

+ +

Message #4377 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 09:02:38 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I think there are the following three reasonable answers to Q1/Q2
+> taken together.
+>
+> i.   Q1: Multiple in >jessie
+>      Q2: Requiring specific init is forbidden
+>
+> ii.  Q1: Multiple in >jessie
+>      Q2: Requiring default init is permitted
+>
+> iii. Q1: Single in jessie+1
+>      Q2: Requiring default init is permitted
+
+Why do you use 'specific init' in (1) but "default init" in (ii) and
+(iii)?  Please be consistent in the use of "specific init" for all three
+options.  
+
+With that change, (ii) might well be my first choice among these three.
+
+As written, I don't see the point of having Q2 included in (iii) other
+than for completeness, as asserting that we'll only support one init
+system seems to make the question of whether anything depends on it
+explicitly irrelevant and/or redundant?
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 16:12:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 16:12:08 GMT) (full text, mbox, link).

+ +

Message #4382 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 09:09:38 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> If we are I to vote now, I would like to see on the ballot at least:
+
+If we choose to proceed with this kind of a vote, the combinations I
+care about are adequately captured by this list. 
+
+I remain uncomfortable, however, about trying to be prescriptive about
+what happens past jessie. 
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 16:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 16:27:04 GMT) (full text, mbox, link).

+ +

Message #4387 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Bdale Garbee <bdale@gag.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 16:25:09 +0000
+
+
Bdale Garbee writes ("Re: Bug#727708: call for votes on default Linux init system for jessie"):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > I think there are the following three reasonable answers to Q1/Q2
+> > taken together.
+> >
+> > i.   Q1: Multiple in >jessie
+> >      Q2: Requiring specific init is forbidden
+> >
+> > ii.  Q1: Multiple in >jessie
+> >      Q2: Requiring default init is permitted
+> >
+> > iii. Q1: Single in jessie+1
+> >      Q2: Requiring default init is permitted
+> 
+> Why do you use 'specific init' in (1) but "default init" in (ii) and
+> (iii)?  Please be consistent in the use of "specific init" for all three
+> options.  
+
+I think it doesn't make sense to allow people to require a non-default
+init.  If you think it does then there are three possible answers to
+Q2: "requiring a specific init is permitted even if it is not the
+default one", "requiring the default init is OK but requiring another
+is not" and "requiring a specific init is not OK".
+
+> With that change, (ii) might well be my first choice among these three.
+
+But I guess you disagree.
+
+> As written, I don't see the point of having Q2 included in (iii) other
+> than for completeness, as asserting that we'll only support one init
+> system seems to make the question of whether anything depends on it
+> explicitly irrelevant and/or redundant?
+
+I was trying to determine the reasonable subset of the entire possible
+matrix of answers.  Obviously I think the answer "single" to Q1
+implies the "requiring the default init is OK" to Q2.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 17:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 17:03:04 GMT) (full text, mbox, link).

+ +

Message #4392 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 09:59:13 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I think it doesn't make sense to allow people to require a non-default
+> init.  If you think it does then there are three possible answers to
+> Q2: "requiring a specific init is permitted even if it is not the
+> default one", "requiring the default init is OK but requiring another
+> is not" and "requiring a specific init is not OK".
+
+I prefer Don's approach to thinking about this:
+
+   I still don't think the last sentence of this paragraph completely
+   handles the cases where someone can legitimately depend on a specific
+   init system or specific init system interface.
+
+   If we're supporting multiple init systems, then software which doesn't
+   support multiple init systems which could feasibly do so is buggy. If
+   patches to fix it appear and aren't applied, then people can appeal to
+   the CTTE. It's not necessary or feasible for us to anticipate every
+   single technical wrinkle and delay making a decision to do so.
+
+Thus, I believe the only acceptable option for Q2 from among your set is
+"requiring a specific init is permitted even if it is not the default
+one".  But I would prefer to vote a ballot that doesn't mention
+dependencies at all. 
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 17:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 17:15:05 GMT) (full text, mbox, link).

+ +

Message #4397 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, Bdale Garbee <bdale@gag.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 09:12:54 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I think it doesn't make sense to allow people to require a non-default
+> init.
+
+I think this position is consistent with allowing each maintainer broad
+autonomy, and not overly burdening them with requirements that may make
+it difficult or impossible to provide bug fixes and other improvements
+From newer upstream versions.
+
+Yes, I'd consider it a bug, but I'm not sure it reaches the level of an
+RC bug.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 17:27:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 17:27:10 GMT) (full text, mbox, link).

+ +

Message #4402 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Bdale Garbee <bdale@gag.com>, 727708@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 09:23:11 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Bdale Garbee <bdale@gag.com> writes:
+
+> Thus, I believe the only acceptable option for Q2 from among your set is
+> "requiring a specific init is permitted even if it is not the default
+> one".  But I would prefer to vote a ballot that doesn't mention
+> dependencies at all.
+
+I agree with this; I don't think we should try to force developers into
+significant work to satisfy an init system constraint as that may
+prevent or delay important fixes and improvements from entering the
+repository.
+
+Of course, nothing would prevent someone else from fixing these kinds of
+bugs and having those fixes get merged into the package, potentially
+invoking §6.1.4 to have the tech-ctte resolve any conflict as needed.
+However, I'd anticipate that most package developers would readily
+accept fixes that made their packages work for more people.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 17:36:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 17:36:10 GMT) (full text, mbox, link).

+ +

Message #4407 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 09:33:53 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> If we are I to vote now, I would like to see on the ballot at least:
+>    DM  systemd by default, but also others
+>    DO  systemd only in jessie+1
+>    UM  upstart by default, but also others
+>    UO  upstart only in jessie+1
+>    RM  openrc by default, but also others
+>    VM  sysvinit by default, but also others
+
+I'm still very uncomfortable with any vote that would constrain our
+solution space past the Jessie release. I'm fairly convinced that we'll
+be supporting multiple init systems for a long time, but my vision gets
+very fuzzy out that far, and it's just possible I might be wrong.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 17:36:45 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 17:36:45 GMT) (full text, mbox, link).

+ +

Message #4412 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Olav Vitters <ovitters@gmail.com>, 727708@bugs.debian.org
+
Cc: Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Tue, 28 Jan 2014 19:34:56 +0200
+
+
On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote:
+> On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette <joss@debian.org> wrote:
+> > Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
+> >> No. My question isn't about logind, but about using a user systemd
+> >> session to supervise processes started by the session. IIRC both GNOME
+> >> and KDE were mentioned to consider this feature.
+> >
+> > I wouldn't worry much about such features, at least not for jessie. They
+> > will most likely be fallbacks, and in the unlikely case they are at
+> > build time, we could always put the two binaries in the same package
+> > with dynamic detection, thus working around this requirement.
+> 
+> Fallback is intended, so for near future you'd be ok. Longer term, I
+> expect almost no maintenance to occur from GNOME side, so be prepared
+> to handle the maintenance if nobody else does.
+>...
+
+The freeze for jessie will be in November 2014, so it will ship with
+GNOME 3.14 (or earlier).
+
+Am I reading your email correctly that can Debian assume that for the 
+GNOME in jessie proper fallbacks will be in place, so that GNOME in 
+jessie will work fine with init systems other than systemd?
+
+
+> Regards,
+> Olav (GNOME release team dude for the people who don't know)
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 17:36:48 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 17:36:48 GMT) (full text, mbox, link).

+ +

Message #4417 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 28 Jan 2014 19:35:56 +0200
+
+
On Tue, Jan 28, 2014 at 11:39:51AM +0000, Ian Jackson wrote:
+>...
+>    M. Debian intends to support multiple init systems, for the
+>       foreseeable future, and so long as their respective communities
+>       and code remain healthy.  Software outside of an init system's
+>       implementation may not require a specific init system to be
+>       pid 1, although degraded operation is tolerable.
+>...
+
+Is udev considered to be part of systemd's implementation?
+
+
+> Ian.
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 17:45:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 17:45:07 GMT) (full text, mbox, link).

+ +

Message #4422 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Keith Packard <keithp@keithp.com>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, + Bdale Garbee <bdale@gag.com>
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 28 Jan 2014 19:42:32 +0200
+
+
On Tue, Jan 28, 2014 at 09:12:54AM -0800, Keith Packard wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> 
+> > I think it doesn't make sense to allow people to require a non-default
+> > init.
+> 
+> I think this position is consistent with allowing each maintainer broad
+> autonomy, and not overly burdening them with requirements that may make
+> it difficult or impossible to provide bug fixes and other improvements
+> From newer upstream versions.
+> 
+> Yes, I'd consider it a bug, but I'm not sure it reaches the level of an
+> RC bug.
+
+For anyone intending to make Debian the laughingstock of the open source
+world, here is a good opportunity:
+
+  Debian decides that Upstart is the default init system for jessie,
+  but it's default desktop GNOME forces the installation of systemd.
+
+
+> Ian.
+
+cu
+Adrian
+
+BTW: Yes, the "default desktop for jessie" discussion that is scheduled 
+     for August is also intertwingled with the init system issue...
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 18:00:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 18:00:09 GMT) (full text, mbox, link).

+ +

Message #4427 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Keith Packard <keithp@keithp.com>, + 727708@bugs.debian.org, + Bdale Garbee <bdale@gag.com>
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie [and 1 more messages]
+
Date: Tue, 28 Jan 2014 17:53:08 +0000
+
+
Bdale Garbee writes ("Bug#727708: call for votes on default Linux init system for jessie"):
+> Thus, I believe the only acceptable option for Q2 from among your set is
+> "requiring a specific init is permitted even if it is not the default
+> one".  But I would prefer to vote a ballot that doesn't mention
+> dependencies at all. 
+
+Keith Packard writes ("Bug#727708: call for votes on default Linux init system for jessie"):
+> I'm still very uncomfortable with any vote that would constrain our
+> solution space past the Jessie release. I'm fairly convinced that we'll
+> be supporting multiple init systems for a long time, but my vision gets
+> very fuzzy out that far, and it's just possible I might be wrong.
+
+I'm not going to try to talk you out of this.
+
+In that case we need options on the ballot which don't contain any of
+the texts on this question I was proposing, as well as options why do.
+
+If there is noone who wants to explicitly say something like this
+
+    O. Debian intends to converge on one init system; in jessie+1,
+       packages may require that the default init system is in use.
+
+then there is no point putting it on the ballot.
+
+That would leave us with
+
+    DM  systemd by default, but also others
+    D-  systemd by default, say nothing else
+    UM  upstart by default, but also others
+    U-  upstart by default, say nothing else
+    R-  openrc by default, say nothing else
+    V-  sysvinit by default, say nothing else
+
+I'm not going to push for RM and RV even though I would prefer them,
+because I think R- and V- are more popular in the rest of the TC.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 18:00:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 18:00:12 GMT) (full text, mbox, link).

+ +

Message #4432 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 17:54:18 +0000
+
+
Don Armstrong writes ("Bug#727708: call for votes on default Linux init system for jessie"):
+> On Tue, 28 Jan 2014, Ian Jackson wrote:
+> > >    M. Debian intends to support multiple init systems, for the
+> > >       foreseeable future, and so long as their respective communities
+> > >       and code remain healthy.  Software outside of an init system's
+> > >       implementation may not require a specific init system to be
+> > >       pid 1, although degraded operation is tolerable.
+> 
+> I still don't think the last sentence of this paragraph completely
+> handles the cases where someone can legitimately depend on a specific
+> init system or specific init system interface.
+> 
+> If we're supporting multiple init systems, then software which doesn't
+> support multiple init systems which could feasibly do so is buggy. If
+> patches to fix it appear and aren't applied, then people can appeal to
+> the CTTE. It's not necessary or feasible for us to anticipate every
+> single technical wrinkle and delay making a decision to do so.
+
+Is there some rephrasing of this paragraph which would persuade you to
+put it ahead of a ballot option with the paragraph entirely deleted ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 18:03:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 18:03:08 GMT) (full text, mbox, link).

+ +

Message #4437 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: init system gr override - formal resolution proposal
+
Date: Tue, 28 Jan 2014 18:00:32 +0000
+
+
Ian Jackson writes ("init system gr override - formal resolution proposal"):
+> I hereby propose the following resolution:
+> 
+>   1. The Technical Committee does not wish any resolutions it passes
+>      about the init system question(s) to stand in the face of any
+>      contrary view expressed by a majority of the Developers in a
+>      General Resolution.
+> 
+>   2. Accordingly, all TC decisions (past and future) related to init
+>      systems, which do not specify otherwise, should be read as
+>      including the following rider:
+>        | This decision is automatically vacated by any contrary
+>        | General Resolution which passes by a simple majority.
+>        | In that case the General Resolution takes effect and
+>        | the whole of this decision is to be taken as withdrawn by the
+>        | TC (i.e. as if the TC had explicitly withdrawn it by a
+>        | subsequent TC resolution).
+> 
+> Please send comments, or formal amendment proposals, by 2014-01-28
+> 17:00 UTC.  I will call a vote on some version(s) then.
+
+I withdraw this, as it's no longer needed.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 18:03:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 18:03:11 GMT) (full text, mbox, link).

+ +

Message #4442 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: multiple init systems - formal resolution proposal
+
Date: Tue, 28 Jan 2014 18:00:57 +0000
+
+
Ian Jackson writes ("multiple init systems - formal resolution proposal"):
+> I hereby propose the following resolution:
+> 
+>    1. Support for sysvinit is mandatory in jessie.
+> 
+>    2. Debian intends to support multiple init systems, for the
+>       foreseeable future, and so long as their respective communities
+>       and code remain healthy.  Nothing outside of an init system's
+>       implementation may require a specific init system to be pid 1.
+> 
+> Please send comments, or formal amendment proposals, by 2014-01-28
+> 17:00 UTC.  I will call a vote on some version(s) then.
+
+I withdraw this, as it's no longer needed.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 18:03:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 18:03:14 GMT) (full text, mbox, link).

+ +

Message #4447 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Adrian Bunk <bunk@stusta.de>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, Bdale Garbee <bdale@gag.com>
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 10:01:00 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Adrian Bunk <bunk@stusta.de> writes:
+
+>   Debian decides that Upstart is the default init system for jessie,
+>   but it's default desktop GNOME forces the installation of systemd.
+
+There are reasons I've left gnome behind...
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 18:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 18:39:04 GMT) (full text, mbox, link).

+ +

Message #4452 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 10:34:26 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I think there are the following three reasonable answers to Q1/Q2
+> taken together.
+
+> i.   Q1: Multiple in >jessie
+>      Q2: Requiring specific init is forbidden
+
+> ii.  Q1: Multiple in >jessie
+>      Q2: Requiring default init is permitted
+
+> iii. Q1: Single in jessie+1
+>      Q2: Requiring default init is permitted
+
+> Of these (ii) would cause the non-default inits to rot.  Unless anyone
+> thinks this is a useful option I don't think we should vote on it.
+
+ii is my preferred option.  I think it's the option that makes the most
+sense.  I don't agree that it will necessarily cause non-default inits to
+rot.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 18:42:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 18:42:07 GMT) (full text, mbox, link).

+ +

Message #4457 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 18:38:59 +0000
+
+
Russ Allbery writes ("Re: Bug#727708: call for votes on default Linux init system for jessie"):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > Of these (ii) would cause the non-default inits to rot.  Unless anyone
+> > thinks this is a useful option I don't think we should vote on it.
+> 
+> ii is my preferred option.  I think it's the option that makes the most
+> sense.  I don't agree that it will necessarily cause non-default inits to
+> rot.
+
+Do you agree with Russ and Bdale that it would be better not to
+address these questions in the TC decision ?  If so then I don't think
+we need to explore this line of conversation any further; it's only
+worth it if there is a form of words that you would prefer to saying
+nothing at all.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 18:42:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 18:42:10 GMT) (full text, mbox, link).

+ +

Message #4462 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 18:39:33 +0000
+
+
Ian Jackson writes ("Re: Bug#727708: call for votes on default Linux init system for jessie"):
+> Do you agree with Russ and Bdale that it would be better not to
+
+Wait, where did "Russ" come from there ?  I meant Keith.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 18:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 18:45:04 GMT) (full text, mbox, link).

+ +

Message #4467 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 10:43:04 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Russ Allbery writes:
+>> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+>>> Of these (ii) would cause the non-default inits to rot.  Unless anyone
+>>> thinks this is a useful option I don't think we should vote on it.
+
+>> ii is my preferred option.  I think it's the option that makes the most
+>> sense.  I don't agree that it will necessarily cause non-default inits
+>> to rot.
+
+> Do you agree with Russ and Bdale that it would be better not to address
+> these questions in the TC decision ?
+
+Yes, that's even better.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 19:09:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 19:09:09 GMT) (full text, mbox, link).

+ +

Message #4472 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 28 Jan 2014 11:05:18 -0800
+
+
On Tue, 28 Jan 2014, Ian Jackson wrote:
+> Don Armstrong writes ("Bug#727708: call for votes on default Linux init system for jessie"):
+> > On Tue, 28 Jan 2014, Ian Jackson wrote:
+> > > >    M. Debian intends to support multiple init systems, for the
+> > > >       foreseeable future, and so long as their respective communities
+> > > >       and code remain healthy.  Software outside of an init system's
+> > > >       implementation may not require a specific init system to be
+> > > >       pid 1, although degraded operation is tolerable.
+> > 
+
+[...]
+
+> Is there some rephrasing of this paragraph which would persuade you to
+> put it ahead of a ballot option with the paragraph entirely deleted ?
+
+Changing the last sentence to 
+
+  Where feasible, software should interoperate with non-default init
+  systems; maintainers are encouraged to accept technically sound
+  patches to enable interoperation, even if it results in degraded
+  operation.
+
+would be enough for me, but that basically makes the entire sentence
+advisory, which probably doesn't satisfy your concerns.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+You think to yourself, hey, it's a test tube, for God's sake. Pretty
+soon, though, the rush from a test tube isn't enough. You want to
+experiment more and more. Then before you know it, you're laying in
+the corner of a lab somewhere with a Soxhlet apparatus in one hand,
+a three neck flask in the other, strung out and begging for grant
+money.
+ -- Tim Mitchell, 1994 Ig Nobel Chemistry Prize Speech
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 19:15:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Neil McGovern <neilm@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 19:15:12 GMT) (full text, mbox, link).

+ +

Message #4477 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Neil McGovern <neilm@debian.org>
+
To: Don Armstrong <don@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 28 Jan 2014 19:14:36 +0000
+
+
[Message part 1 (text/plain, inline)]
+
Hi Don,
+
+On Tue, Jan 28, 2014 at 11:05:18AM -0800, Don Armstrong wrote:
+>   Where feasible, software should interoperate with non-default init
+>   systems; maintainers are encouraged to accept technically sound
+>   patches to enable interoperation, even if it results in degraded
+>   operation.
+> 
+
+Did you mean "degraded operation while running under the non-default
+init." or "degraded operation while running under the default init."?
+
+I suspect the former, but perhaps a wording tweak for clarity may be
+useful :)
+
+Neil
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 19:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 19:27:04 GMT) (full text, mbox, link).

+ +

Message #4482 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 28 Jan 2014 11:23:11 -0800
+
+
On Tue, 28 Jan 2014, Neil McGovern wrote:
+> On Tue, Jan 28, 2014 at 11:05:18AM -0800, Don Armstrong wrote:
+> >   Where feasible, software should interoperate with non-default init
+> >   systems; maintainers are encouraged to accept technically sound
+> >   patches to enable interoperation, even if it results in degraded
+> >   operation.
+> > 
+> 
+> Did you mean "degraded operation while running under the non-default
+> init." or "degraded operation while running under the default init."?
+
+The former. So :
+
+   Where feasible, software should interoperate with non-default init
+   systems; maintainers are encouraged to accept technically sound
+   patches to enable interoperation, even if it results in degraded
+   operation while running under the non-default init.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+If you find it impossible to believe that the universe didn't have a
+creator, why don't you find it impossible that your creator didn't
+have one either?
+ -- Anonymous Coward http://slashdot.org/comments.pl?sid=167556&cid=13970629
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 19:51:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 19:51:15 GMT) (full text, mbox, link).

+ +

Message #4487 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: Don Armstrong <don@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 28 Jan 2014 20:46:42 +0100
+
+
On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote:
+> On Tue, 28 Jan 2014, Neil McGovern wrote:
+> > On Tue, Jan 28, 2014 at 11:05:18AM -0800, Don Armstrong wrote:
+> > >   Where feasible, software should interoperate with non-default init
+> > >   systems; maintainers are encouraged to accept technically sound
+> > >   patches to enable interoperation, even if it results in degraded
+> > >   operation.
+> > > 
+> > 
+> > Did you mean "degraded operation while running under the non-default
+> > init." or "degraded operation while running under the default init."?
+> 
+> The former. So :
+> 
+>    Where feasible, software should interoperate with non-default init
+>    systems; maintainers are encouraged to accept technically sound
+>    patches to enable interoperation, even if it results in degraded
+>    operation while running under the non-default init.
+Maybe I'm dense...
+
+Scenario: Let's say that OpenRC is the new default init and in the
+meanwhile, Gnome has gained a dependency on systemd. A patch to
+support Upstart in Gnome is posted that partially breaks the
+functionality under systemd.
+
+By your wording, maintainers are encouraged to accept the patch.
+
+Zbyszek
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 20:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 20:09:04 GMT) (full text, mbox, link).

+ +

Message #4492 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 28 Jan 2014 12:08:19 -0800
+
+
On Tue, 28 Jan 2014, Zbigniew Jędrzejewski-Szmek wrote:
+> On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote:
+> > The former. So :
+> > 
+> >    Where feasible, software should interoperate with non-default init
+> >    systems; maintainers are encouraged to accept technically sound
+> >    patches to enable interoperation, even if it results in degraded
+> >    operation while running under the non-default init.
+>
+> Maybe I'm dense...
+> 
+> Scenario: Let's say that OpenRC is the new default init and in the
+> meanwhile, Gnome has gained a dependency on systemd. A patch to
+> support Upstart in Gnome is posted that partially breaks the
+> functionality under systemd.
+> 
+> By your wording, maintainers are encouraged to accept the patch.
+
+No. This was precisely the ambiguity which Neil (correctly) pointed out.
+Simply put, patches which reduced existing functionality while running
+under the default init (say, systemd), would not be technically sound.
+
+Instead, maintainers are encouraged to accept the patch even if it
+results in reduced functionality while running under the non-default
+init (say, upstart) in comparison to the default init (say, systemd).
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+I will not make any deals with you. I've resigned. I will not be
+pushed, filed, stamped, indexed, briefed, debriefed or numbered. My
+life is my own. I resign.
+ -- Patrick McGoohan as Number 6 in "The Prisoner"
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 20:24:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 20:24:07 GMT) (full text, mbox, link).

+ +

Message #4497 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Don Armstrong <don@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 28 Jan 2014 22:20:12 +0200
+
+
On Tue, Jan 28, 2014 at 12:08:19PM -0800, Don Armstrong wrote:
+> On Tue, 28 Jan 2014, Zbigniew Jędrzejewski-Szmek wrote:
+> > On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote:
+> > > The former. So :
+> > > 
+> > >    Where feasible, software should interoperate with non-default init
+> > >    systems; maintainers are encouraged to accept technically sound
+> > >    patches to enable interoperation, even if it results in degraded
+> > >    operation while running under the non-default init.
+> >
+> > Maybe I'm dense...
+> > 
+> > Scenario: Let's say that OpenRC is the new default init and in the
+> > meanwhile, Gnome has gained a dependency on systemd. A patch to
+> > support Upstart in Gnome is posted that partially breaks the
+> > functionality under systemd.
+> > 
+> > By your wording, maintainers are encouraged to accept the patch.
+> 
+> No. This was precisely the ambiguity which Neil (correctly) pointed out.
+> Simply put, patches which reduced existing functionality while running
+> under the default init (say, systemd), would not be technically sound.
+> 
+> Instead, maintainers are encouraged to accept the patch even if it
+> results in reduced functionality while running under the non-default
+> init (say, upstart) in comparison to the default init (say, systemd).
+
+That's a different case.
+
+Zbigniew was talking about a package that has a dependency on a
+*non*default init system.
+
+And for that the first question is whether such a dependency on a 
+*non*default init would be allowed at all.
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 20:51:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 20:51:10 GMT) (full text, mbox, link).

+ +

Message #4502 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 28 Jan 2014 12:49:43 -0800
+
+
On Tue, 28 Jan 2014, Adrian Bunk wrote:
+> Zbigniew was talking about a package that has a dependency on a
+> *non*default init system.
+
+Ah, OK. That's easily resolved with 
+
+    Where feasible, software should interoperate with non-default init
+    systems; maintainers are encouraged to accept technically sound
+    patches to enable interoperation, even if it results in degraded
+    operation while running under the init system the patch enables
+    interoperation with.
+
+> And for that the first question is whether such a dependency on a
+> *non*default init would be allowed at all.
+
+I'm deliberately avoiding even wading into this question, because
+delineating between packages whose design requires that they depend on a
+specific init system, packages which depend on a particular init system
+due to a lack of developer effort, and packages which depend on a
+particular init system for no good reason at all is hard.
+
+I'd much rather give some guidance (in the form of the above), and trust
+maintainers to do the right thing. The CTTE and/or the project can
+always intervene if necessary after the fact.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+"There are two major products that come out of Berkeley: LSD and UNIX.
+We don't believe this to be a coincidence."
+ -- Jeremy S. Anderson
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 20:54:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 20:54:05 GMT) (full text, mbox, link).

+ +

Message #4507 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 28 Jan 2014 22:51:31 +0200
+
+
On Tue, 2014-01-28 at 22:20 +0200, Adrian Bunk wrote:
+> On Tue, Jan 28, 2014 at 12:08:19PM -0800, Don Armstrong wrote:
+> > On Tue, 28 Jan 2014, Zbigniew Jędrzejewski-Szmek wrote:
+> > > On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote:
+> > > > The former. So :
+> > > > 
+> > > >    Where feasible, software should interoperate with non-default init
+> > > >    systems; maintainers are encouraged to accept technically sound
+> > > >    patches to enable interoperation, even if it results in degraded
+> > > >    operation while running under the non-default init.
+> > >
+> > > Maybe I'm dense...
+> > > 
+> > > Scenario: Let's say that OpenRC is the new default init and in the
+> > > meanwhile, Gnome has gained a dependency on systemd. A patch to
+> > > support Upstart in Gnome is posted that partially breaks the
+> > > functionality under systemd.
+> > > 
+> > > By your wording, maintainers are encouraged to accept the patch.
+> > 
+> > No. This was precisely the ambiguity which Neil (correctly) pointed out.
+> > Simply put, patches which reduced existing functionality while running
+> > under the default init (say, systemd), would not be technically sound.
+> > 
+> > Instead, maintainers are encouraged to accept the patch even if it
+> > results in reduced functionality while running under the non-default
+> > init (say, upstart) in comparison to the default init (say, systemd).
+> 
+> That's a different case.
+> 
+> Zbigniew was talking about a package that has a dependency on a
+> *non*default init system.
+> 
+> And for that the first question is whether such a dependency on a 
+> *non*default init would be allowed at all.
+
+Not really. What Zbigniew was talking about was whether the above
+wording would allow a patch enabling operation with system A to degrade
+existing functionality with *another* system B (whether B is actually a
+strict "dependency" does not seem that important). This depends on how
+you interpret "the non-default init"; Don obviously meant this to refer
+to the same init as the patch is for.
+
+I think this kind of possible ambiguity could be avoided by phrasing
+like "even if the patch only implements a degraded mode of operation
+under this system", to make it clear that the "degrade" does not refer
+to any functionality that existed _before_ the patch.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 21:24:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 21:24:10 GMT) (full text, mbox, link).

+ +

Message #4512 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Wed, 29 Jan 2014 07:21:43 +1000
+
+
On 28 January 2014 21:39, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
+> I don't want to pass a resolution specifying the default without also
+> answering the other two, related, contentious questions:
+>   Q1: Do we intend to support multiple systems long-term, or do we
+>   intend to settle on a single system, probably in jessie+1 ?
+
+FWIW, that seems overly prescriptive to me -- if we settle on systemd
+now, and as a result upstart stops getting maintained and systemfree
+gets written that uses the same config files but only works on FreeBSD
+and Hurd, maybe no one will want to maintain multiple init systems
+later. Conversely, maybe people get excited about some init system we
+don't pick as default for jessie and it becomes really awesome by the
+time jessie is out; why would we want to prevent it being available in
+Debian even if it's not ready to be default, or doesn't work with
+Gnome yet, or whatever?
+
+>   Q2: Is it OK for packages to depend on a specific init system as
+>   pid 1 ?
+
+I don't think that's the right question for the issue(s) at play here.
+
+From what I can tell, the important question isn't whether systemd or
+upstart happens to be pid 1, but rather whether certain interfaces
+(dbus, logind, potentially others) that are only (currently) provided
+by systemd are available on the system.
+
+That would make the question break down into something like:
+
+  Q2a: Is it OK for packages providing init systems to provide other
+APIs beyond just the minimum needed for starting/stopping services?
+
+  Q2b: If so, is it OK for packages requiring those APIs (such as
+logind) to just depend on the particular init system known to provide
+them (eg Depends: systemd)?
+
+There's a third related question that I don't think is particularly
+crucial, regarding the different ways of telling different init
+systems about your service:
+
+  Q2c: Is it OK for packages to provide a service start/stop
+description that is understandable by some but not all available init
+systems in Debian?
+
+After Steve's and Russ's comments in [0] and [1], and thinking about
+it some more, I'm inclined to think all those questions could
+reasonably be dealt with through the policy process, though I still
+think some non-binding advice from the tech ctte wouldn't be out of
+place.
+
+[0] https://lists.debian.org/debian-ctte/2014/01/msg00382.html
+[1] https://lists.debian.org/debian-ctte/2014/01/msg00383.html
+
+>      Q2: Requiring specific init is forbidden
+
+Note that this answer would preclude providing a package designed to,
+say, "duplicate aj's environment exactly, because it's awesome and all
+his friends want to just be able to apt-get install it and be just as
+cool as aj is". I don't think that's a win.
+
+Cheers,
+aj
+
+-- 
+Anthony Towns <aj@erisian.com.au>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 21:51:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Olav Vitters <ovitters@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 21:51:09 GMT) (full text, mbox, link).

+ +

Message #4517 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Olav Vitters <ovitters@gmail.com>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Tue, 28 Jan 2014 22:50:00 +0100
+
+
On Tue, Jan 28, 2014 at 07:34:56PM +0200, Adrian Bunk wrote:
+> On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote:
+> > On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette <joss@debian.org> wrote:
+> > > Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
+> > >> No. My question isn't about logind, but about using a user systemd
+> > >> session to supervise processes started by the session. IIRC both GNOME
+> > >> and KDE were mentioned to consider this feature.
+> > >
+> > > I wouldn't worry much about such features, at least not for jessie. They
+> > > will most likely be fallbacks, and in the unlikely case they are at
+> > > build time, we could always put the two binaries in the same package
+> > > with dynamic detection, thus working around this requirement.
+> > 
+> > Fallback is intended, so for near future you'd be ok. Longer term, I
+> > expect almost no maintenance to occur from GNOME side, so be prepared
+> > to handle the maintenance if nobody else does.
+> >...
+> 
+> The freeze for jessie will be in November 2014, so it will ship with
+> GNOME 3.14 (or earlier).
+> 
+> Am I reading your email correctly that can Debian assume that for the 
+> GNOME in jessie proper fallbacks will be in place, so that GNOME in 
+> jessie will work fine with init systems other than systemd?
+
+gnome-session will have a fallback for this in 3.14. Initially we
+assumed that gnome-session would go away totally, but seems even with
+systemd --user you'll still have a gnome-session around. It just does
+less in case of systemd.
+
+Note that I'm just talking about gnome-session. GNOME not under systemd
+does have it fair share of reduced functionality. Further, in my
+experience it was *way* more stable to either go for full systemd or
+always rely on the reduced functionality. The runtime detection of "is
+systemd running as PID 1" was IMO not very stable (and that wasn't just
+GNOME components, others as well). Though that was under Mageia and
+later on Gentoo provided various patches to improve it (but no idea how
+good the current state is or if we regressed anywhere).
+
+-- 
+Regards,
+Olav
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 28 Jan 2014 22:03:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to ChaosEsque Team <chaosesqueteam@yahoo.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 28 Jan 2014 22:03:10 GMT) (full text, mbox, link).

+ +

Message #4522 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: ChaosEsque Team <chaosesqueteam@yahoo.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems: We have to see it for what it is: Lennart/Linux OS.
+
Date: Tue, 28 Jan 2014 13:56:02 -0800 (PST)
+
+
We have to see it for what it is. Lennart Pottering and his acolytes
+who work within other projects are essentially forking Gnu/Linux and
+are creating LennartOS.
+
+What should be done is to follow their often spoken refrain: fork
+every project that relies on systemd, xyzkit, LennartStuff:
+create X.org-concrete (if they go the Lennart way (there's a patch now!))
+KDE-concrete, Gnome2 Gnome3-concrete. Security fixes would be
+applied, as-well as legitimate bug fixes (all these are often
+one to three liners). Otherwise the software would mostly retain
+its form. Something familiar, mature, stable.
+
+Remember: Software is much more an art form than a science. The way
+it interacts is a choice not a foregone conclusion.
+
+Lennart and his followers use the fallacy that software is a
+science to bully all of us into following their direction.
+
+A fork of (all but) linux is need now, it's already happening
+on Lennart's Side. We had better meet them in kind and protect our
+software system or be subsumed.
+
+
+*Those who want lennartOS could install package-lennart.
+**Those who want Gnu/Linux would install package or package-concrete.
+***When positions are irreconcilable, and paths diverge, a fork is necessary.
+***This is the case here. We need not our universe to be pulled out from
+***under us. We don't need conquering to the Lennart Way, just as the men
+***of pakistan, afghanistan, iraq, appaplachia, japan, do not need conquering
+***to the UK/american way.
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 00:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 00:09:04 GMT) (full text, mbox, link).

+ +

Message #4527 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 28 Jan 2014 19:05:01 -0500
+
+
On Tue, Jan 28, 2014 at 12:42 PM, Adrian Bunk wrote:
+> For anyone intending to make Debian the laughingstock of the open source
+> world, here is a good opportunity:
+>
+>   Debian decides that Upstart is the default init system for jessie,
+>   but it's default desktop GNOME forces the installation of systemd.
+
+What makes you think gnome is going to be the default?
+
+http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a=commitdiff;h=dfca406eb694e0ac00ea04b12fc912237e01c9b5
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 01:27:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 01:27:09 GMT) (full text, mbox, link).

+ +

Message #4532 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Tue, 28 Jan 2014 20:24:46 -0500
+
+
On Tue, Jan 28, 2014 at 9:57 AM, Thorsten Glaser wrote:
+> Michael Gilbert dixit:
+>
+>>Why not avoid impeding progress and just let gnome do what it needs to
+>>work the way it wants, which would involve depending on the right
+>
+> Excuse me, why is GNOME, specifically, being allowed to “do what it
+> wants”, in this case?
+
+gnome is simply an example, which makes sense to talk about given its
+apparent direction toward being systemd-only.
+
+Why exactly would it be harmful for the gnome island to be a systemd world?
+
+> Imagine other software with a more-or-less legitimate dependency on, meh idk, upstart for example.
+
+I don't see any problem with that either.  If someone were interested
+in creating "upstartwm", why get in their way?
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 01:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Peter Dolding <oiaohm@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 01:30:04 GMT) (full text, mbox, link).

+ +

Message #4537 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Peter Dolding <oiaohm@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Some how I think I might have a way to end this argument.
+
Date: Wed, 29 Jan 2014 11:27:37 +1000
+
+
Lets look at the problem little more broad than systemd vs upstart....
+the Linux kernel linked stuff.
+
+Freebsd the most intergrated init system is most likely going to be
+launchd or releation.
+
+https://wiki.freebsd.org/launchd
+
+Solaris Management Console is the most integrated init system with a
+Solaris kernel.  http://osdyson.org/ exists off to the side of debian
+at the moment due to debian sticking dominantly with sysvinit.
+
+The idea of porting upstart and systemd most likely can be given up
+on.  Since porting either to Freebsd or Solaris is most likely
+pointlessly.  The upstream supported in Freebsd and Solaris for there
+own init is going to be many times more current on their kernel
+feature support than any third party.
+
+Package maintainers don't want to have to create individual files per
+init system.  Add on the fact there will be multi init systems.   How
+to resolve the issue.   Unified generator solution that reads from a
+common file format and spits out the format the init system requires.
+
+Systemd does support generated SourcePath=  declare in Unit files.
+It would be great if upstart would add equal.  Yes this is where
+upstarts contributor agreement is a problem.
+
+There is no reason a SourcePath equal declare could not be added to
+existing LSB systemv init.
+
+Like it or not the author of Systemd is correct.  Its basically
+pointless porting init systems across kernels.   Init systems to work
+right have to end up kernel dependant to take advantage of platform
+particular security features.    Also including waffle defining all
+the unique bends for all the unique platforms like sysvinit did also
+made life more complex for administrators.
+
+Its time to bite the bullet.
+
+Systemd vs Upstart if you restrict to Linux only and number of
+supported Linux Kernel features systemd is clearly winning.
+
+Upstart major argument has be in theory portability to other
+platforms.   This is totally not an option.
+
+Without portablity in the init system it becomes how well does the
+init system intergrate with having its configuration files generated
+so package maintainers can create common file declaring what they need
+the init system todo for them.
+
+Objective package and init system dependency totally unlinked from
+each other.   Packages become dependant on particular versions of
+generators.
+
+Yes the problem here is another project is required.   Something that
+should be part of the standard processes.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 02:09:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Peter Dolding <oiaohm@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 02:09:10 GMT) (full text, mbox, link).

+ +

Message #4542 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Peter Dolding <oiaohm@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Re: Bug#727708: multiple init systems: We have to see it for what + it is: Lennart/Linux OS. Not.
+
Date: Wed, 29 Jan 2014 12:04:14 +1000
+
+
ChaosEsque Team <chaosesqueteam@yahoo.com>
+>> We have to see it for what it is. Lennart Pottering and his acolytes
+>> who work within other projects are essentially forking Gnu/Linux and
+>> are creating LennartOS.
+
+Debian is a multi kernel solution.  So solution has to deal with the
+fact all OS's are differenet.
+
+>> What should be done is to follow their often spoken refrain: fork
+>> every project that relies on systemd, xyzkit, LennartStuff:
+>> create X.org-concrete (if they go the Lennart way (there's a patch now!))
+>> KDE-concrete, Gnome2 Gnome3-concrete. Security fixes would be
+>> applied, as-well as legitimate bug fixes (all these are often
+>> one to three liners). Otherwise the software would mostly retain
+>> its form. Something familiar, mature, stable.
+
+Fork the kernel???  right we all know how successful this turns out
+for those making clones of Solaris.  Solaris clones have to go SMC
+they don't have a option of using a different init system.
+
+Sysvinit came on Linux by being lazy.
+
+Secure software is a science.  I am sick of those who say Software is
+more an art.  Saying software is a art is a nice universal excuse not
+todo quality control.
+
+Really the way systemd is going its going to be come like Solaris  and
+SMC not able to be split.   Launchd on Freebsd is also most likely
+going to become not able to be split.
+
+Forking every package that depends on systemd is pointless.
+Providing a solution where packages can be less tightly bound to
+systemd is the only way forwards to your problem.
+
+Future we need to be able to be able to release 1 package for systemd,
+smc and launchd at a min.  Sorting this out could also see debian
+packages directly installable on OS X.
+
+From the LCA2014 conference there was a  horribly porting deb packages
+onto rpm systems because the system could not be stopped to change OS.
+  The Linux world is horribly fragmented.   Art side is part the
+problem here.
+
+Yes we are going to see most likely a over reaction going the other way.
+
+Lets go over the key points of software.
+
+User interface design.  This is majority a science.  You create a
+theory you go and attempt to prove it wrong when you cannot this
+becomes acceptable wisdom to base interface on.
+User interface graphics.  This is part standards and part art.
+Quality Control.  This is again a science.  Methods and procedures.
+
+Software is closer to maths and science than art.   Yes there is a old
+believe that software is art but anyone holding that idea normally
+ends up making suspect software.
+
+Science does not give you the right to bully.  Lennart is laying down
+a challenge who is going to step up.   Those attempting to stay in
+past on sysvinit are waking up its not possible.
+
+There are still those following advancing Linux without following
+Lennart.   http://linux.conf.au/schedule/30076/view_talk  Project
+hammerhead for one.
+
+Something that is required is how to make more packages and
+applications not distribution bound or init system bound.  Generator
+for init files is one of the ways out.   Libraries wrapping particular
+feature requests is another.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 02:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 02:24:04 GMT) (full text, mbox, link).

+ +

Message #4547 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems: We have to see it for what it is: Lennart/Linux OS. Not.
+
Date: Tue, 28 Jan 2014 18:21:12 -0800
+
+
These discussions of grand schemes to change the future of Linux
+development are potentially interesting in the right forum, but this isn't
+the right forum.  The goal of this discussion is to decide what Debian is
+going to do for jessie, with some discussion of what Debian might do after
+jessie.  There are many possible visions of the future, but right now we
+have to decide what Debian is going to do in the near term.
+
+It's basically impossible to translate grand schemes for forking large
+amounts of software, changing major development models, or the like into
+any sort of practically achievable advice for the Debian project in the
+timeframe of the next release.  Similarly, the concept of init
+configuration generators has come up in this discussion before, but a
+working set of generators and universal syntax does not currently exist,
+and we can't adopt something that doesn't exist.
+
+If you all find these ideas interesting, I encourage you to go tackle
+them!  Write code, test code, make the world a better place, and give
+people more options.  I'm sure there are others who would be interested in
+discussing them with you, and possibly collaborating.
+
+But the role of the Technical Committee on these sorts of discussions is
+reluctant and trailing-edge, not visionary and bleeding-edge.  We're a
+decision-making body of last resort called on to make decisions when the
+project needs to have a decision and the correct option isn't clear.  As a
+result, we have to deal with the practical, concrete, and currently
+available.  We are neither empowered to, nor in a position to, set grand
+design strategies for what other developers might work on, only to decide
+how to integrate the code we have available to us now in places where the
+right decision is not clear.
+
+This bug discussion is already quite long and protracted, and it would be
+easier for those following it if strategic discussions of how to drive the
+future of Linux could be moved to other, more appropriate forums where
+they have a better chance of finding their audience.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 08:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to ChaosEsque Team <chaosesqueteam@yahoo.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 08:06:04 GMT) (full text, mbox, link).

+ +

Message #4552 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: ChaosEsque Team <chaosesqueteam@yahoo.com>
+
To: 727708@bugs.debian.org
+
Cc: oiaohm@gmail.com
+
Subject: Re: Re: Re: Bug#727708: multiple init systems: We have to see it for what it is: Lennart/Linux OS. Yes it is.
+
Date: Wed, 29 Jan 2014 00:00:41 -0800 (PST)
+
+
Ah, you're a systemd acolyte. You smugly proclaim that it is USELESS to resist!
+::
+>Forking every package that depends on systemd is pointless.
+
+
+If you read what I wrote you would see that I said fork everything below/or above
+(whatever "software stack" direction you believe in) the linux kernel,
+and maintain them in a very stable form, applying security patches and bug fixes.
+::
+>Fork the kernel???  right we all know how successful this turns out
+>for those making clones of Solaris.  Solaris clones have to go SMC
+>they don't have a option of using a different init system.
+
+Personally I do not care what you or Lennart are sick of (which includes
+unix philosophy, as-well as any people who are learned in the unix 
+way). I do not want to learn your new little computer religion (getting
+bigger every day). There are social consequences to your hostile 
+internal fork of the Gnu/Linux system. You and Lennart do not give a
+damn about those consequences for other people.
+::
+>Secure software is a science.  I am sick of those who say Software is
+>more an art.  Saying software is a art is a nice universal excuse not
+>todo quality control.
+
+Anyway, one way to have secure software is to freeze development 
+at some mature version, and then do an audit and focus on fixing
+all the little niggling bugs and failings. Not that you windows programmer
+refugees would know anything about that. You're a flavor of the month
+or half-decade kind of people. And you are attacking the linux system
+from the inside. You like building on shifting sands, and you like it
+even more to force us all to live on the beach with you.
+
+If you want secure software, it's called the grsecurity patch and PAX, not systemd.
+
+>Sysvinit came on Linux by being lazy.
+It came on linux by doing one thing and doing it well: it starts various processes
+the system administrator wants started, and then it gets out of the way.
+Very nice and secure design paradigm: does few things, has few lines of code.
+
+>The Linux world is horribly fragmented.
+Good. It is called choice. Guess what: the hobbyists do not exist to promote or
+expand that religion in your mind called "Linux" or "Desktop Linux" or "The Universal Faith".
+You think if you could just FORCE the Linux world to standardize on YOUR 
+software and YOUR interfaces then they would work more efficiently towards YOUR
+goals (of supreme Desktop OS or whatever computer religion/heresy you're into.)
+
+As an aside: you know once upon a time there was little fragmentation in the init system area.
+It was pretty much a non issue and no app cared what init system you ran.
+Lennart and friends changed all that.
+YOU are creating the DIVISION here, and YOU have the GALL to put blaim elsewhere.
+YOU (Lennart and co) are UPROOTING what we all know and love, and telling us
+to basically go a FCK ourselves if we do not like it ("Progress" "Go and fork everything *SNCR*")
+
+Fsck Lennart. Fsck every abomination he foists onto us with gusto.
+"It's free, it's all free software, what's the problem" So is a bullet, but I don't want one!
+
+No one needs to "step up to the plate": Our current systems work fine for us, we do 
+not want to be forced (and yes making every project you and yours infiltrate depend
+on systemd does equal force in the software world)
+
+Watch Lennart be a do chbag to the good man who is trying to give a presentation;
+even jumps up on stage at the end. You can feel the dejected feel the man has
+as he rushes through his carefully prepared presentation because Lennart got 
+a mic and took up much of the allotted time.
+
+www.youtube.com/watch?v=_ERAXJj142o
+
+SystemD and the rest of Lennarts garbage (PulseAudio) is a hostile takeover
+of what was once a nice unix like OS, by Lennart Pottering and his followers.
+
+He loves the attention, we have to pay attention to every damn thing he does,
+and learn HIS new way of doing things. He is a jackass, and a smug 
+passive-aggressive totalitarian, as are many of his adoring followers.
+
+
+>Software is closer to maths and science than art.   Yes there is a old
+>believe that software is art but anyone holding that idea normally
+>ends up making suspect software.
+
+Yep, if we don't want systemd and pulseaudio so on and so forth,
+not only are we suspect, but the software we write is suspect!
+
+You Lennart guys always have some bullsht aside like this to
+degenerate your detractors. There's always something wrong with
+us: Just look at *this *bulleted *list *of *features. How could anyone
+disagree with that, they must be insane!
+
+In math and science there are often only a handful of ways to 
+do a particular thing. In art and religion there are infinite possibilities
+and choices: software is the same. Ofcourse all my software 
+is suspect, as am I. Perhaps I'm a heretic and should be burned.
+
+Go to tartarus, and bring Lennart and his religion with you.
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 08:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to ChaosEsque Team <chaosesqueteam@yahoo.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 08:27:05 GMT) (full text, mbox, link).

+ +

Message #4557 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: ChaosEsque Team <chaosesqueteam@yahoo.com>
+
To: 727708@bugs.debian.org
+
Cc: rra@debian.org
+
Subject: Re: Bug#727708: multiple init systems: We have to see it for what it is: Lennart/Linux OS. Not.
+
Date: Wed, 29 Jan 2014 00:20:19 -0800 (PST)
+
+
>This bug discussion is already quite long and protracted, and it would be
+>easier for those following it if strategic discussions of how to drive the
+>future of Linux could be moved to other, more appropriate forums where
+>they have a better chance of finding their audience.
+
+It's either Lennarts way or the highway.
+He and his have declared the unix way dead, his fanboy developers
+join other pivotal projects and subvert them from the inside.
+
+>But the role of the Technical Committee on these sorts of discussions is
+>reluctant and trailing-edge, not visionary and bleeding-edge.  We're a
+>decision-making body of last resort called on to make decisions when the
+>project needs to have a decision and the correct option isn't clear.  As a
+>result, we have to deal with the practical, concrete, and currently
+>available.  We are neither empowered to, nor in a position to, set grand
+>design strategies for what other developers might work on, only to decide
+>how to integrate the code we have available to us now in places where the
+>right decision is not clear.
+
+I wish the "bleeding edge" trail-blazing crap Lennart and crew stuff down our
+throats was rejected. Virtually all of his followers say that systemd must be
+the one true way or be prepared to go and fork all the projects that "rely"
+on it now (and in the future). Maybe that should be done.
+
+Their idea of a universal operating system is one where all opposition is 
+crushed. Aka europe a few centuries ago.
+
+For the record: I have forked opensource projects at points where they started
+removing features or went in another direction, or had an as hole of a developer
+take over the project and pretty much become king of it (the king of NO). These
+are and were videogame projects so I guess aren't relevant. But to the "go
+and fork it"... yea I've done it. Turns out fine. I got a concrete base, they go
+off into loopy land. When they fix bugs or security issues I back port the few
+lines manually.
+
+Aside:
+Those who have a userspace kernel to compete with the real linux kernel, and 
+feel we must all use it, do not want to hear reasons why we shouldn't be forced
+to use it:
+"Just fuck off, this bug has already enough crap even without your fanatic bullshit."
+--Ondřej Surý ondrej@sury.org
+
+Yea, I'd better shut up.
+
+Honestly. I, and many many many others, do NOT WANT SYSTEMD.
+We do not want to be forced or cajoled into using it.
+NOR do we want to be PUNISHED for not using it.
+"heheh yea you don't have to use it, but nothing will work on your system lolz hahhahah!"
+
+The systemd people seem to hate freedom and choice. They seem to be 
+totalitarians. Why must we be forced to use their "software stack"
+Why do we have to accept their tendrils needlessly corrupting every 
+free-software project that is at the "core" of Gnu/Linux?
+
+Alot of the software is great as-is. How about keeping it pre systemd infection.
+Let the systemd church have it's own system. Please do not make it hard
+for us to have ours separate from them. They are taking over everything
+that is good in linux, and they do not respect anyone.
+
+	
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 08:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Emilio Pozuelo Monfort <pochu@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 08:45:04 GMT) (full text, mbox, link).

+ +

Message #4562 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Emilio Pozuelo Monfort <pochu@debian.org>
+
To: ChaosEsque Team <chaosesqueteam@yahoo.com>, 727708@bugs.debian.org
+
Cc: oiaohm@gmail.com, owner@bugs.debian.org
+
Subject: Re: Bug#727708: Re: Re: Bug#727708: multiple init systems: We have + to see it for what it is: Lennart/Linux OS. Yes it is.
+
Date: Wed, 29 Jan 2014 09:41:06 +0100
+
+
On 29/01/14 09:00, ChaosEsque Team wrote:
+> Ah, you're a systemd acolyte. You smugly proclaim that it is USELESS to resist!
+> ::
+>> Forking every package that depends on systemd is pointless.
+> 
+> 
+> If you read what I wrote
+
+Nobody read what you wrote because it's nonsense. Please stop it now.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 09:09:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 09:09:05 GMT) (full text, mbox, link).

+ +

Message #4567 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: Olav Vitters <ovitters@gmail.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 10:05:22 +0100
+
+
Le mardi 28 janvier 2014 à 19:34 +0200, Adrian Bunk a écrit : 
+> On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote:
+> > On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette <joss@debian.org> wrote:
+> > > Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
+> > >> No. My question isn't about logind, but about using a user systemd
+> > >> session to supervise processes started by the session. IIRC both GNOME
+> > >> and KDE were mentioned to consider this feature.
+> > >
+> > > I wouldn't worry much about such features, at least not for jessie. They
+> > > will most likely be fallbacks, and in the unlikely case they are at
+> > > build time, we could always put the two binaries in the same package
+> > > with dynamic detection, thus working around this requirement.
+> > 
+> > Fallback is intended, so for near future you'd be ok. Longer term, I
+> > expect almost no maintenance to occur from GNOME side, so be prepared
+> > to handle the maintenance if nobody else does.
+> >...
+> 
+> The freeze for jessie will be in November 2014, so it will ship with
+> GNOME 3.14 (or earlier).
+> 
+> Am I reading your email correctly that can Debian assume that for the 
+> GNOME in jessie proper fallbacks will be in place, so that GNOME in 
+> jessie will work fine with init systems other than systemd?
+
+No, you are not. There are several features in systemd that GNOME uses.
+One of them is user sessions, for which there will indeed be a fallback
+in place. But it is not the only one.
+
+Cheers,
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 10:45:16 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to ChaosEsque Team <chaosesqueteam@yahoo.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 10:45:16 GMT) (full text, mbox, link).

+ +

Message #4572 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: ChaosEsque Team <chaosesqueteam@yahoo.com>
+
To: 727708@bugs.debian.org, Emilio Pozuelo Monfort <pochu@debian.org>
+
Cc: oiaohm@gmail.com, owner@bugs.debian.org
+
Subject: Re: Bug#727708: Re: Re: Bug#727708: multiple init systems: We have to see it for what it is: Lennart/Linux OS. Yes it is.
+
Date: Wed, 29 Jan 2014 02:41:13 -0800 (PST)
+
+
Not wanting to have to learn the flavor of the month, then relearn the new flavor of the month after that, and relearn the next flavor of the month is nonsense, gotcha.
+
+And anyone who disagrees strongly with being forced to use systemd is a troll. Yep.
+
+Wanting some stability in things, and voicing this opinion is forbidden.
+Showing displeasure at the attempt to coopt everything to use and then rely
+on systemd... that's just crazy.
+
+Notice how the SystemD supporters reacted to the idea of having choice of init system earlier:
+a (very polite, as things must be) "no". When other packages come into debian, they 
+don't tend to remove other packages that do similar things. Not so with systemd.
+SystemD is a SYSTEM. And we must all sign up for it. Out with the old, in with the new, so
+on and so on.
+
+Lennart Pottering is to Linux what Bill Gates was to the use of academic computer systems in the 80s. 
+>Dear BTS admins,
+
+>this troll has been polluting the already very long bug lof of #727708,
+>and has apparently no interest in stopping after Russ already told him
+>to stop.
+
+>Could you please consider blocking him from the BTS?
+
+>Thanks,
+>-- 
+>.''`.        Josselin Mouette
+--------------------------------------------
+On Wed, 1/29/14, Emilio Pozuelo Monfort <pochu@debian.org> wrote:
+
+ Subject: Re: Bug#727708: Re: Re: Bug#727708: multiple init systems: We have to see it for what it is: Lennart/Linux OS. Yes it is.
+ To: "ChaosEsque Team" <chaosesqueteam@yahoo.com>, 727708@bugs.debian.org
+ Cc: oiaohm@gmail.com, owner@bugs.debian.org
+ Date: Wednesday, January 29, 2014, 12:41 AM
+ 
+ On 29/01/14 09:00, ChaosEsque Team
+ wrote:
+ > Ah, you're a systemd acolyte. You smugly proclaim that
+ it is USELESS to resist!
+ > ::
+ >> Forking every package that depends on systemd is
+ pointless.
+ > 
+ > 
+ > If you read what I wrote
+ 
+ Nobody read what you wrote because it's nonsense. Please
+ stop it now.
+ 
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 11:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 11:15:04 GMT) (full text, mbox, link).

+ +

Message #4577 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Wed, 29 Jan 2014 11:13:33 +0000
+
+
On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
+> On 28 January 2014 21:39, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
+> > I don't want to pass a resolution specifying the default without also
+> > answering the other two, related, contentious questions:
+> >   Q1: Do we intend to support multiple systems long-term, or do we
+> >   intend to settle on a single system, probably in jessie+1 ?
+> 
+> FWIW, that seems overly prescriptive to me -- if we settle on systemd
+> now, and as a result upstart stops getting maintained and systemfree
+> gets written that uses the same config files but only works on FreeBSD
+> and Hurd, maybe no one will want to maintain multiple init systems
+> later.
+
+Perhaps a better phrasing would be something like "remain open to
+supporting multiple init systems as long as they are actively
+maintained".
+
+> Conversely, maybe people get excited about some init system we
+> don't pick as default for jessie and it becomes really awesome by the
+> time jessie is out; why would we want to prevent it being available in
+> Debian even if it's not ready to be default, or doesn't work with
+> Gnome yet, or whatever?
+
+(I don't think I can suggest better wording for the "single" options as
+they aren't ones I favour.)
+
+> >   Q2: Is it OK for packages to depend on a specific init system as
+> >   pid 1 ?
+> 
+> I don't think that's the right question for the issue(s) at play here.
+> 
+> >From what I can tell, the important question isn't whether systemd or
+> upstart happens to be pid 1, but rather whether certain interfaces
+> (dbus, logind, potentially others) that are only (currently) provided
+> by systemd are available on the system.
+
+That's certainly the principal issue for e.g. GNOME.  But I think it's
+reasonable to anticipate that some maintainers might want to drop
+support in their service packages for init systems which they don't
+favour and which aren't the default; one can reasonably take different
+views on whether that's appropriate, and I think guidance from the
+committee would be useful.
+
+I agree with you that it's worth breaking it down into the matters of
+service specifications (which for the most part have resisted attempts
+to implement translation layers) and other APIs (which have a better
+track record here).
+
+>   Q2a: Is it OK for packages providing init systems to provide other
+> APIs beyond just the minimum needed for starting/stopping services?
+
+We might disagree on the extent, perhaps, but I doubt anyone on the
+committee would vote against this in its general form; both systemd and
+upstart implement interfaces beyond the bare minimum, though upstart
+certainly takes a more minimalist tack.
+
+> After Steve's and Russ's comments in [0] and [1], and thinking about
+> it some more, I'm inclined to think all those questions could
+> reasonably be dealt with through the policy process, though I still
+> think some non-binding advice from the tech ctte wouldn't be out of
+> place.
+
+I certainly don't think we should get into the specifics of how things
+should be laid out, but the general direction is non-obvious and
+important.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 17:03:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 17:03:05 GMT) (full text, mbox, link).

+ +

Message #4582 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Michael Gilbert <mgilbert@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Wed, 29 Jan 2014 19:01:54 +0200
+
+
On Tue, Jan 28, 2014 at 07:05:01PM -0500, Michael Gilbert wrote:
+> On Tue, Jan 28, 2014 at 12:42 PM, Adrian Bunk wrote:
+> > For anyone intending to make Debian the laughingstock of the open source
+> > world, here is a good opportunity:
+> >
+> >   Debian decides that Upstart is the default init system for jessie,
+> >   but it's default desktop GNOME forces the installation of systemd.
+> 
+> What makes you think gnome is going to be the default?
+> 
+> http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a=commitdiff;h=dfca406eb694e0ac00ea04b12fc912237e01c9b5
+
+Read the text in debian/changelog that is there - the final decision 
+will be made in August (or later).
+
+I was sarcastically describing a worst-case scenario that is not 
+completely impossible - in reality I would expect enough sanity
+in Debian to ensure that something depending on a non-default
+init system cannot be part of a default installation.
+
+> Best wishes,
+> Mike
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 17:03:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 17:03:08 GMT) (full text, mbox, link).

+ +

Message #4587 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Olav Vitters <ovitters@gmail.com>
+
Cc: 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 19:02:19 +0200
+
+
On Tue, Jan 28, 2014 at 10:50:00PM +0100, Olav Vitters wrote:
+>...
+> Further, in my
+> experience it was *way* more stable to either go for full systemd or
+> always rely on the reduced functionality. The runtime detection of "is
+> systemd running as PID 1" was IMO not very stable (and that wasn't just
+> GNOME components, others as well). Though that was under Mageia and
+> later on Gentoo provided various patches to improve it (but no idea how
+> good the current state is or if we regressed anywhere).
+
+I'd guess the main reason for this is that distributions usually support 
+only one init system so the runtime detection rarely gets tested, and if 
+Debian would support multiple init systems such issues would get sorted 
+out quickly.
+
+> Regards,
+> Olav
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 17:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 17:06:04 GMT) (full text, mbox, link).

+ +

Message #4592 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Cc: Olav Vitters <ovitters@gmail.com>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 19:03:51 +0200
+
+
On Wed, Jan 29, 2014 at 10:05:22AM +0100, Josselin Mouette wrote:
+> Le mardi 28 janvier 2014 à 19:34 +0200, Adrian Bunk a écrit : 
+> > On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote:
+> > > On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette <joss@debian.org> wrote:
+> > > > Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
+> > > >> No. My question isn't about logind, but about using a user systemd
+> > > >> session to supervise processes started by the session. IIRC both GNOME
+> > > >> and KDE were mentioned to consider this feature.
+> > > >
+> > > > I wouldn't worry much about such features, at least not for jessie. They
+> > > > will most likely be fallbacks, and in the unlikely case they are at
+> > > > build time, we could always put the two binaries in the same package
+> > > > with dynamic detection, thus working around this requirement.
+> > > 
+> > > Fallback is intended, so for near future you'd be ok. Longer term, I
+> > > expect almost no maintenance to occur from GNOME side, so be prepared
+> > > to handle the maintenance if nobody else does.
+> > >...
+> > 
+> > The freeze for jessie will be in November 2014, so it will ship with
+> > GNOME 3.14 (or earlier).
+> > 
+> > Am I reading your email correctly that can Debian assume that for the 
+> > GNOME in jessie proper fallbacks will be in place, so that GNOME in 
+> > jessie will work fine with init systems other than systemd?
+> 
+> No, you are not. There are several features in systemd that GNOME uses.
+> One of them is user sessions, for which there will indeed be a fallback
+> in place. But it is not the only one.
+
+Can you provide a list of features without a fallback in place?
+
+
+Assuming jessie will support multiple init systems, why would GNOME need 
+a dependency on systemd?
+
+I fully get the point that in such a scenario some GNOME packages would 
+have a *Suggests* on systemd-sysv (no matter whether it's the default
+or not) - but do they really need a dependency?
+
+Part of what I am trying to understand is the scope of problems a 
+theoretical scenario "a new installation of jessie installs the default 
+desktop GNOME and the default init system sysvinit [1]" would produce.
+
+Would making any init system other than systemd the default for jessie 
+automatically exclude GNOME from being considered as an option for the 
+default desktop in jessie?
+
+
+> Cheers,
+
+cu
+Adrian
+
+[1] or upstart or OpenRC
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 17:24:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 17:24:05 GMT) (full text, mbox, link).

+ +

Message #4597 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: Adrian Bunk <bunk@stusta.de>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Wed, 29 Jan 2014 17:20:39 +0000
+
+
On 19:01, Adrian Bunk wrote:
+> On Tue, Jan 28, 2014 at 07:05:01PM -0500, Michael Gilbert wrote:
+> > What makes you think gnome is going to be the default?
+> > 
+> > http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a=commitdiff;h=dfca406eb694e0ac00ea04b12fc912237e01c9b5
+> 
+> Read the text in debian/changelog that is there - the final decision 
+> will be made in August (or later).
+> 
+> I was sarcastically describing a worst-case scenario that is not 
+> completely impossible - in reality I would expect enough sanity
+> in Debian to ensure that something depending on a non-default
+> init system cannot be part of a default installation.
+
+I'd expect Debian GNOME install media would still give a GNOME desktop
+by default, Debian KDE disc gives you KDE, etc.
+
+Would it be crazy to suggest putting the preferred init system
+in the 'task'?  A Debian GNOME install would likely install systemd,
+otherwise it could be something else.
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 17:45:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 17:45:11 GMT) (full text, mbox, link).

+ +

Message #4602 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org, Olav Vitters <ovitters@gmail.com>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 18:41:11 +0100
+
+
Le mercredi 29 janvier 2014 à 19:03 +0200, Adrian Bunk a écrit : 
+> > No, you are not. There are several features in systemd that GNOME uses.
+> > One of them is user sessions, for which there will indeed be a fallback
+> > in place. But it is not the only one.
+> 
+> Can you provide a list of features without a fallback in place?
+
+At least logind, timedated, hostnamed, localed, the boot control
+interfaces. With a very widespread level of failure depending on the
+unavailable interface.
+
+> Assuming jessie will support multiple init systems, why would GNOME need 
+> a dependency on systemd?
+
+Because it needs logind.
+https://lists.debian.org/debian-ctte/2014/01/msg00360.html
+
+> Would making any init system other than systemd the default for jessie 
+> automatically exclude GNOME from being considered as an option for the 
+> default desktop in jessie?
+
+There are solutions for a non-systemd init. They are technically wrong,
+but they are realistic (basically it means using logind v204). But there
+are no realistic solutions for having GNOME support multiple init
+systems in jessie.
+
+Cheers,
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 18:03:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 18:03:13 GMT) (full text, mbox, link).

+ +

Message #4607 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Josselin Mouette <joss@debian.org>
+
Cc: 727708@bugs.debian.org, Olav Vitters <ovitters@gmail.com>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 20:00:34 +0200
+
+
On Wed, Jan 29, 2014 at 06:41:11PM +0100, Josselin Mouette wrote:
+> Le mercredi 29 janvier 2014 à 19:03 +0200, Adrian Bunk a écrit : 
+>...
+> > Assuming jessie will support multiple init systems, why would GNOME need 
+> > a dependency on systemd?
+> 
+> Because it needs logind.
+> https://lists.debian.org/debian-ctte/2014/01/msg00360.html
+>...
+
+You wrote there
+  I also have to insist that GNOME 3.10+ *needs* a working logind even for
+  basic functionality
+
+What Olav wrote sounds quite different.
+
+What *basic functionality* exactly is missing in GNOME 3.10 without logind?
+
+Note that I am not referring to bugs that are not yet sorted out like
+  * Switch from consolekit to systemd-logind sessions. For some reason
+    gnome-shell 3.10 unlocking fails with consolekit...
+3 months ago in gdm3 - I am referring to basic functionality that is 
+simply missing in GNOME 3.10 without logind.
+
+> Cheers,
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 18:30:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 18:30:12 GMT) (full text, mbox, link).

+ +

Message #4612 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org, Olav Vitters <ovitters@gmail.com>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 19:17:29 +0100
+
+
Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit : 
+> What *basic functionality* exactly is missing in GNOME 3.10 without logind?
+> 
+> Note that I am not referring to bugs that are not yet sorted out like
+>   * Switch from consolekit to systemd-logind sessions. For some reason
+>     gnome-shell 3.10 unlocking fails with consolekit...
+> 3 months ago in gdm3 - I am referring to basic functionality that is 
+> simply missing in GNOME 3.10 without logind.
+
+You have the answer to your own question above. Unlocking the screen
+sounds like pretty basic functionality.
+
+Gnome-shell uses GDM for screen locking, and GDM heavily relies on
+logind nowadays. There is fallback code that uses ConsoleKit, but it has
+been untested for several major releases, and now fails even for trivial
+things. Add to that the fact that ConsoleKit itself has been
+unmaintained for quite some time, making it unsuitable for a new stable
+release that needs maintenance for several more years
+
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 18:45:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 18:45:05 GMT) (full text, mbox, link).

+ +

Message #4617 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Josselin Mouette <joss@debian.org>
+
Cc: 727708@bugs.debian.org, Olav Vitters <ovitters@gmail.com>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 20:43:37 +0200
+
+
On Wed, Jan 29, 2014 at 07:17:29PM +0100, Josselin Mouette wrote:
+> Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit : 
+> > What *basic functionality* exactly is missing in GNOME 3.10 without logind?
+> > 
+> > Note that I am not referring to bugs that are not yet sorted out like
+> >   * Switch from consolekit to systemd-logind sessions. For some reason
+> >     gnome-shell 3.10 unlocking fails with consolekit...
+> > 3 months ago in gdm3 - I am referring to basic functionality that is 
+> > simply missing in GNOME 3.10 without logind.
+> 
+> You have the answer to your own question above. Unlocking the screen
+> sounds like pretty basic functionality.
+
+Your statement was
+  I also have to insist that GNOME 3.10+ *needs* a working logind even for
+  basic functionality
+
+Are you saying that there are only some bugs to get sorted out for using 
+GNOME 3.10 without logind, or is there a fundamental technical reason
+why some *basic functionality* (which?) cannot be made working in
+GNOME 3.10 without logind?
+
+
+>...
+> Add to that the fact that ConsoleKit itself has been
+> unmaintained for quite some time, making it unsuitable for a new stable
+> release that needs maintenance for several more years
+
+Debian is anyway not providing much maintenance apart from security 
+updates for stable, so there is no real problem here for jessie.
+
+And for security fixes, companies like Red Hat are anyway committed to
+provide these for ConsoleKit for their products until around 5 years 
+*after* Debian will have dropped security support for jessie.[1]
+
+cu
+Adrian
+
+[1] the announced End of Extended Life Cycle for
+    Red Hat Enterprise Linux 6 is Q4 2023
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 19:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 19:09:04 GMT) (full text, mbox, link).

+ +

Message #4622 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 20:05:21 +0100
+
+
Le mercredi 29 janvier 2014 à 20:43 +0200, Adrian Bunk a écrit :
+> > You have the answer to your own question above. Unlocking the screen
+> > sounds like pretty basic functionality.
+> 
+> Your statement was
+>   I also have to insist that GNOME 3.10+ *needs* a working logind even for
+>   basic functionality
+
+My bad. I was under the impression you wanted a serious discussion.
+Sorry for contributing to the noise, everyone.
+
+-- 
+.''`.      Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 19:30:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 19:30:12 GMT) (full text, mbox, link).

+ +

Message #4627 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>, Olav Vitters <ovitters@gmail.com>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 11:27:53 -0800
+
+
Adrian Bunk <bunk@stusta.de> writes:
+> On Wed, Jan 29, 2014 at 07:17:29PM +0100, Josselin Mouette wrote:
+>> Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit : 
+
+>>> What *basic functionality* exactly is missing in GNOME 3.10 without
+>>> logind?
+
+>>> Note that I am not referring to bugs that are not yet sorted out like
+>>>   * Switch from consolekit to systemd-logind sessions. For some reason
+>>>     gnome-shell 3.10 unlocking fails with consolekit...
+>>> 3 months ago in gdm3 - I am referring to basic functionality that is 
+>>> simply missing in GNOME 3.10 without logind.
+
+>> You have the answer to your own question above. Unlocking the screen
+>> sounds like pretty basic functionality.
+
+> Your statement was
+>   I also have to insist that GNOME 3.10+ *needs* a working logind even for
+>   basic functionality
+
+> Are you saying that there are only some bugs to get sorted out for using 
+> GNOME 3.10 without logind, or is there a fundamental technical reason
+> why some *basic functionality* (which?) cannot be made working in
+> GNOME 3.10 without logind?
+
+I'm still wondering if maybe there's just a communication failure here, so
+let me try one more round.
+
+My understanding of what Josselin is saying is that GNOME's ConsoleKit
+support is effectively unmaintained and unsupported upstream, as is
+ConsoleKit itself.  The consequences of that are starting to show in a
+variety of unfixed bugs.
+
+In one sense, that's "just" bugs to be sorted out.  However, they're
+upstream bugs in code that upstream appears to no longer be interested in
+supporting, and they're bugs that the Debian GNOME maintainers are
+unenthused about trying to fix, since that would effectively require
+taking over maintenance of the ConsoleKit code upstream.  (Not to mention
+that the logind code path appears to be technically much better and have a
+much stronger future, so it's hard to get motivated to work on the
+ConsoleKit code.)
+
+In other words, they're bugs with no resources currently assigned.  Note
+that things like screen lock have security implications, so the jessie
+stable lifetime *is* important for this code.  Maintaining it properly
+would require confidence that we would be able to identify and fix
+security issues in the GNOME code and in ConsoleKit through the jessie
+supported lifecycle.
+
+Obviously, if resources appear, that changes the situation, but I think
+the GNOME maintainers are understandably wary of such approaches as
+someone taking a week and fixing all the currently known bugs and then
+moving on to other things, since their expectation is that, given the
+situation, new bugs and new issues will continue to arise.  The code
+really needs an ongoing maintainer with a good upstream relationship who
+can get the fixes and support incorporated upstream for it to remain
+viable.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 20:15:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 20:15:10 GMT) (full text, mbox, link).

+ +

Message #4632 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>, + Olav Vitters <ovitters@gmail.com>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 22:13:25 +0200
+
+
On Wed, Jan 29, 2014 at 11:27:53AM -0800, Russ Allbery wrote:
+> Adrian Bunk <bunk@stusta.de> writes:
+> > On Wed, Jan 29, 2014 at 07:17:29PM +0100, Josselin Mouette wrote:
+> >> Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit : 
+> 
+> >>> What *basic functionality* exactly is missing in GNOME 3.10 without
+> >>> logind?
+> 
+> >>> Note that I am not referring to bugs that are not yet sorted out like
+> >>>   * Switch from consolekit to systemd-logind sessions. For some reason
+> >>>     gnome-shell 3.10 unlocking fails with consolekit...
+> >>> 3 months ago in gdm3 - I am referring to basic functionality that is 
+> >>> simply missing in GNOME 3.10 without logind.
+> 
+> >> You have the answer to your own question above. Unlocking the screen
+> >> sounds like pretty basic functionality.
+> 
+> > Your statement was
+> >   I also have to insist that GNOME 3.10+ *needs* a working logind even for
+> >   basic functionality
+> 
+> > Are you saying that there are only some bugs to get sorted out for using 
+> > GNOME 3.10 without logind, or is there a fundamental technical reason
+> > why some *basic functionality* (which?) cannot be made working in
+> > GNOME 3.10 without logind?
+> 
+> I'm still wondering if maybe there's just a communication failure here, so
+> let me try one more round.
+> 
+> My understanding of what Josselin is saying is that GNOME's ConsoleKit
+> support is effectively unmaintained and unsupported upstream, as is
+> ConsoleKit itself.  The consequences of that are starting to show in a
+> variety of unfixed bugs.
+>...
+
+No, Josselin was making the technical claim that GNOME 3.10 would need a 
+working logind even for basic functionality.
+
+So if it is possible to get the basic functionality of GNOME 3.10 
+without a working logind, his claim is just plain wrong.
+
+And when I was asking him for the technical details that would back up 
+such a strong claim, he was not able to deliver.
+
+And that does matter a lot, since such claims seem to be the basis
+of all these "GNOME in jessie needs systemd" or "with multiple init 
+systems, GNOME will need a dependency on systemd" (and Josselin even 
+expects an exception from the release managers for that if the TC 
+decision would not allow such a dependency [1]).
+
+
+I do fully acknowledge that there are issues with ConsoleKit being 
+unmaintained and many non-systemd codepath in GNOME being unmaintained
+and with GNOME missing some non-basic functionality without systemd.
+
+But claims that even basic functionality in GNOME in jessie could not 
+work without logind might just be FUD.
+
+
+The TC can rule that systemd will be the default for jessie and that 
+dependencies on systemd will be OK if a maintainer wishes do add them, 
+but such a decision should be based on facts and not on unproven
+"GNOME needs it" claims.
+
+
+cu
+Adrian
+
+[1] https://lists.debian.org/debian-ctte/2014/01/msg00460.html
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 20:27:06 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Matthias Klumpp <matthias@tenstral.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 20:27:06 GMT) (full text, mbox, link).

+ +

Message #4637 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Matthias Klumpp <matthias@tenstral.net>
+
To: Adrian Bunk <bunk@stusta.de>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 21:24:16 +0100
+
+
2014-01-29 Adrian Bunk <bunk@stusta.de>:
+> [...]
+> I do fully acknowledge that there are issues with ConsoleKit being
+> unmaintained and many non-systemd codepath in GNOME being unmaintained
+> and with GNOME missing some non-basic functionality without systemd.
+>
+> But claims that even basic functionality in GNOME in jessie could not
+> work without logind might just be FUD.
+>
+> The TC can rule that systemd will be the default for jessie and that
+> dependencies on systemd will be OK if a maintainer wishes do add them,
+> but such a decision should be based on facts and not on unproven
+> "GNOME needs it" claims.
+No, Josselin is right: GNOME *does not* work without services provided
+by systemd. He never said that - given some amount of work - it can't
+be made working. But given the limited resources of the GNOME team, I
+can fully understand why they don't want to make the other solutions
+work (e.g. by taking over ConsoleKit maintenance).
+So, Joss' statement is correct.
+Also, have in mind that logind provides the basis for some additional
+features (e.g. real multiseat-support, sane closing of applications on
+logout, shutdown inhibitions etc.) and that systemd/logind is required
+for using Wayland, and GNOME is definitively going that road. Also,
+there are plans to make systemd --user manage a GNOME session, so the
+gnome-session codepath wil bitrot soon as well. And even on KDE we are
+evaluating that option[1], so it's not just GNOME going that way.
+Cheers,
+    Matthias
+
+[1] Fallbacks in place, but I don't know anyone who likes working on startkde...
+-- 
+Debian Developer | Freedesktop-Developer
+I welcome VSRE emails. See http://vsre.info/
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 20:54:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 20:54:07 GMT) (full text, mbox, link).

+ +

Message #4642 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 20:45:32 +0000 (UTC)
+
+
Matthias Klumpp dixit:
+
+>No, Josselin is right: GNOME *does not* work without services provided
+>by systemd. He never said that - given some amount of work - it can't
+
+Hum, we can always add “remove GNOME (3) from Debian” to the
+list of GR or TC points to consider (this *has* been suggested
+earlier, even)… and given that MATE seems to have picked up
+the market of GNOME…
+
+>Also, have in mind that logind provides the basis for some additional
+>features (e.g. real multiseat-support, sane closing of applications on
+>logout, shutdown inhibitions etc.) and that systemd/logind is required
+>for using Wayland, and GNOME is definitively going that road. Also,
+
+This is more of a threat than a promise.
+
+>gnome-session codepath wil bitrot soon as well. And even on KDE we are
+>evaluating that option[1], so it's not just GNOME going that way.
+
+As long as it’s still evaluating… the evaluation can result in
+“let’s do a more sane thing, after all GNOME got kicked off Debian
+for requiring systemd”.
+
+I *still* don’t see a problem with keeping sysvinit with sysv-rc,
+which I’m not overly fond of but which is still better than the
+alternatives – and all packages have sysvinit scripts already
+*anyway* so there is no added maintenance burden except for those
+who do wish to support other inits, which, in turn, can run the
+existing initscripts. My favourite option would thus be to keep
+sysvinit/sysv-rc forever, keep it as default for jessie, and do
+not permit any package to depend on an init implementation, but
+allow packages to degrade if the currently active init (be it
+the default init or not) does not support everything needed (i.e.
+no “allow degrade iff a default init is chosen” or “allow degrade
+iff a non-default init is chosen”).
+
+bye,
+//mirabilos
+-- 
+13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good
+guy. But he's always right! In every fsckin' situation, he's right. Even
+with his deeply perverted taste in software and borked ambition towards
+broken OSes - in the end, he's damn right about it :(! […] works in mksh
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 21:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 21:00:05 GMT) (full text, mbox, link).

+ +

Message #4647 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Matthias Klumpp <matthias@tenstral.net>
+
Cc: 727708@bugs.debian.org, Olav Vitters <ovitters@gmail.com>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 22:57:26 +0200
+
+
On Wed, Jan 29, 2014 at 09:24:16PM +0100, Matthias Klumpp wrote:
+> 2014-01-29 Adrian Bunk <bunk@stusta.de>:
+> > [...]
+> > I do fully acknowledge that there are issues with ConsoleKit being
+> > unmaintained and many non-systemd codepath in GNOME being unmaintained
+> > and with GNOME missing some non-basic functionality without systemd.
+> >
+> > But claims that even basic functionality in GNOME in jessie could not
+> > work without logind might just be FUD.
+> >
+> > The TC can rule that systemd will be the default for jessie and that
+> > dependencies on systemd will be OK if a maintainer wishes do add them,
+> > but such a decision should be based on facts and not on unproven
+> > "GNOME needs it" claims.
+> No, Josselin is right: GNOME *does not* work without services provided
+> by systemd.
+
+How did you verify that this claim you are making here is actually true?
+
+
+> He never said that - given some amount of work - it can't
+> be made working. But given the limited resources of the GNOME team, I
+> can fully understand why they don't want to make the other solutions
+> work (e.g. by taking over ConsoleKit maintenance).
+> So, Joss' statement is correct.
+>...
+
+No, it is not correct.
+
+Note that Josselin's statement [1]
+
+  I also have to insist that GNOME 3.10+ *needs* a working logind even for
+  basic functionality, and that starting with v205, logind *needs* systemd
+  as PID 1. You might disagree with the implementation details that lead
+  to this situation, but you should not expect either of these facts to
+  change before jessie.
+
+does not mention any resource problem.[2]
+
+Neither does his statement contain any mentioning of ConsoleKit 
+maintainership - and taking over ConsoleKit maintainership
+would anyway not fix the alleged "GNOME 3.10+ *needs* a working logind".
+
+He plainly claims that logind would be required for GNOME.
+
+And you are wrong when you claim "He never said that it can't be made 
+working." In fact, what Josselin insists on there is that starting with 
+GNOME 3.10 no version of GNOME before jessie will be able to provide 
+even basic functionality without logind.
+
+
+> Cheers,
+>     Matthias
+>...
+
+cu
+Adrian
+
+[1] https://lists.debian.org/debian-ctte/2014/01/msg00360.html
+[2] in which case a call for people working on that would be more
+    appropriate
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 21:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 21:03:04 GMT) (full text, mbox, link).

+ +

Message #4652 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org, Josselin Mouette <joss@debian.org>, Olav Vitters <ovitters@gmail.com>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 12:58:57 -0800
+
+
Adrian Bunk <bunk@stusta.de> writes:
+> On Wed, Jan 29, 2014 at 11:27:53AM -0800, Russ Allbery wrote:
+
+>> I'm still wondering if maybe there's just a communication failure here, so
+>> let me try one more round.
+
+>> My understanding of what Josselin is saying is that GNOME's ConsoleKit
+>> support is effectively unmaintained and unsupported upstream, as is
+>> ConsoleKit itself.  The consequences of that are starting to show in a
+>> variety of unfixed bugs.
+>>...
+
+> No, Josselin was making the technical claim that GNOME 3.10 would need a 
+> working logind even for basic functionality.
+
+> So if it is possible to get the basic functionality of GNOME 3.10 
+> without a working logind, his claim is just plain wrong.
+
+> And when I was asking him for the technical details that would back up
+> such a strong claim, he was not able to deliver.
+
+He delivered exactly what you asked for, and you then deleted his response
+and claimed he didn't provide it.  Then you did the same thing to me.
+
+It looks like Josselin's response to you was the correct one, and I will
+now follow his lead, do what I should have done a while back, and stop
+responding to your email messages on this topic, since I don't believe
+you're discussing in good faith.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 22:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Olav Vitters <olav@vitters.nl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 22:24:04 GMT) (full text, mbox, link).

+ +

Message #4657 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Olav Vitters <olav@vitters.nl>
+
To: Thorsten Glaser <tg@mirbsd.de>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 23:22:25 +0100
+
+
On Wed, Jan 29, 2014 at 08:45:32PM +0000, Thorsten Glaser wrote:
+> Matthias Klumpp dixit:
+> 
+> >No, Josselin is right: GNOME *does not* work without services provided
+> >by systemd. He never said that - given some amount of work - it can't
+> 
+> Hum, we can always add “remove GNOME (3) from Debian” to the
+> list of GR or TC points to consider (this *has* been suggested
+> earlier, even)… and given that MATE seems to have picked up
+> the market of GNOME…
+
+As agreed privately, please don't talk about GNOME. Your suggestions
+don't make much sense and you don't know what you're talking about
+anyway. Your continued characterization of GNOME (e.g. "threat") while
+knowing nothing is quite sad.
+
+Apologies to the rest reading this…
+
+-- 
+Regards,
+Olav
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 22:57:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andrew Shadura <andrew@shadura.me>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 22:57:05 GMT) (full text, mbox, link).

+ +

Message #4662 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andrew Shadura <andrew@shadura.me>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 23:54:11 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Hello,
+
+On Wed, 29 Jan 2014 19:17:29 +0100
+Josselin Mouette <joss@debian.org> wrote:
+
+> Gnome-shell uses GDM for screen locking, and GDM heavily relies on
+> logind nowadays. There is fallback code that uses ConsoleKit, but it
+> has been untested for several major releases, and now fails even for
+> trivial things. Add to that the fact that ConsoleKit itself has been
+> unmaintained for quite some time, making it unsuitable for a new
+> stable release that needs maintenance for several more years
+
+That only confirms the fact GNOME developers can't even keep their code
+working, not even speaking about testing its interoperability with
+most common environments. That doesn't create a good reputation, you
+know.
+
+-- 
+Cheers,
+  Andrew
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 23:06:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Olav Vitters <olav@vitters.nl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 23:06:05 GMT) (full text, mbox, link).

+ +

Message #4667 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Olav Vitters <olav@vitters.nl>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Thu, 30 Jan 2014 00:03:20 +0100
+
+
On Wed, Jan 29, 2014 at 11:54:11PM +0100, Andrew Shadura wrote:
+> On Wed, 29 Jan 2014 19:17:29 +0100
+> Josselin Mouette <joss@debian.org> wrote:
+> 
+> > Gnome-shell uses GDM for screen locking, and GDM heavily relies on
+> > logind nowadays. There is fallback code that uses ConsoleKit, but it
+> > has been untested for several major releases, and now fails even for
+> > trivial things. Add to that the fact that ConsoleKit itself has been
+> > unmaintained for quite some time, making it unsuitable for a new
+> > stable release that needs maintenance for several more years
+> 
+> That only confirms the fact GNOME developers can't even keep their code
+> working, not even speaking about testing its interoperability with
+> most common environments. That doesn't create a good reputation, you
+> know.
+
+Almost all of our developers are either using systemd, or they're using
+something which provides logind (Ubuntu). Even Gentoo has started
+depending on systemd (thus logind, etc) for GNOME.
+
+In short: for the most common environment, GNOME is damn stable and very
+well tested.
+
+-- 
+Regards,
+Olav
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 23:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to James Rhodes <jrhodes@redpointsoftware.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 23:15:04 GMT) (full text, mbox, link).

+ +

Message #4672 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: James Rhodes <jrhodes@redpointsoftware.com.au>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Thu, 30 Jan 2014 10:11:22 +1100
+
+
[Message part 1 (text/plain, inline)]
+
On 30 January 2014 09:54, Andrew Shadura <andrew@shadura.me> wrote:
+
+> Hello,
+>
+> On Wed, 29 Jan 2014 19:17:29 +0100
+> Josselin Mouette <joss@debian.org> wrote:
+>
+> > Gnome-shell uses GDM for screen locking, and GDM heavily relies on
+> > logind nowadays. There is fallback code that uses ConsoleKit, but it
+> > has been untested for several major releases, and now fails even for
+> > trivial things. Add to that the fact that ConsoleKit itself has been
+> > unmaintained for quite some time, making it unsuitable for a new
+> > stable release that needs maintenance for several more years
+>
+> That only confirms the fact GNOME developers can't even keep their code
+> working, not even speaking about testing its interoperability with
+> most common environments. That doesn't create a good reputation, you
+> know.
+>
+
+Why do you expect GNOME developers to maintain support for ConsoleKit, when
+it's been deprecated and unmaintained for several years?  It's not the
+responsibility of the GNOME developers to pick up maintenance of ConsoleKit
+and to suggest that not doing this is representative of their quality as
+developers is borderline offensive.
+
+GNOME developers do keep their code working, against what they've stated
+they will support.  That happens to be logind.
+
+(Apologies if I'm not replying to this bug correctly as it's my first time
+emailing against a Debian bug)
+
+Regards, James.
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 29 Jan 2014 23:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 29 Jan 2014 23:21:04 GMT) (full text, mbox, link).

+ +

Message #4677 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Andrew Shadura <andrew@shadura.me>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 15:18:46 -0800
+
+
Andrew Shadura <andrew@shadura.me> writes:
+> Josselin Mouette <joss@debian.org> wrote:
+
+>> Gnome-shell uses GDM for screen locking, and GDM heavily relies on
+>> logind nowadays. There is fallback code that uses ConsoleKit, but it
+>> has been untested for several major releases, and now fails even for
+>> trivial things. Add to that the fact that ConsoleKit itself has been
+>> unmaintained for quite some time, making it unsuitable for a new stable
+>> release that needs maintenance for several more years
+
+> That only confirms the fact GNOME developers can't even keep their code
+> working, not even speaking about testing its interoperability with most
+> common environments. That doesn't create a good reputation, you know.
+
+The point of this discussion is to determine the set of constraints we
+have around dependencies on either init systems or components closely tied
+to init systems.  GNOME's reputation for portability or code stability,
+for good or for ill, is not directly relevant; what's relevant is whether
+the software works or does not work in particular configurations, and what
+the implications are for package dependencies within Debian.  Whether or
+not GNOME itself is stable, portable, or to your liking is only relevant
+if the project believes it is so unstable or so uninteresting that we're
+not going to ship it in jessie, and I don't believe there is any realistic
+chance we would pick that option.
+
+Given that, your opinions about the quality of GNOME upstream development
+don't seem relevant to the problem we're trying to resolve.  If you don't
+like the software, don't use it.  And please don't hold opinions about the
+proper packaging of software you don't like and don't believe is
+well-written!  That's just intensely irritating and comes across as
+malicious sniping.  Let the people who are interested in making the
+software work figure out what that entails.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 00:18:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to ChaosEsque Team <chaosesqueteam@yahoo.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 00:18:05 GMT) (full text, mbox, link).

+ +

Message #4682 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: ChaosEsque Team <chaosesqueteam@yahoo.com>
+
To: 727708@bugs.debian.org
+
Cc: tg@mirbsd.de
+
Subject: Re: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Wed, 29 Jan 2014 16:11:16 -0800 (PST)
+
+
This sounds like a good solution, since MATE is the gnome we all knew, and the Gnome of today is a different beast entirely (though it gets to keep the name).
+::
+>Hum, we can always add “remove GNOME (3) from Debian” to the
+>list of GR or TC points to consider (this *has* been suggested
+>earlier, even)… and given that MATE seems to have picked up
+>the market of GNOME…
+
+
+>This is more of a threat than a promise.
+There are alot of those from a certain crowd. 
+They use the carrot and the stick approach.
+The proper free/open approach is just the carrot and let people decide and respect them.
+Not cattle pen them and run them to wherever one wishes.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 00:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to ChaosEsque Team <chaosesqueteam@yahoo.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 00:30:04 GMT) (full text, mbox, link).

+ +

Message #4687 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: ChaosEsque Team <chaosesqueteam@yahoo.com>
+
To: 727708@bugs.debian.org
+
Cc: rra@debian.org, andrew@shadura.me
+
Subject: Re: Re: Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
+
Date: Wed, 29 Jan 2014 16:24:02 -0800 (PST)
+
+
 >If you don't like the software, don't use it.
+
+Absolutely. But that is not really an option that is to be afforded to all of us if
+the systemd guys successfully have their way with linux.
+
+It would be nice if they afforded us such a freedom, but their statements 
+and their actions suggest that this would be a one way street:
+
+They "convince" as many pieces of the "software stack" as possible
+to depend on systemd, and we can go use "an embedded system or something"
+(yes that's a quote from one of the systemders) if we don't like it.
+
+When they came here their proposal was to remove all other init systems 
+from Debian, and force everyone to use systemd.
+
+They are here to conquer. In time the statement would read:
+"If you don't like systemd, don't use linux - get a mac or something *SNCR*"
+
+They have conquered a good number of other distributions, now it is time
+to bring Debian, too, into the fold.
+
+>Given that, your opinions about the quality of GNOME upstream development
+>don't seem relevant to the problem we're trying to resolve.  If you don't
+>like the software, don't use it.  And please don't hold opinions about the
+>proper packaging of software you don't like and don't believe is
+>well-written!  That's just intensely irritating and comes across as
+>malicious sniping.  Let the people who are interested in making the
+>software work figure out what that entails.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 01:36:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Matthias Klumpp <matthias@tenstral.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 01:36:05 GMT) (full text, mbox, link).

+ +

Message #4692 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Matthias Klumpp <matthias@tenstral.net>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Re: Bug#727708: multiple init systems - formal + resolution proposal - Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 02:32:42 +0100
+
+
2014-01-30 ChaosEsque Team <chaosesqueteam@yahoo.com>:
+>  [bullshit]
+
+Wasn't there some kind of a ban applied here?
+I am confused.
+Cheers,
+    Matthias
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 10:33:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to skirpichev@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 10:33:07 GMT) (full text, mbox, link).

+ +

Message #4697 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sergey B Kirpichev <skirpichev@gmail.com>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Thu, 30 Jan 2014 14:29:24 +0400
+
+
On Wed, Jan 29, 2014 at 03:18:46PM -0800, Russ Allbery wrote:
+> Given that, your opinions about the quality of GNOME upstream development
+> don't seem relevant to the problem we're trying to resolve.  If you don't
+> like the software, don't use it.
+
+Unfortunately, it doesn't save us, as the set of constraints of this
+software may affect the future Debian policy.
+
+Do we have any other software, that right now forces other to switch
+the init system?  If not, "remove GNOME from Debian" could be an
+option (and, may be, a good motivation for upstream to keep away from
+insane changes, be more LSB-compatible).  There is no good reasons to
+change long-standing Debian policy about alternative inits.
+
+> Let the people who are interested in making the
+> software work figure out what that entails.
+
+"People who are interested" seems to be not interested in anything
+except satisfying their requirements by new Debian policy.  But
+the Debian is not just a Gnome launcher.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 10:45:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to skirpichev@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 10:45:09 GMT) (full text, mbox, link).

+ +

Message #4702 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sergey B Kirpichev <skirpichev@gmail.com>
+
To: Colin Watson <cjwatson@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Thu, 30 Jan 2014 14:40:09 +0400
+
+
On Wed, Jan 29, 2014 at 11:13:33AM +0000, Colin Watson wrote:
+> We might disagree on the extent, perhaps, but I doubt anyone on the
+> committee would vote against this in its general form; both systemd and
+> upstart implement interfaces beyond the bare minimum, though upstart
+> certainly takes a more minimalist tack.
+
+I just wonder why nobody from tect-ctte take care about the exact
+specification of that "bare minimum" (or, in other words, what exactly
+is wrong with sysvinit).  Correct me, please, if I'm wrong.
+
+The whole 3000+ thread is about different features of one or another
+sysvinit replacement.  Or do we buy the least terrible variant from the submitted?
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 12:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 12:18:04 GMT) (full text, mbox, link).

+ +

Message #4707 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: Matthias Klumpp <matthias@tenstral.net>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal + - Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 12:05:05 +0000 (UTC)
+
+
Matthias Klumpp dixit:
+
+>2014-01-30 ChaosEsque Team <chaosesqueteam@yahoo.com>:
+>>  [bullshit]
+
+This was actually *not* bullshit. The delivery of most of the
+content could use some polishing, but the content is a(n inconvenient)
+truth.
+
+>Wasn't there some kind of a ban applied here?
+
+Apparently not, but it’s better that way, as the reasoning
+was something along the lines of the messages being off-topic,
+which they are clearly not, so I believe the ban to be in
+error, anyway.
+
+bye,
+//mirabilos
+-- 
+<diogenese> Beware of ritual lest you forget the meaning behind it.
+<igli> yeah but it means if you really care about something, don't
+    ritualise it, or you will lose it. don't fetishise it, don't
+    obsess. or you'll forget why you love it in the first place.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 13:54:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 13:54:08 GMT) (full text, mbox, link).

+ +

Message #4712 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: Thorsten Glaser <tg@mirbsd.de>, 727708@bugs.debian.org
+
Cc: Matthias Klumpp <matthias@tenstral.net>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal - + Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 08:51:45 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Thu, Jan 30, 2014 at 12:05:05PM +0000, Thorsten Glaser wrote:
+> This was actually *not* bullshit. The delivery of most of the
+> content could use some polishing, but the content is a(n inconvenient)
+> truth.
+
+Man, if someone was spouting garbage like that in support of systemd,
+you bet your mksh that I would call them on it[1] and try to seperate them
+from the sane people.
+
+Don't support the trolls, we're having a hard enough time keeping the
+signal ratio as high as it is - we don't need more over politicised
+garbage on the list.
+
+
+Much love,
+  Paul
+
+[1]: I actually have, in fact, done this. There are people arguing for
+     the position I support that I've told to back off from the thread.
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
+: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+`. `'`  http://people.debian.org/~paultag
+ `-     http://people.debian.org/~paultag/conduct-statement.txt
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 14:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 14:21:04 GMT) (full text, mbox, link).

+ +

Message #4717 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: 727708@bugs.debian.org
+
Cc: Paul Tagliamonte <paultag@debian.org>, Thorsten Glaser <tg@mirbsd.de>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal + - Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 14:18:25 +0000
+
+
[Message part 1 (text/plain, inline)]
+
Putting it another way, then, I expect there are some people who will
+not want systemd on their GNU/Linux systems.  I don't think it matters
+if their reasons are technical, political, irrational fear or personal
+dislike of the creator;  I'd like them to have that choice and for it to
+work as well as possible.
+
+Whatever init system we use on the non-Linux ports (which will certainly
+not be systemd), I expect it will be fully available to Debian GNU/Linux
+installs, with init scripts that we'd have to maintain already for the
+sake of our ports.  Hopefully that is some reassurance.
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 14:45:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 14:45:05 GMT) (full text, mbox, link).

+ +

Message #4722 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: TC resolution revised draft
+
Date: Thu, 30 Jan 2014 14:40:19 +0000
+
+
I have taken Bdale's text, reformatted it a bit, and added the GR
+rider and the multiple init systems rider texts.
+
+For the GR rider I used the version from my previous standalone
+proposal.  I see Bdale has a different text in git.  I'll discuss that
+in a moment.
+
+For the multiple init systems rider I used my original text for the
+first sentence and Don's formulation for the second sentence.
+
+I have also added an explicit option for declining to decide and
+asking the project to do it via GR.  I think such an option would be
+much better than FD.
+
+Below is the result.  This in principle results in 9 real options plus
+FD.  I'm going to call the options by the subsets of the text they
+use:
+
+  D DM U UM O OM V VM GR and of course FD
+
+I think we can probably leave out one of each of O OM V VM.  If anyone
+has a preference for O and V over OM and VM please say so.  I think O
+and V are probably sufficient for those options, as the desire to
+support multiple systems there is probably obvious so doesn't need
+saying.  That would leave us with 7 real options which isn't too
+unmanageable.
+
+The text below is in the tc git repo.
+
+I'm going to follow up in a moment with a formal action to propose
+a resolution, starting the constitutional discussion period.
+
+Ian.
+
+== version D (systemD) ==
+
+   The default init system for Linux architectures in jessie should
+   be systemd.
+
+== version U (Upstart) ==
+
+   The default init system for Linux architectures in jessie should
+   be upstart.
+
+== version O (Openrc) ==
+
+   The default init system for Linux architectures in jessie should
+   be openrc
+
+== version V (sysVinit) ==
+
+   The default init system for Linux architectures in jessie should
+   be sysvinit (no change).
+
+== version GR (General Resolution) ==
+
+   The Technical Committee requests that the project decide the
+   default init system for jessie by means of General Resolution.
+
+== optional rider M (Multiple init systems) ==
+
+   Debian intends to support multiple init systems, for the
+   foreseeable future, and so long as their respective communities
+   and code remain healthy.
+
+   Where feasible, software should interoperate with non-default
+   init systems; maintainers are encouraged to accept technically
+   sound patches to enable interoperation, even if it results in
+   degraded operation while running under the init system the patch
+   enables interoperation with.
+
+== rider for all versions except GR ==
+
+   This decision is automatically vacated by any contrary General
+   Resolution which passes by a simple majority.  In that case the
+   General Resolution takes effect and the whole of this TC resolution
+   is to be taken as withdrawn by the TC, just as if the TC had
+   explicitly withdrawn it by a subsequent TC resolution.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 14:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 14:48:04 GMT) (full text, mbox, link).

+ +

Message #4727 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: TC resolution revised draft
+
Date: Thu, 30 Jan 2014 14:43:59 +0000
+
+
Ian Jackson writes ("TC resolution revised draft"):
+> For the GR rider I used the version from my previous standalone
+> proposal.  I see Bdale has a different text in git.  I'll discuss that
+> in a moment.
+
+I see that Bdale has his own draft in git.
+
+The differences are:
+
+ * My GR rider is different to Bdale's.  Mine is more comprehensive;
+   it specifically allows the GR to override any other part of the
+   resolution, and that any contrary GR completely replaces the TC
+   resolution.  I think this is better.  This is particularly true
+   given that the TC resolution might include the "multiple init
+   systems" wording, which ought to be overrideable too.
+
+   So for that reason I have kept my version rather than Bdale's.
+
+ * My options have mnemonic letters.  This is going to be relevant
+   because some of them want to have the multiple init systems
+   version.
+
+ * Formatting is a bit different.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 14:51:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 14:51:09 GMT) (full text, mbox, link).

+ +

Message #4732 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: TC resolution revised draft
+
Date: Thu, 30 Jan 2014 14:47:47 +0000
+
+
Ian Jackson writes ("TC resolution revised draft"):
+> I'm going to follow up in a moment with a formal action to propose
+> a resolution, starting the constitutional discussion period.
+
+I hereby formally propose what I have called UM (text below).
+
+I also hereby formally propose DM as an amendment, but do not accept
+it.
+
+After I hear from other TC members on the merits of O vs OM and V vs
+VM, I will propose but not accept one of each, unless someone else
+gets there first.
+
+I suggest that those TC members who prefer to leave out the comments
+about supporting multiple init systems propose D and/or U.
+
+That will leave us voting on (most likely):
+   D    systemd default in jessie, say nothing about multiple inits
+   DM   systemd default in jessie, support multiple inits
+   U    systemd default in jessie, say nothing about multiple inits
+   UM   systemd default in jessie, support multiple inits
+   O    openrc default in jessie
+   V    sysvinit default in jessie
+   GR   project should decide via GR
+   FD   further discussion
+
+We should see what people say by email and at the meeting, but unless
+people disagree I think it would be sensible to have a formal
+discussion period of about a week.
+
+That would have us starting the vote on the 6th of February.  Is
+everyone available to vote then ?
+
+Thanks,
+Ian.
+
+== version D (systemD) ==
+
+   The default init system for Linux architectures in jessie should
+   be systemd.
+
+== version U (Upstart) ==
+
+   The default init system for Linux architectures in jessie should
+   be upstart.
+
+== version O (Openrc) ==
+
+   The default init system for Linux architectures in jessie should
+   be openrc
+
+== version V (sysVinit) ==
+
+   The default init system for Linux architectures in jessie should
+   be sysvinit (no change).
+
+== version GR (General Resolution) ==
+
+   The Technical Committee requests that the project decide the
+   default init system for jessie by means of General Resolution.
+
+== optional rider M (Multiple init systems) ==
+
+   Debian intends to support multiple init systems, for the
+   foreseeable future, and so long as their respective communities
+   and code remain healthy.
+
+   Where feasible, software should interoperate with non-default
+   init systems; maintainers are encouraged to accept technically
+   sound patches to enable interoperation, even if it results in
+   degraded operation while running under the init system the patch
+   enables interoperation with.
+
+== rider for all versions except GR ==
+
+   This decision is automatically vacated by any contrary General
+   Resolution which passes by a simple majority.  In that case the
+   General Resolution takes effect and the whole of this TC resolution
+   is to be taken as withdrawn by the TC, just as if the TC had
+   explicitly withdrawn it by a subsequent TC resolution.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 14:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 14:54:04 GMT) (full text, mbox, link).

+ +

Message #4737 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Thu, 30 Jan 2014 14:51:27 +0000
+
+
On 30/01/14 14:40, Ian Jackson wrote:
+>   D DM U UM O OM V VM GR and of course FD
+> 
+> I think we can probably leave out one of each of O OM V VM.  If anyone
+> has a preference for O and V over OM and VM please say so.
+
+Couldn't it bias the outcome if votes might otherwise have been split
+between O and OM for example?  And so better to leave them in?
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 15:00:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 15:00:15 GMT) (full text, mbox, link).

+ +

Message #4742 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steven Chamberlain <steven@pyro.eu.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Thu, 30 Jan 2014 14:59:35 +0000
+
+
Steven Chamberlain writes ("Bug#727708: TC resolution revised draft"):
+> On 30/01/14 14:40, Ian Jackson wrote:
+> >   D DM U UM O OM V VM GR and of course FD
+> > 
+> > I think we can probably leave out one of each of O OM V VM.  If anyone
+> > has a preference for O and V over OM and VM please say so.
+> 
+> Couldn't it bias the outcome if votes might otherwise have been split
+> between O and OM for example?  And so better to leave them in?
+
+Thanks for asking, but I think not. [1]
+
+Our voting system (Condorcet with "Schwartz Cloneproof Sequential
+Dropping") is designed to cope with that.  In actual practice I'm
+expecting to have a single Condorcet winner in which case
+splitting/joining options is totally irrelevant.
+
+Ian.
+
+[1] I'm starting to feel the need to thank anyone who makes a short
+and non-useless contribution, even if they happen to be wrong, since
+there are so many unhelpful emails now and such a bad atmosphere.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 15:27:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 15:27:05 GMT) (full text, mbox, link).

+ +

Message #4747 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Svante Signell <svante.signell@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Cut-and paste typo
+
Date: Thu, 30 Jan 2014 16:23:07 +0100
+
+
I think you made a c-p typo, see below:
+
+> That will leave us voting on (most likely):
+>    D    systemd default in jessie, say nothing about multiple inits
+>    DM   systemd default in jessie, support multiple inits
+>    U    systemd default in jessie, say nothing about multiple inits
+>         ^upstart
+>    UM   systemd default in jessie, support multiple inits
+>         ^upstart
+>    O    openrc default in jessie
+>    V    sysvinit default in jessie
+>    GR   project should decide via GR
+>    FD   further discussion
+
+Otherwise the voting would (almost) not be needed!
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 15:33:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 15:33:07 GMT) (full text, mbox, link).

+ +

Message #4752 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Cut-and paste typo
+
Date: Thu, 30 Jan 2014 15:29:24 +0000
+
+
Svante Signell writes ("Bug#727708: Cut-and paste typo"):
+> I think you made a c-p typo, see below:
+> 
+> > That will leave us voting on (most likely):
+> >    D    systemd default in jessie, say nothing about multiple inits
+> >    DM   systemd default in jessie, support multiple inits
+> >    U    systemd default in jessie, say nothing about multiple inits
+> >         ^upstart
+> >    UM   systemd default in jessie, support multiple inits
+> >         ^upstart
+> >    O    openrc default in jessie
+> >    V    sysvinit default in jessie
+> >    GR   project should decide via GR
+> >    FD   further discussion
+> 
+> Otherwise the voting would (almost) not be needed!
+
+*rotfl*
+
+You are of course entirely right.  Here's the revised table
+
+    D    systemd default in jessie, say nothing about multiple inits
+    DM   systemd default in jessie, support multiple inits
+    U    upstart default in jessie, say nothing about multiple inits
+    UM   upstart default in jessie, support multiple inits
+    O    openrc default in jessie
+    V    sysvinit default in jessie
+    GR   project should decide via GR
+    FD   further discussion
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 15:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 15:54:04 GMT) (full text, mbox, link).

+ +

Message #4757 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Thu, 30 Jan 2014 15:50:44 +0000
+
+
Philipp Kern writes ("Re: Bug#727708: TC resolution revised draft"):
+> On 2014-01-30 15:59, Ian Jackson wrote:
+> > Our voting system (Condorcet with "Schwartz Cloneproof Sequential
+> > Dropping") is designed to cope with that.  In actual practice I'm
+> > expecting to have a single Condorcet winner in which case
+> > splitting/joining options is totally irrelevant.
+> 
+> I really hope you are right that it cannot be rigged. That said: How 
+> does Bdale's casting vote work with Condorcet? If there's a tie, both 
+> are in the set of winners and he'll break the tie using the order within 
+> his vote?
+
+Yes.  See Constitution A.6.
+
+Thanks,
+Ian.
+
+(PS: I have replied to the bug.  Please send messages on this subject
+to the bug, not just to the ctte list.)
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 16:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 16:00:04 GMT) (full text, mbox, link).

+ +

Message #4762 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Thu, 30 Jan 2014 15:57:36 +0000
+
+
Philipp Kern writes ("Re: Bug#727708: TC resolution revised draft"):
+> So if we assume that upstart wins, would it be acceptable to depend on 
+> systemd (or vice versa)? We might then get a set called, say, Unity, 
+> depending on upstart and one called, say, GNOME, depending on systemd, 
+> which would not be co-installable. Maybe there should be a paragraph 
+> addressing this?
+
+I have tried to persaude my colleagues that it is necessary to exclude
+this possibility, but I don't seem to have succeeded.
+
+> I do like the current phrasing wrt support of the non-default init 
+> system. But I don't see the question above addressed in it…
+
+You're right, it's not.  Some of my proposed stronger wordings for the
+Multiple section do address it.
+
+However, with Russ, Bdale and Keith all saying they're opposed to
+having this paragraph at all, I would need the support of all the rest
+of the TC to include it.  Hence my proposal for a compromise which Don
+has said he prefers to FD.  (And even that may not be enough.)
+
+If you think it's important to explicitly vote on this question then I
+am open to putting it on the ballot.  (Although the number of options
+starts to become rather unwieldy, in practice I expect the TC members
+not to have trouble ranking them.)
+
+I also don't know whether Bdale intends to use his casting vote to
+force a decision (and if so how far that decision will go), or whether
+he'll use it to acknowledge that the TC is split and punt the question
+to a GR.  But I would guess the former.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 16:33:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Matthias Klumpp <matthias@tenstral.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 16:33:10 GMT) (full text, mbox, link).

+ +

Message #4767 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Matthias Klumpp <matthias@tenstral.net>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal - + Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 17:30:04 +0100
+
+
2014-01-30 Thorsten Glaser <tg@mirbsd.de>:
+> Matthias Klumpp dixit:
+>
+>>2014-01-30 ChaosEsque Team <chaosesqueteam@yahoo.com>:
+>>>  [bullshit]
+>
+> This was actually *not* bullshit. The delivery of most of the
+> content could use some polishing, but the content is a(n inconvenient)
+> truth.
+>
+>>Wasn't there some kind of a ban applied here?
+>
+> Apparently not, but it’s better that way, as the reasoning
+> was something along the lines of the messages being off-topic,
+> which they are clearly not, so I believe the ban to be in
+> error, anyway.
+First of all, I am sorry for leaking information and this rather rude
+reply - won't happen again. I was just very annoyed yesterday, but a
+more polite reply would still have been better (although I still think
+the arguments weren't valid)
+On thing about the whole "dropping GNOME" and "punishing Lennart/the
+systemd team for pushing innovations without caring for how it was
+done prevously":
+What would be the effecr if we decided to drop GNOME, because it
+depends on systemd?
+Of course, Debian would have played with it's muscles, but in the end
+we would have lost GNOME users, all GNOME developers and many
+motivated people involved in taking care of GNOME. GNOME upstream
+won't really change, because they test the with-systemd codepath,
+which means they are running it. So we would have a great loss without
+any gain.
+What would happen if we adopted systemd?
+We could keep every software running as-it-is on Debian. People would
+not notice any issues, because (except for some bugs pending to be
+fixed, and the migration phase) a systemd-system does not break
+anything for Linux users (ask Arch, Fedora, OpenSUSE, ...). Of course,
+there is the kFreeBSD case. But instead of porting away each and every
+software from systemd to $other_init, in case of kFreeBSD we would
+"just" have to maintain portability patches for applications which
+want to run on this architecture. So, less work. For users of
+alternative kernels, they could also use sysvinit or anything else,
+because existing scripts won't stop working and new ones can be
+written which match the underlying alternative kernel (sysvinit is
+running on kFreeBSD due to some hacks to make /proc Linux-ish, so this
+kind of adaption is already happening).
+If we would drop systemd or anything which Lennart created, we would
+reject functionality without any technical reason to do so. The
+software written by Lennart fixes issues. That's why Wayland uses it
+and an X patch is pending, to make some new scenarios with X possible.
+People working on these projects are no idiots who add a dependency
+"because they can", but because it seems to be the best solution in
+order to fix a problem for them. Of course, that could - in theory -
+be done differently, but nobody stepped up to write an alternative to
+systemd services, so systemd is used.
+Not using systemd fixes *none* of the problems, but results in much
+more work in future to make stuff work on Debian - so I don't really
+consider this to be a viable solution to anything.
+All of the above applies to upstart as well, but with the limitation
+that in case of using upstart we would still have to make upstart
+support systemd features and to carry additional patches to make all
+systemd services work well on that system.
+In the end: Dropping GNOME or systemd does not fix issues but is only
+hiding problems. Ignoring things written by the systemd people which
+are adopted by many upstream projects already will harm Debian more
+then simply adding them and making them work great (because that's
+what distributions should do: make upstream software work well
+together), no matter if systemd is running as init or not.
+Phew, waaay to much text...
+Cheers,
+    Matthias
+
+-- 
+I welcome VSRE emails. See http://vsre.info/
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 17:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 17:06:04 GMT) (full text, mbox, link).

+ +

Message #4772 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: Matthias Klumpp <matthias@tenstral.net>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal + - Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 17:01:01 +0000 (UTC)
+
+
Matthias Klumpp dixit:
+
+>What would happen if we adopted systemd?
+
+The project would lose (a different set of) contributors and users.
+
+The OSS ecosystem would lose, vendor-lock-in would ensue in a way
+even worse than the FSF does, and the remnants of Unix/GNU in Debian
+would die, to be replaced by FLOS. The last “big” outpost of inde‐
+pendence would go away. I don’t know which OS I’d use in place of
+Debian then (probably rather OpenBSD than Gentoo), in the places
+where I’m currently using, supporting or pushing Debian.
+
+Debian would follow the path of Red Hat, Inc.
+
+The LSB would die.
+
+The LPI people would probably rejoice, as they could drop
+everything other than systemd configs…
+
+Every single Unix or GNU sysadmin would have to relearn
+basically everything about system/service management.
+
+Oh, and don’t let me get started on “journal”…
+
+And, finally – last but definitely not least – nobody knows
+what Lennart and Co. would drop onto our heads *next* time.
+Or the GNOME people. And, by then, switching away would be
+even *more* reluctant work.
+
+>software written by Lennart fixes issues. That's why Wayland uses it
+>and an X patch is pending, to make some new scenarios with X possible.
+
+It also creates lots of issues (a common way to fix audio
+problems on contemporary Debian is “purge pulseaudio”, I
+kid you not!), and not everyone needs all those scenarios.
+
+I don’t mind Debian permitting people to use systemd as
+long as sysvinit support stays mandatory, and it is possible
+to install a Debian system without systemd/GNOME without
+needing to go through unreasonable things. Otherwise… well.
+
+>In the end: Dropping GNOME or systemd does not fix issues but is only
+
+Well, it _would_ fix the current clash *and* give clear
+signals into the direction of KDE and hopefully XFCE people.
+Also, it would signal to people that they cannot just take
+over the entire OS like that.
+
+Distributions are *not* meant to be there to just look and
+do the same. Rather, the contrary. While their initial and
+foremost purpose is to make the bunch of packages in the GNU
+ecosystem installable and harmonise with each other, their
+job is also to offer a diverse choice.
+
+And the GNOME/systemd people are invited to make their dream
+of the FLOS GNOME OS into a Debian derivate or Pure Blend.
+
+bye,
+//mirabilos
+-- 
+08:05⎜<XTaran:#grml> mika: Does grml have an tool to read Apple
+     ⎜    System Log (asl) files? :)
+08:08⎜<ft:#grml> yeah. /bin/rm. ;)       08:09⎜<mrud:#grml> hexdump -C
+08:31⎜<XTaran:#grml> ft, mrud: *g*
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 17:09:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 17:09:10 GMT) (full text, mbox, link).

+ +

Message #4777 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Matthias Klumpp <matthias@tenstral.net>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 17:04:45 +0000
+
+
Matthias Klumpp writes ("Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely."):
+> What would be the effecr if we decided to drop GNOME, because it
+> depends on systemd?
+
+In this hypothetical scenario:
+
+It would be fairly easy for a downstream of Debian to mandate systemd
+for their users, and provide Gnome.
+
+It would not be anywhere near as easy for a downstream of Debian to
+undo the assumption by Debian (de facto or de jure) of systemd as the
+one true init system.
+
+If it comes down to it I would prefer to drop Gnome than to make
+systemd mandatory for all of Debian's users and downstreams just
+because Gnome had introduced a hard dependency on systemd.
+
+Luckily this is all hypothetical.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 17:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 17:27:04 GMT) (full text, mbox, link).

+ +

Message #4782 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Thu, 30 Jan 2014 17:22:21 +0000
+
+
Philipp Kern writes ("Re: Bug#727708: TC resolution revised draft"):
+> On 2014-01-30 15:47, Ian Jackson wrote:
+> > == optional rider M (Multiple init systems) ==
+> > 
+> >    Debian intends to support multiple init systems, for the
+> >    foreseeable future, and so long as their respective communities
+> >    and code remain healthy.
+> > 
+> >    Where feasible, software should interoperate with non-default
+> >    init systems; maintainers are encouraged to accept technically
+> >    sound patches to enable interoperation, even if it results in
+> >    degraded operation while running under the init system the patch
+> >    enables interoperation with.
+> 
+> So if we assume that upstart wins, would it be acceptable to depend on 
+> systemd (or vice versa)? We might then get a set called, say, Unity, 
+> depending on upstart and one called, say, GNOME, depending on systemd, 
+> which would not be co-installable. Maybe there should be a paragraph 
+> addressing this?
+
+So, my previous version of this rider was this:
+
+       Debian intends to support multiple init systems, for the
+       foreseeable future, and so long as their respective communities
+       and code remain healthy.
+
+(Same as above.)
+
+       Software outside of an init system's implementation may not
+       require a specific init system to be pid 1, although degraded
+       operation is tolerable.
+
+Different to above.  Perhaps adding this:
+
+       Maintainers are encouraged to accept technically sound patches
+       to enable improved interoperation with various init systems.
+
+would soften this text.
+
+
+I will ensure that something like this gets onto the ballot iff I hear
+from the project that they think it's important to vote on it in the
+TC (even if the TC seems likely to reject it).
+
+I'm obviously open to suggested wording improvements for the version M
+you see above (which is in the git repo) and this stronger
+compatibility requirement version.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 17:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 17:33:05 GMT) (full text, mbox, link).

+ +

Message #4787 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: Thorsten Glaser <tg@mirbsd.de>, 727708@bugs.debian.org
+
Cc: Matthias Klumpp <matthias@tenstral.net>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal + - Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 17:29:32 +0000
+
+
On 30/01/14 17:01, Thorsten Glaser wrote:
+> And the GNOME/systemd people are invited to make their dream
+> of the FLOS GNOME OS into a Debian derivate or Pure Blend.
+
+If the chosen default is something other than systemd, and if the TC
+resolution does not prevent GNOME having a hard dependency on systemd
+interfaces, then systemd would effectively belong to task-gnome-desktop
+
+That situation is basically how the pure blends work already?  And it
+still means the Debian GNOME DVD could give the ideal setup for GNOME.
+And the 'default' can be decided irrespective of what GNOME needs?
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 17:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to skirpichev@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 17:42:04 GMT) (full text, mbox, link).

+ +

Message #4792 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sergey B Kirpichev <skirpichev@gmail.com>
+
To: Matthias Klumpp <matthias@tenstral.net>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal - + Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 21:38:32 +0400
+
+
On Thu, Jan 30, 2014 at 05:30:04PM +0100, Matthias Klumpp wrote:
+> What would be the effecr if we decided to drop GNOME, because it
+> depends on systemd?
+> Of course, Debian would have played with it's muscles, but in the end
+> we would have lost GNOME users, all GNOME developers and many
+> motivated people involved in taking care of GNOME.
+
+May be. On another hand, it this decision can attract "more
+conservative" (and, probably, experienced) people from other
+distributions.
+
+> GNOME upstream won't really change
+
+Why?  There are non-Linux GNOME users, for example.  If the GNOME
+developers don't care even about such popular distribution as Debian -
+something is going wrong.  And not with the Debian, for sure.
+
+> We could keep every software running as-it-is on Debian. People would
+> not notice any issues, because (except for some bugs pending to be
+> fixed, and the migration phase) a systemd-system does not break
+> anything for Linux users
+
+Please don't repeat here these myths.  It does break
+things, it has bugs.  Go to bugtrackers of mentioned distributions,
+go to the systemd's bugtracker.  Last, but not least:
+http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=yes&src=systemd
+
+> If we would drop systemd or anything which Lennart created, we would
+> reject functionality without any technical reason to do so.
+
+There are lots of reasons why we sometimes want to keep things
+simple and clean.  A good example was mentioned in this thread:
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#3155
+
+> That's why Wayland uses it
+> and an X patch is pending, to make some new scenarios with X possible.
+> People working on these projects are no idiots who add a dependency
+> "because they can", but because it seems to be the best solution in
+> order to fix a problem for them.
+
+Are X-people indeed sacrifice portability, or there is something
+different (e.g. these dependencies are optional)?
+
+> Not using systemd fixes *none* of the problems
+
+Where is the list of problems for sysvinit we intend to solve?
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 17:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 17:51:05 GMT) (full text, mbox, link).

+ +

Message #4797 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal + - Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 18:47:02 +0100
+
+
Le jeudi 30 janvier 2014 à 21:38 +0400, Sergey B Kirpichev a écrit :
+> [Lots of crap]
+> 
+> Where is the list of problems for sysvinit we intend to solve?
+
+https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv
+
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 18:27:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bastien Beudart <bastienbeudart@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 18:27:07 GMT) (full text, mbox, link).

+ +

Message #4802 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bastien Beudart <bastienbeudart@gmail.com>
+
To: ijackson@chiark.greenend.org.uk, 727708@bugs.debian.org
+
Cc: matthias@tenstral.net
+
Subject: Bug#727708: multiple init systems - formal resolution proposal - + Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 19:24:11 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Matthias Klumpp writes ("Bug#727708: multiple init systems - formal
+resolution proposal - Don't like software, don't use it.
+Absolutely."):
+
+>> What would be the effecr if we decided to drop GNOME, because it
+>> depends on systemd?
+
+>In this hypothetical scenario:
+
+>It would be fairly easy for a downstream of Debian to mandate systemd
+>for their users, and provide Gnome.
+
+>It would not be anywhere near as easy for a downstream of Debian to
+>undo the assumption by Debian (de facto or de jure) of systemd as the
+>one true init system.
+
+>If it comes down to it I would prefer to drop Gnome than to make
+>systemd mandatory for all of Debian's users and downstreams just
+>because Gnome had introduced a hard dependency on systemd.
+
+>Luckily this is all hypothetical.
+
+>Ian.
+
+
+Hi Ian,
+
+
+I know that you are a respected Debian developer, but who are you to decide
+
+alone what kind of software which may be dropped from the archive?
+(I'm refering to ...I would prefer to drop Gnome...).
+
+
+Also, as far as I know Debian cares a lot about its users, who,
+according to popcon, seem to
+
+appreciate GNOME. Don't you care about them? Are you a proponent of a
+caste system in Debian,
+
+where all project that don't follow your precepts and vision risk to
+be kicked outside of Debian?
+
+
+As you have been pretty harsh against people maintaining those, again
+according to your precepts,
+
+second zone projects in Debian, please permit me to be as well, and
+let me tell you that you're a
+
+tiny despot, and you look worse than people you're trying to fight against!
+
+
+Have a good day,
+
+Bastien
+
+
+PS: I know that I'll probably undergo your ire, thus be banned from
+the list; as it seems you can grant you all the rights!
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 18:39:18 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Jason A. Donenfeld" <Jason@zx2c4.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 18:39:18 GMT) (full text, mbox, link).

+ +

Message #4807 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
+
To: 727708@bugs.debian.org
+
Subject: TC Ballot Format
+
Date: Thu, 30 Jan 2014 19:31:05 +0100
+
+
Excuse the ignorance if this suggestion winds up being not any
+different from Ian's current proposal, due to the specifics of the
+Condorcet method. But in case it is, it strikes me that coupling the
+"multiple" vote with the "init" vote allows for more voting options,
+and thus the potential for an unwanted outcome. Currently as I
+understand it, the ballot has these choices: D, DM, U, UM, O, OM, V,
+VM, FD. I would suggest factoring out the "M" choice into a separate
+vote on the same ballot. I would thus propose the following vote:
+
+
+=== Begin misguided suggestion to the TC ===
+
+Question A. Debian will use the following init system as the default
+init on Linux:
+
+D) systemd
+U) upstart
+O) openrc
+V) sysvinit
+FD) further discussion
+
+
+Question B. Debian will allow alternative, non-default, init systems on Linux:
+
+Y) yes
+N) no
+FD) further discussion
+
+
+Question C. The decision of a simple majority GR decision will become
+the TC's decision for questions A and B above.
+
+Y) yes
+N) no
+FD) further discussion
+
+=== End misguided suggestion to the TC ===
+
+
+Obviously the language of each question isn't as tight as it could be,
+but the general suggestion here is that by splitting question A from
+B, I believe we might mitigate some potential surprises...
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 18:45:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Svante Signell <svante.signell@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 18:45:08 GMT) (full text, mbox, link).

+ +

Message #4812 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Svante Signell <svante.signell@gmail.com>
+
To: 727708 <727708@bugs.debian.org>
+
Subject: Regarding sysvinit+openrc/insserv
+
Date: Thu, 30 Jan 2014 19:41:14 +0100
+
+
+Who wrote the parts of sysvinit+openrc and sysvinit+insserv? Maybe that
+person should modify some of the faulty information for these cases.
+
+Some points:
+sysvinit+insserv/openrc:
+D-Bus interfaces: Why are they needed, nothing of this is defined by
+POSIX? And dbus is already heavily depending on systemd on GNU/Linux:
+Build-depends:...
+libsystemd-daemon-dev (>= 32) [linux-any],
+libsystemd-journal-dev (>= 32) [linux-any],
+libsystemd-login-dev (>= 32) [linux-any]
+
+sysvinit+openrc:
+Remove: OpenRC’s support for parallel boot is not production-ready:
+wrong, see the upcoming 0.12.4+20131230-8
+Add: OpenRC is developing quickly, many of the missing features will
+soon be there.
+
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 19:00:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to skirpichev@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 19:00:07 GMT) (full text, mbox, link).

+ +

Message #4817 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sergey B Kirpichev <skirpichev@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal - + Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 22:43:41 +0400
+
+
On Thu, Jan 30, 2014 at 06:47:02PM +0100, Josselin Mouette wrote:
+> Le jeudi 30 janvier 2014 à 21:38 +0400, Sergey B Kirpichev a écrit :
+> > [Lots of crap]
+
+Nice argumentation, as usual...
+
+> > Where is the list of problems for sysvinit we intend to solve?
+> 
+> https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv
+
+* Sysvinit/insserv has very little C code, but the real code size must
+  take shell scripts into account. These scripts come in huge numbers,
+  contain bugs and are hard to maintain.
+
+  - I don't see that this is a big problem.  C is a low-level
+    language and it's a good idea to implement some logic on
+    a high-level scripting language.
+
+* Debugging an init script is a tedious task. [...]
+
+  - Usually it's as simple as to add set +x
+
+* Sysvinit is insufficient for desktops. [...] But the real problems
+  arise on big server setups, where Debian is losing ground because of
+  its antiquated init system.
+
+  - Debian is not only about desktops.
+  - The second part is too subjective.  A counterexample was
+    provided in the reference, mentioned in my previous post.
+
+Is this all?  Sounds like a bad joke.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 19:00:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 19:00:11 GMT) (full text, mbox, link).

+ +

Message #4822 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: "Jason A. Donenfeld" <Jason@zx2c4.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC Ballot Format
+
Date: Thu, 30 Jan 2014 18:56:18 +0000 (UTC)
+
+
Jason A. Donenfeld dixit:
+
+>Question B. Debian will allow alternative, non-default, init systems on Linux:
+
+No, as Ian already explained this will not permit people
+to vote, for example:
+
+A with multiple > B with multiple > B alone > NOTA > A alone
+
+bye,
+//mirabilos
+-- 
+<diogenese> Beware of ritual lest you forget the meaning behind it.
+<igli> yeah but it means if you really care about something, don't
+    ritualise it, or you will lose it. don't fetishise it, don't
+    obsess. or you'll forget why you love it in the first place.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 19:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 19:03:04 GMT) (full text, mbox, link).

+ +

Message #4827 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: init system resolution - revised proposal
+
Date: Thu, 30 Jan 2014 19:00:28 +0000
+
+
We had a good drafting session on IRC.  Here are the results.
+I hereby propose (and propose and do not accept amendments as
+necessary), so as to provide the following options:
+
+  DT   systemd default in jessie, requiring specific init is allowed
+  DL   systemd default in jessie, requiring specific init NOT allowed
+
+  UT   upstart default in jessie, requiring specific init is allowed 
+  UL   upstart default in jessie, requiring specific init NOT allowed
+
+  OT   openrc default in jessie, requiring specific init is allowed
+  OL   openrc default in jessie, requiring specific init NOT allowed
+
+  VT   sysvinit default in jessie, requiring specific init is allowed
+  VL   sysvinit default in jessie, requiring specific init NOT allowed
+
+  GR   project should decide via GR
+
+  FD   further discussion
+
+Each of these consists of the applicable sections from the resolution
+text below (which is in 727708_initsystem/draft-resolution.txt in
+git).
+
+We agreed that we would call for votes on Monday night (let's say,
+18:00 UTC) unless any TC member objects.  We will start voting sooner
+if everyone agrees that this is the good ballot text.
+
+Ian, Bdale, Andy, Don and Russ agreed on IRC that this was a good
+ballot.  Steve, Colin, Keith: let us know, and perhaps we can start
+the vote sooner.
+
+Thanks,
+Ian.
+
+== version D (systemD) ==
+
+   The default init system for Linux architectures in jessie should
+   be systemd.
+
+== version U (Upstart) ==
+
+   The default init system for Linux architectures in jessie should
+   be upstart.
+
+== version O (Openrc) ==
+
+   The default init system for Linux architectures in jessie should
+   be openrc.
+
+== version V (sysVinit) ==
+
+   The default init system for Linux architectures in jessie should
+   be sysvinit (no change).
+
+== version GR (General Resolution) ==
+
+   The Technical Committee requests that the project decide the
+   default init system for jessie by means of General Resolution.
+
+== dependencies rider version T (Tight coupling) ==
+
+   This decision is limited to selecting a default initsystem; we
+   continue to welcome contributions of support for all init systems.
+
+   Software may require a specific init system to be pid 1.
+
+   However, where feasible, software should interoperate with
+   all init systems; maintainers are encouraged to accept
+   technically sound patches to enable interoperation, even if it
+   results in degraded operation while running under the init system
+   the patch enables interoperation with.
+
+== dependencies rider version L (Loose coupling) ==
+
+   This decision is limited to selecting a default initsystem; we
+   continue to welcome contributions of support for all init systems.
+
+   Software outside of an init system's implementation may not require
+   a specific init system to be pid 1, although degraded operation is
+   tolerable.
+
+   Maintainers are encouraged to accept technically sound patches
+   to enable improved interoperation with various init systems.
+
+== rider for all versions except GR ==
+
+   This decision is automatically vacated by any contrary General
+   Resolution which passes by a simple majority.  In that case the
+   General Resolution takes effect and the whole of this TC resolution
+   is to be taken as withdrawn by the TC, just as if the TC had
+   explicitly withdrawn it by a subsequent TC resolution.
+
+-- 
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 19:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 19:09:04 GMT) (full text, mbox, link).

+ +

Message #4832 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: skirpichev@gmail.com, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Thu, 30 Jan 2014 12:05:19 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Sergey B Kirpichev <skirpichev@gmail.com> writes:
+
+> I just wonder why nobody from tect-ctte take care about the exact
+> specification of that "bare minimum" (or, in other words, what exactly
+> is wrong with sysvinit).
+
+In a sense, we all have done this, even if you don't see it explicitly
+written in just this way.  
+
+The thing that may not be obvious is that this line doesn't stand still,
+it is constantly moving as more people develop more free software that
+does newer and better things and in the process builds new dependencies.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 22:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Olav Vitters <ovitters@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 22:57:04 GMT) (full text, mbox, link).

+ +

Message #4837 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Olav Vitters <ovitters@gmail.com>
+
To: skirpichev@gmail.com, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal - + Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 23:55:13 +0100
+
+
On Thu, Jan 30, 2014 at 6:38 PM, Sergey B Kirpichev
+<skirpichev@gmail.com> wrote:
+> On Thu, Jan 30, 2014 at 05:30:04PM +0100, Matthias Klumpp wrote:
+>> GNOME upstream won't really change
+>
+> Why?  There are non-Linux GNOME users, for example.  If the GNOME
+> developers don't care even about such popular distribution as Debian -
+> something is going wrong.  And not with the Debian, for sure.
+
+This has already been answered. GNOME advised all distributors 2 years
+ago. Nothing much happened. Meanwhile, we went ahead and relied more
+on systemd without really depending on systemd. You could implement
+the interfaces of the various bits without depending really on
+systemd.
+
+If after (seems it is going to be) 2.5 years you come back and say
+"we'll, we decided on this" while meanwhile we continued communicating
+our decisions and plans (we plan at least 6 months ahead), then, I
+find phrasings like "don't care even about such popular distributions
+as Debian" offensive. This as we provided ample opportunity to know
+our plans, to discuss, etc.
+
+Anyway, it seems you don't know what systemd provides and from your
+various responses it is pretty clear you cannot be bothered to
+investigate. "It works fine for me" is such an easy answer. Coming
+late to this bugreport and asking questions that have already been
+asked and answered many times before, yet feeling entitled to be able
+to talk about what others did: good luck with that, but as already
+mentioned to other people: I can provide the various emails that we
+reached out and did our best. I can also show you that all the
+questions you're asking have been asked and answered before. Maybe
+investigate a little bit before forming your opinion!
+
+Lastly, we have added *loads* and *loads* of new dependencies over the
+many years GNOME has existed.
+
+Regards,
+Olav
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 30 Jan 2014 23:42:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 30 Jan 2014 23:42:10 GMT) (full text, mbox, link).

+ +

Message #4842 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal - + Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 18:38:46 -0500
+
+
On Thu, Jan 30, 2014 at 12:04 PM, Ian Jackson wrote:
+>> What would be the effecr if we decided to drop GNOME, because it
+>> depends on systemd?
+>
+> In this hypothetical scenario:
+>
+> It would be fairly easy for a downstream of Debian to mandate systemd
+> for their users, and provide Gnome.
+>
+> It would not be anywhere near as easy for a downstream of Debian to
+> undo the assumption by Debian (de facto or de jure) of systemd as the
+> one true init system.
+>
+> If it comes down to it I would prefer to drop Gnome than to make
+> systemd mandatory for all of Debian's users and downstreams just
+> because Gnome had introduced a hard dependency on systemd.
+>
+> Luckily this is all hypothetical.
+
+The only hypothetical situation that would result in dropping gnome is
+one where the TC enacts language barring dependencies on non-default
+init systems.  In all other cases systemd remains in debian, and gnome
+can remain by using systemd.
+
+So, to lets take a step back from this hypothetical cliff by removing
+that idea from the discussion.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 00:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 00:03:04 GMT) (full text, mbox, link).

+ +

Message #4847 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system resolution - revised proposal
+
Date: Thu, 30 Jan 2014 16:01:42 -0800
+
+
A couple of comments inline below.
+
+Ian Jackson wrote:
+> == dependencies rider version T (Tight coupling) ==
+> 
+>    This decision is limited to selecting a default initsystem; we
+>    continue to welcome contributions of support for all init systems.
+> 
+>    Software may require a specific init system to be pid 1.
+> 
+>    However, where feasible, software should interoperate with
+>    all init systems; maintainers are encouraged to accept
+>    technically sound patches to enable interoperation, even if it
+>    results in degraded operation while running under the init system
+>    the patch enables interoperation with.
+> 
+> == dependencies rider version L (Loose coupling) ==
+> 
+>    This decision is limited to selecting a default initsystem; we
+>    continue to welcome contributions of support for all init systems.
+> 
+>    Software outside of an init system's implementation may not require
+>    a specific init system to be pid 1, although degraded operation is
+>    tolerable.
+
+There is an issue with this wording, which I don't think is intended.
+Sometimes, the easiest way to maintain support for multiple init systems
+involves having a family of packages, each of which enables support for
+one init system or family of init systems.  For instance, consider a
+gnome-session-systemd package which uses systemd user sessions, provided
+in parallel with a compatibility package that does not.  Or, consider
+the systemd-shim package.  As written, this clause would prohibit such
+alternative packages, even though *collectively* the packages satisfy
+this requirement.  I would suggest adding language like the following,
+optionally with the following [non-binding] example:
+
+   Packages which form part of a set of alternatives integrating with
+   different init systems need not individually run on other init
+   systems, as long as the packages collectively meet the requirements
+   of this section.  [ For example, a package using systemd to launch a
+   user session, provided as an alternative to a package that runs on
+   sysvinit, need not itself run on sysvinit. ]
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 00:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 00:24:04 GMT) (full text, mbox, link).

+ +

Message #4852 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system resolution - revised proposal
+
Date: Thu, 30 Jan 2014 16:21:05 -0800
+
+
On Thu, 30 Jan 2014, Josh Triplett wrote:
+> Ian Jackson wrote:
+> >    Software outside of an init system's implementation may not require
+> >    a specific init system to be pid 1, although degraded operation is
+> >    tolerable.
+> 
+> For instance, consider a gnome-session-systemd package which uses
+> systemd user sessions, provided in parallel with a compatibility
+> package that does not. Or, consider the systemd-shim package. As
+> written, this clause would prohibit such alternative packages, even
+> though *collectively* the packages satisfy this requirement.
+
+Using "software" instead of "packages" sidesteps this problem, I think,
+since that avoids the technical details of how such compatibility is
+implemented.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+Have you ever noticed: the most vocal superpatriots are the old men
+who send young men out to die.
+ -- Harlan Ellison "Basilisk" (_Deathbird Stories_ p73)
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 01:09:03 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Petr Baudis <pasky@ucw.cz>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 01:09:03 GMT) (full text, mbox, link).

+ +

Message #4857 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Petr Baudis <pasky@ucw.cz>
+
To: debian-ctte@lists.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system resolution - revised proposal
+
Date: Fri, 31 Jan 2014 01:59:25 +0100
+
+
  Hi!
+
+  Apologies for jumping into the discussion even though I'm not a Debian
+Developer.
+
+> == dependencies rider version L (Loose coupling) ==
+> 
+>    This decision is limited to selecting a default initsystem; we
+>    continue to welcome contributions of support for all init systems.
+> 
+>    Software outside of an init system's implementation may not require
+>    a specific init system to be pid 1, although degraded operation is
+>    tolerable.
+> 
+>    Maintainers are encouraged to accept technically sound patches
+>    to enable improved interoperation with various init systems.
+
+  I'd just like to clarify - say we have a scenario (that I assume might
+be realistic) where without systemd, locking screen in GNOME and some
+other fairly basic features do not work (have unfixed bugs, possibly
+with security implications; possibly these features would be entirely
+disabled because of that).  GNOME would also display a warning window on
+login notifying the user that for a proper GNOME experience, they should
+switch their system to systemd.  Some *gnome* packages would have
+Recommends: systemd.
+
+  (Nevertheless, installing (major components of) GNOME might still
+be useful for users that do not wish to use the complete desktop
+environment but perhaps would want to install a variety of GNOME
+applications or work around these issues in their special-purpose
+environment.)
+
+  Would such a particular example of (greatly, but not fatally) degraded
+operation fall within the intent of this proposal?
+
+  Thanks,
+
+				Petr "Pasky" Baudis
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 01:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 01:21:04 GMT) (full text, mbox, link).

+ +

Message #4862 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: skirpichev@gmail.com, 727708@bugs.debian.org, Matthias Klumpp <matthias@tenstral.net>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 17:16:46 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Sergey B Kirpichev <skirpichev@gmail.com> writes:
+
+> Are X-people indeed sacrifice portability, or there is something
+> different (e.g. these dependencies are optional)?
+
+Speaking as the X server release manager, the systemd patches exist
+solely to provide for interoperation with systemd or other similar
+device management processes. None of them eliminate existing device
+management infrastructure at all.
+
+In effect, X takes the Debian position that patches which improve
+interoperabilty with a specific init system should be integrated.
+
+X is most definitely not going to ever require systemd. I think that any
+package which requires a specific init system is broken and I'd work to
+fix any that I depended on.
+
+> Where is the list of problems for sysvinit we intend to solve?
+
+For X, the problem is running X as a user other than root, which should
+provide for increased system security as we'll be reducing the amount of
+root code substantially. Using the systemd mechanisms for sending new
+input devices to the X server solves one of the longstanding issues with
+non-root X.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 01:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 01:24:04 GMT) (full text, mbox, link).

+ +

Message #4867 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system resolution - revised proposal
+
Date: Thu, 30 Jan 2014 17:19:48 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> Ian, Bdale, Andy, Don and Russ agreed on IRC that this was a good
+> ballot.  Steve, Colin, Keith: let us know, and perhaps we can start
+> the vote sooner.
+
+I can vote with this ballot. Sorry I had to disappear in the middle of
+the meeting; that all turned out for naught as the flight I was on got
+canceled, and I'll be home for the weekend after all.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 01:57:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 01:57:10 GMT) (full text, mbox, link).

+ +

Message #4872 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Petr Baudis <pasky@ucw.cz>, 727708@bugs.debian.org, debian-ctte@lists.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system resolution - revised proposal
+
Date: Thu, 30 Jan 2014 18:52:25 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Petr Baudis <pasky@ucw.cz> writes:
+
+>   Would such a particular example of (greatly, but not fatally) degraded
+> operation fall within the intent of this proposal?
+
+I think so, yes.
+
+I do think forcing users who've made a conscious decision to live this
+way to click through a warning pop-up on each login is rather unkind,
+though.  If some mechanism were provided to mark such a thing as "yes,
+I've seen this warning, don't bother me again" until perhaps the next
+GNOME version upgrade, that would seem like a much better way to treat
+such users.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 01:57:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Matthias Klumpp <matthias@tenstral.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 01:57:13 GMT) (full text, mbox, link).

+ +

Message #4877 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Matthias Klumpp <matthias@tenstral.net>
+
To: Keith Packard <keithp@keithp.com>
+
Cc: skirpichev@gmail.com, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal - + Don't like software, don't use it. Absolutely.
+
Date: Fri, 31 Jan 2014 02:53:41 +0100
+
+
2014-01-31 Keith Packard <keithp@keithp.com>:
+> Sergey B Kirpichev <skirpichev@gmail.com> writes:
+> [...]
+>> Where is the list of problems for sysvinit we intend to solve?
+>
+> For X, the problem is running X as a user other than root, which should
+> provide for increased system security as we'll be reducing the amount of
+> root code substantially. Using the systemd mechanisms for sending new
+> input devices to the X server solves one of the longstanding issues with
+> non-root X.
+I was referring to that - of course X does not depend on systemd, but
+systemd provides features which make it possible to fix existing
+issues, that's why it makes sense to use it. Of course it does not
+exclude implementing that stuff in a different, non-systemd tool, but
+to my knowledge nobody has done that yet.
+Thank you for working on X and clarifying this!
+    Matthias
+
+-- 
+I welcome VSRE emails. See http://vsre.info/
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 02:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 02:30:04 GMT) (full text, mbox, link).

+ +

Message #4882 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Matthias Klumpp <matthias@tenstral.net>
+
Cc: skirpichev@gmail.com, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
+
Date: Thu, 30 Jan 2014 18:26:37 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Matthias Klumpp <matthias@tenstral.net> writes:
+
+> Of course it does not exclude implementing that stuff in a different,
+> non-systemd tool, but to my knowledge nobody has done that yet.
+
+Exactly so. I have ideas on how this might work in a simpler and more
+general fashion, but people rarely listen to ideas without also seeing
+working code :-)
+-- 
+
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 08:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 08:30:04 GMT) (full text, mbox, link).

+ +

Message #4887 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system resolution - revised proposal
+
Date: Fri, 31 Jan 2014 00:27:37 -0800
+
+
Don Armstrong wrote:
+> On Thu, 30 Jan 2014, Josh Triplett wrote:
+> > Ian Jackson wrote:
+> > >    Software outside of an init system's implementation may not require
+> > >    a specific init system to be pid 1, although degraded operation is
+> > >    tolerable.
+> >
+> > For instance, consider a gnome-session-systemd package which uses
+> > systemd user sessions, provided in parallel with a compatibility
+> > package that does not. Or, consider the systemd-shim package. As
+> > written, this clause would prohibit such alternative packages, even
+> > though *collectively* the packages satisfy this requirement.
+>
+> Using "software" instead of "packages" sidesteps this problem, I think,
+> since that avoids the technical details of how such compatibility is
+> implemented.
+
+How confident are you that the entire technical committee and the
+community of people filing bugs in the future will share your
+interpretation of that statement in the resolution, versus the
+interpretation that would result in an automatic RC bug on *any* package
+that "Depends: systemd-sysv" (or logical equivalent), even if an
+alternative package exists?  And to ask the reverse question: given your
+interpretation above, how averse are you to making some kind of
+clarification along the lines of what you said above official rather
+than unofficial?  I'd hate to see people arguing over this ruling later
+if a one-sentence clarification could make it completely unambiguous.
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 08:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 08:36:05 GMT) (full text, mbox, link).

+ +

Message #4892 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Fri, 31 Jan 2014 09:33:33 +0100
+
+
Le jeudi 30 janvier 2014 à 14:40 +0000, Ian Jackson a écrit : 
+>   D DM U UM O OM V VM GR and of course FD
+
+[snip text for 10 different options]
+
+> == optional rider M (Multiple init systems) ==
+> 
+>    Debian intends to support multiple init systems, for the
+>    foreseeable future, and so long as their respective communities
+>    and code remain healthy.
+> 
+>    Where feasible, software should interoperate with non-default
+>    init systems; maintainers are encouraged to accept technically
+>    sound patches to enable interoperation, even if it results in
+>    degraded operation while running under the init system the patch
+>    enables interoperation with.
+
+Since this text just recommends common sense and is not even mandatory,
+I wonder what it is trying to achieve.
+
+Given the Condorcet voting method is susceptible to tactical voting,
+especially when the votes are public, I fear it would make it very
+tempting for some members to manipulate the vote using this added
+complexity.
+
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 08:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 08:42:04 GMT) (full text, mbox, link).

+ +

Message #4897 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal + - Don't like software, don't use it. Absolutely.
+
Date: Fri, 31 Jan 2014 09:38:45 +0100
+
+
Le jeudi 30 janvier 2014 à 22:43 +0400, Sergey B Kirpichev a écrit : 
+> > https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv
+
+Since you forgot to paste the first sentence, let me add it here.
+
+“Sysvinit was never designed to cope with the dynamic/event-based
+architecture of the current Linux kernel. The only reason why we still
+use it today is the cost of a migration.”
+
+> Is this all?
+
+Yes, this is all. Anyone who knows how Linux works doesn’t consider
+sysvinit a viable choice today. There is no need for lengthy
+argumentations, because there is nothing to argue against.
+
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 10:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to skirpichev@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 10:15:05 GMT) (full text, mbox, link).

+ +

Message #4902 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sergey B Kirpichev <skirpichev@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Fri, 31 Jan 2014 14:07:13 +0400
+
+
(I was informed, that my posts are not welcome anymore here.  So,
+there is last one for all.)
+
+On Thu, Jan 30, 2014 at 12:05:19PM -0700, Bdale Garbee wrote:
+> Sergey B Kirpichev <skirpichev@gmail.com> writes:
+> > I just wonder why nobody from tect-ctte take care about the exact
+> > specification of that "bare minimum" (or, in other words, what exactly
+> > is wrong with sysvinit).
+> 
+> In a sense, we all have done this, even if you don't see it explicitly
+> written in just this way.
+
+Sorry.  Maybe it's clear from the thread for others, that this
+specification is somewhere in minds of all tech-ctte members...
+
+But I doubt if it's so, as I was kindly pointed out to
+https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv
+Is this all (what we want to fix in sysvinit/what we want to have
+in the modern init)?
+
+And that wasn't clear for others, otherwise I can't explain, for example,
+the questions why OpenRC was silently discarded from reviews.
+
+> The thing that may not be obvious is that this line doesn't stand still,
+> it is constantly moving as more people develop more free software that
+> does newer and better things and in the process builds new dependencies.
+
+Old init was working for years.  Are we only buy something
+that satisfy the new dependencies (for the Gnome) or a new
+init, that would work for comparable time?
+
+On Thu, Jan 30, 2014 at 05:16:46PM -0800, Keith Packard wrote:
+> In effect, X takes the Debian position that patches which improve
+> interoperabilty with a specific init system should be integrated.
+
+Seems to be sane and reasonable position.  I wonder why Gnome
+people can't follow this.
+
+>> Where is the list of problems for sysvinit we intend to solve?
+> For X, the problem is running X as a user other than root
+
+(There are sysvinit-enabled setups even without X...)
+
+On Fri, Jan 31, 2014 at 09:38:45AM +0100, Josselin Mouette wrote:
+> > > https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv
+> Since you forgot to paste the first sentence, let me add it here.
+> 
+> “Sysvinit was never designed to cope with the dynamic/event-based
+> architecture of the current Linux kernel. The only reason why we still
+> use it today is the cost of a migration.”
+
+I'm not forgot, because it's not the only reason - please
+see the mentioned example.
+
+> Anyone who knows how Linux works doesn’t consider
+> sysvinit a viable choice today.
+
+I'm sure Google sysadmins know how Linux works, still
+they consider sysvinit to be a viable (and preferred) choice.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 11:57:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Neil McGovern <neilm@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 11:57:10 GMT) (full text, mbox, link).

+ +

Message #4907 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Neil McGovern <neilm@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Fri, 31 Jan 2014 11:55:40 +0000
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Jan 31, 2014 at 09:33:33AM +0100, Josselin Mouette wrote:
+> Given the Condorcet voting method is susceptible to tactical voting,
+
+Hi Josselin,
+
+I'm not sure what you mean here, could you care to elaborate?
+
+Neil
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 12:09:03 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 12:09:04 GMT) (full text, mbox, link).

+ +

Message #4912 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system resolution - revised proposal
+
Date: Fri, 31 Jan 2014 12:05:06 +0000
+
+
Josh Triplett writes ("Bug#727708: init system resolution - revised proposal"):
+> A couple of comments inline below.
+...
+> There is an issue with this wording, which I don't think is intended.
+> Sometimes, the easiest way to maintain support for multiple init systems
+> involves having a family of packages, each of which enables support for
+> one init system or family of init systems.  For instance, consider a
+> gnome-session-systemd package which uses systemd user sessions, provided
+> in parallel with a compatibility package that does not.  Or, consider
+> the systemd-shim package.  As written, this clause would prohibit such
+> alternative packages, even though *collectively* the packages satisfy
+> this requirement.  I would suggest adding language like the following,
+> optionally with the following [non-binding] example:
+
+This is why we use the word "software", not "packages".
+
+>    Packages which form part of a set of alternatives integrating with
+>    different init systems need not individually run on other init
+>    systems, as long as the packages collectively meet the requirements
+>    of this section.  [ For example, a package using systemd to launch a
+>    user session, provided as an alternative to a package that runs on
+>    sysvinit, need not itself run on sysvinit. ]
+
+I agree with the intent here but I think it's best done in policy
+rather than in the TC resolution.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 12:09:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 12:09:07 GMT) (full text, mbox, link).

+ +

Message #4917 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Keith Packard <keithp@keithp.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system resolution - revised proposal
+
Date: Fri, 31 Jan 2014 12:05:55 +0000
+
+
Keith Packard writes ("Re: Bug#727708: init system resolution - revised proposal"):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > Ian, Bdale, Andy, Don and Russ agreed on IRC that this was a good
+> > ballot.  Steve, Colin, Keith: let us know, and perhaps we can start
+> > the vote sooner.
+> 
+> I can vote with this ballot.
+
+Thanks.
+
+> Sorry I had to disappear in the middle of
+> the meeting; that all turned out for naught as the flight I was on got
+> canceled, and I'll be home for the weekend after all.
+
+Well, I guess you get a weekend at home as compensation for the
+hassle.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 12:09:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 12:09:10 GMT) (full text, mbox, link).

+ +

Message #4922 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system resolution - revised proposal
+
Date: Fri, 31 Jan 2014 12:07:34 +0000
+
+
Josh Triplett writes ("Bug#727708: init system resolution - revised proposal"):
+> How confident are you that the entire technical committee and the
+> community of people filing bugs in the future will share your
+> interpretation of that statement in the resolution,
+
+I'm confident that the policy maintainers will flesh out the meaning
+appropriately.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 13:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to srs@kth.se:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 13:54:04 GMT) (full text, mbox, link).

+ +

Message #4927 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Svante Signell <srs@kth.se>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system resolution - revised proposal
+
Date: Fri, 31 Jan 2014 14:41:10 +0100
+
+
To CTTE,
+
+In the wait for your decision next week, many of us assume that you take
+into consideration the many misleading and false statements that have
+been written about about sysvinit + openrc/insserv.
+
+Additionally, consider this, please:
+Adopting systemd (and gnome, dbus->kdbus, wayland, etc depending on it)
+is very dangerous for the future of Free Software :-(
+
+(I wonder which view FSF would have if they had been involved)
+
+Thanks, have a nice weekend!
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 14:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sébastien Villemot <sebastien@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 14:06:05 GMT) (full text, mbox, link).

+ +

Message #4932 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sébastien Villemot <sebastien@debian.org>
+
To: Neil McGovern <neilm@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Fri, 31 Jan 2014 15:02:21 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Le vendredi 31 janvier 2014 à 11:55 +0000, Neil McGovern a écrit :
+> On Fri, Jan 31, 2014 at 09:33:33AM +0100, Josselin Mouette wrote:
+> > Given the Condorcet voting method is susceptible to tactical voting,
+> 
+> Hi Josselin,
+> 
+> I'm not sure what you mean here, could you care to elaborate?
+
+Here is my understanding of the issue, on a simplified example.
+
+Let's restrict to the following 4 options from the last draft ballot:
+
+  DT   systemd default in jessie, requiring specific init is allowed
+  DL   systemd default in jessie, requiring specific init NOT allowed
+
+  UT   upstart default in jessie, requiring specific init is allowed 
+  UL   upstart default in jessie, requiring specific init NOT allowed
+
+And let's suppose that the CTTE has 4 members: P1 (the chairman), P2, P3
+and P4. Let's suppose that the vote is as follows:
+
+P1: DT > UT > DL > UL
+P2: DL > UL > DT > UT
+P3: UT > UL > DL > DT
+P4: UT > UL > DL > DT
+
+P1 and P2 both prefer systemd over upstart, while P3 and P4 prefer
+upstart over systemd. But P1 and P2 disagree on the coupling question (T
+versus L), while P3 and P4 agree with each other.
+
+The Condorcet winner of this vote is UT (and note that the casting vote
+of P1 is not needed here, since UT is alone in the Schwartz set).
+
+This result is not necessarily what one would have expected beforehand.
+In particular, if the ballot had not included the options about
+coupling, then systemd would have won because of the casting vote of the
+chairman.
+
+Fundamentally, the reason of the victory of upstart in this hypothetical
+vote is that systemd proponents prefer to lose on the coupling question
+rather than on the init system question, while the upstart proponents
+have the opposite preference over the relative importance of these two
+questions.
+
+Of course, in the alternative scenario with two consecutive ballots (one
+on the init, followed by one on the coupling), it would not have been
+possible to express this preference over the relative importance of the
+two questions, so one could argue that this is a feature of the single
+ballot with all options.
+
+Still, my example shows that putting the two questions on the same
+ballot is not just about letting people express different coupling
+choices for different init systems. It can have the more fundamental
+effect of changing the winning init system.
+
+-- 
+ .''`.    Sébastien Villemot
+: :' :    Debian Developer
+`. `'     http://www.dynare.org/sebastien
+  `-      GPG Key: 4096R/381A7594
+
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 14:09:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 14:09:10 GMT) (full text, mbox, link).

+ +

Message #4937 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Fri, 31 Jan 2014 15:06:50 +0100
+
+
Hi Neil,
+
+Le vendredi 31 janvier 2014 à 11:55 +0000, Neil McGovern a écrit : 
+> On Fri, Jan 31, 2014 at 09:33:33AM +0100, Josselin Mouette wrote:
+> > Given the Condorcet voting method is susceptible to tactical voting,
+
+> I'm not sure what you mean here, could you care to elaborate?
+
+Wikipedia has a nice description of how tactical voting works:
+http://en.wikipedia.org/wiki/Tactical_voting#Types_of_tactical_voting
+
+In the current example, a voter can rank insincerely her init system
+choices after #1, in order to give less chances to the one she would
+have ranked #2 sincerely.
+
+With only two realistic options (systemd / upstart), this problem
+doesn’t exist. But introducing more options on the ballot, it becomes
+possible to obtain a rigged outcome. The vote being public, it is all
+the more easier to see how you should rank other options than your
+preference in order to defeat them all.
+
+Cheers,
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 14:15:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 14:15:09 GMT) (full text, mbox, link).

+ +

Message #4942 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: Sébastien Villemot <sebastien@debian.org>, + 727708@bugs.debian.org
+
Cc: Neil McGovern <neilm@debian.org>
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Fri, 31 Jan 2014 14:13:59 +0000
+
+
[Message part 1 (text/plain, inline)]
+
On 31/01/14 14:02, Sébastien Villemot wrote:
+> P1: DT > UT > DL > UL
+> P2: DL > UL > DT > UT
+> P3: UT > UL > DL > DT
+> P4: UT > UL > DL > DT
+
+> Of course, in the alternative scenario with two consecutive ballots (one
+> on the init, followed by one on the coupling), it would not have been
+> possible to express this preference over the relative importance of the
+> two questions, so one could argue that this is a feature of the single
+> ballot with all options.
+
+Yes I think this is by design, and IMHO desirable.  Imagine if the
+questions were uncoupled and decided in *reverse* order, someone might
+decide to compromise on their choice of init system, due to the result
+of the first decision making their original choice less palatable.  I
+think that's what people are expressing in their vote.
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 14:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 14:33:05 GMT) (full text, mbox, link).

+ +

Message #4947 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: Sébastien Villemot <sebastien@debian.org>, + 727708@bugs.debian.org
+
Cc: Neil McGovern <neilm@debian.org>
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Fri, 31 Jan 2014 14:30:11 +0000
+
+
[Message part 1 (text/plain, inline)]
+
On 31/01/14 14:02, Sébastien Villemot wrote:
+> the reason of the victory of upstart in this hypothetical
+> vote is that systemd proponents prefer to lose on the coupling question
+> rather than on the init system question
+
+If having systemd is still a preference despite the outcome of the other
+question, you can avoid losing on it by simply putting the systemd
+options with equal preference:
+
+DT = DL > UL > UT
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 16:09:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 16:09:09 GMT) (full text, mbox, link).

+ +

Message #4952 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Sébastien Villemot <sebastien@debian.org>, + 727708@bugs.debian.org
+
Cc: Neil McGovern <neilm@debian.org>
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Fri, 31 Jan 2014 18:06:35 +0200
+
+
On Fri, Jan 31, 2014 at 03:02:21PM +0100, Sébastien Villemot wrote:
+> Le vendredi 31 janvier 2014 à 11:55 +0000, Neil McGovern a écrit :
+> > On Fri, Jan 31, 2014 at 09:33:33AM +0100, Josselin Mouette wrote:
+> > > Given the Condorcet voting method is susceptible to tactical voting,
+> > 
+> > Hi Josselin,
+> > 
+> > I'm not sure what you mean here, could you care to elaborate?
+> 
+> Here is my understanding of the issue, on a simplified example.
+> 
+> Let's restrict to the following 4 options from the last draft ballot:
+> 
+>   DT   systemd default in jessie, requiring specific init is allowed
+>   DL   systemd default in jessie, requiring specific init NOT allowed
+> 
+>   UT   upstart default in jessie, requiring specific init is allowed 
+>   UL   upstart default in jessie, requiring specific init NOT allowed
+> 
+> And let's suppose that the CTTE has 4 members: P1 (the chairman), P2, P3
+> and P4. Let's suppose that the vote is as follows:
+> 
+> P1: DT > UT > DL > UL
+> P2: DL > UL > DT > UT
+> P3: UT > UL > DL > DT
+> P4: UT > UL > DL > DT
+> 
+> P1 and P2 both prefer systemd over upstart, while P3 and P4 prefer
+> upstart over systemd. But P1 and P2 disagree on the coupling question (T
+> versus L), while P3 and P4 agree with each other.
+> 
+> The Condorcet winner of this vote is UT (and note that the casting vote
+> of P1 is not needed here, since UT is alone in the Schwartz set).
+> 
+> This result is not necessarily what one would have expected beforehand.
+> In particular, if the ballot had not included the options about
+> coupling, then systemd would have won because of the casting vote of the
+> chairman.
+> 
+> Fundamentally, the reason of the victory of upstart in this hypothetical
+> vote is that systemd proponents prefer to lose on the coupling question
+> rather than on the init system question, while the upstart proponents
+> have the opposite preference over the relative importance of these two
+> questions.
+> 
+> Of course, in the alternative scenario with two consecutive ballots (one
+> on the init, followed by one on the coupling), it would not have been
+> possible to express this preference over the relative importance of the
+> two questions, so one could argue that this is a feature of the single
+> ballot with all options.
+>...
+
+I would argue your example shows the voters not understanding how the 
+voting system works...
+
+Quoting the Debian Constitution:
+  Options which the voters rank above the default option are options
+  they find acceptable. Options ranked below the default options are 
+  options they find unacceptable. 
+
+If in your example P1 and P2 would both rank FD (the default option 
+"further discussion") second, then DL wins.
+
+And if additionally P3 and P4 would rank FD second or third, then FD wins.
+
+The casting vote of the chairman sounds more powerful than it is in 
+actually, since in any situation between two options where no option has 
+a majority of at least the quorum, each side can prevent the other side 
+from winning.
+
+So if for example 4 members of the TC would say "only systemd is an 
+acceptable choice", and the other 4 members of the TC would say "only 
+upstart is an acceptable choice", then any result other than "further 
+discussion" would be caused by a voting error.
+
+And this is not a problem of the Condorcet voting system, this is due to 
+the explicit statement "There is a quorum of two." in the Constitution.
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 17:45:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 17:45:07 GMT) (full text, mbox, link).

+ +

Message #4957 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Josselin Mouette <joss@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Fri, 31 Jan 2014 10:41:00 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Josselin Mouette <joss@debian.org> writes:
+
+>> == optional rider M (Multiple init systems) ==
+>> 
+>>    Debian intends to support multiple init systems, for the
+>>    foreseeable future, and so long as their respective communities
+>>    and code remain healthy.
+>> 
+>>    Where feasible, software should interoperate with non-default
+>>    init systems; maintainers are encouraged to accept technically
+>>    sound patches to enable interoperation, even if it results in
+>>    degraded operation while running under the init system the patch
+>>    enables interoperation with.
+>
+> Since this text just recommends common sense and is not even mandatory,
+> I wonder what it is trying to achieve.
+
+We discussed this in our IRC meeting yesterday, largely because I asked
+the same question.  The consensus was that "common sense isn't really
+that common", and including such text might help reduce the number of
+questions that come up and have to be answered later. 
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 19:03:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 19:03:09 GMT) (full text, mbox, link).

+ +

Message #4962 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Fri, 31 Jan 2014 10:58:17 -0800
+
+
On Fri, 31 Jan 2014, Josselin Mouette wrote:
+> With only two realistic options (systemd / upstart), this problem
+> doesn’t exist. But introducing more options on the ballot, it becomes
+> possible to obtain a rigged outcome. The vote being public, it is all
+> the more easier to see how you should rank other options than your
+> preference in order to defeat them all.
+
+If this actually becomes the case, we can vote again, or change our
+votes. Burying will be pretty obvious in this case, after all.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+One day I put instant coffee in my microwave oven and almost went back
+in time.
+ -- Steven Wright
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 31 Jan 2014 20:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 31 Jan 2014 20:30:04 GMT) (full text, mbox, link).

+ +

Message #4967 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Fri, 31 Jan 2014 12:28:15 -0800
+
+
On Fri, 31 Jan 2014, Don Armstrong wrote:
+> If this actually becomes the case, we can vote again, or change our
+> votes. Burying will be pretty obvious in this case, after all.
+
+Scratch what I said.
+
+Given that there isn't actually a potential compromise winner in this
+case, or anyone who has expressed a preference to rank the a compromise
+winner over any of the two front-running options, I can't personally
+come up with a case where burying could actually happen.
+
+If you believe that I'm mistaken, please provide an actual example
+relevant to this particular ballot (and stated preferences) where this
+could actually occur.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+Identical parts aren't.
+ -- Beach's Law
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 17:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 17:15:05 GMT) (full text, mbox, link).

+ +

Message #4972 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Sebastien Villemot <sebastien@debian.org>, + 727708@bugs.debian.org
+
Cc: Neil McGovern <neilm@debian.org>
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Sat, 1 Feb 2014 17:10:55 +0000
+
+
Sébastien Villemot writes ("Bug#727708: TC resolution revised draft"):
+> P1: DT > UT > DL > UL
+> P2: DL > UL > DT > UT
+> P3: UT > UL > DL > DT
+> P4: UT > UL > DL > DT
+
+This is a nice example which actually demonstrates why these questions
+need to be voted on in a single ballot.
+
+If one votes on T-vs-L before U-vs-D, P3 and P4 don't know how to vote
+on T-vs-L until they know how the vote on U-vs-D will turn out.
+
+And of course the order would have to be fixed, and not depend on
+assumptions about the preferences of the voters; so it's not an answer
+to say "then we'll do U-vs-D first".
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 18:06:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 18:06:14 GMT) (full text, mbox, link).

+ +

Message #4977 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Sat, 01 Feb 2014 20:05:09 +0200
+
+
On Sat, 2014-02-01 at 17:10 +0000, Ian Jackson wrote:
+> Sébastien Villemot writes ("Bug#727708: TC resolution revised draft"):
+> > P1: DT > UT > DL > UL
+> > P2: DL > UL > DT > UT
+> > P3: UT > UL > DL > DT
+> > P4: UT > UL > DL > DT
+> 
+> This is a nice example which actually demonstrates why these questions
+> need to be voted on in a single ballot.
+> 
+> If one votes on T-vs-L before U-vs-D, P3 and P4 don't know how to vote
+> on T-vs-L until they know how the vote on U-vs-D will turn out.
+
+I believe that part was just a typo in the message you're replying to,
+and it should be "UT > UL > DT > DL" for P3 and P4. He wouldn't have
+written about "relative importance of these two questions" if he had
+intended the answer to one question to change depending on the answer to
+the other.
+
+So his example was one where the D/U and L/T choices were independent
+for every voter, but combining them into a single ballot produced a
+result different from the expected result of voting on each independent
+question separately.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 19:15:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 19:15:17 GMT) (full text, mbox, link).

+ +

Message #4982 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Keith Packard <keithp@keithp.com>, 727708@bugs.debian.org
+
Cc: Bdale Garbee <bdale@gag.com>, + Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Sat, 1 Feb 2014 11:35:18 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Jan 28, 2014 at 09:23:11AM -0800, Keith Packard wrote:
+> Bdale Garbee <bdale@gag.com> writes:
+
+> > Thus, I believe the only acceptable option for Q2 from among your set is
+> > "requiring a specific init is permitted even if it is not the default
+> > one".  But I would prefer to vote a ballot that doesn't mention
+> > dependencies at all.
+
+> I agree with this; I don't think we should try to force developers into
+> significant work to satisfy an init system constraint as that may
+> prevent or delay important fixes and improvements from entering the
+> repository.
+
+> Of course, nothing would prevent someone else from fixing these kinds of
+> bugs and having those fixes get merged into the package, potentially
+> invoking §6.1.4 to have the tech-ctte resolve any conflict as needed.
+> However, I'd anticipate that most package developers would readily
+> accept fixes that made their packages work for more people.
+
+I'd like to believe this; however, the fact that bug #726763 is still open
+leads me to fear otherwise.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 19:15:21 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 19:15:21 GMT) (full text, mbox, link).

+ +

Message #4987 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>, Josselin Mouette <joss@debian.org>, + Olav Vitters <ovitters@gmail.com>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sat, 1 Feb 2014 11:25:01 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Jan 29, 2014 at 10:13:25PM +0200, Adrian Bunk wrote:
+> No, Josselin was making the technical claim that GNOME 3.10 would need a 
+> working logind even for basic functionality.
+
+> So if it is possible to get the basic functionality of GNOME 3.10 
+> without a working logind, his claim is just plain wrong.
+
+> And when I was asking him for the technical details that would back up 
+> such a strong claim, he was not able to deliver.
+
+> And that does matter a lot, since such claims seem to be the basis
+> of all these "GNOME in jessie needs systemd" or "with multiple init 
+> systems, GNOME will need a dependency on systemd" (and Josselin even 
+> expects an exception from the release managers for that if the TC 
+> decision would not allow such a dependency [1]).
+
+Whether or not it's possible for GNOME in jessie to be made to work without
+logind, I agree with the GNOME team that logind is a reasonable dependency
+for GNOME to have on Linux.
+
+What is not reasonable is the chain of logic that leads from "GNOME should
+use logind" to "GNOME will require systemd as the init system".  logind v204
+(and the other systemd dbus services) have been made to run on
+non-systemd-PID1 systems.  Work is ongoing to provide an alternative
+implementation of a cgroup single-writer, that can then expose a
+systemd-compatible interface for use with logind v205.  These are not
+blue-sky hypotheticals; the first exists in Debian unstable already as the
+systemd-shim package, the second is available as an upstream project
+(http://cgmanager.linuxcontainers.org/) that will be suitable for use in
+Debian well before the jessie release.  And I have already offered my
+support to the systemd maintainers to support this configuration going
+forward.
+
+Yet when I challenge the assertion that "desktop N will require systemd,
+therefore Debian must adopt systemd as PID 1", which has been repeated
+endlessly in this discussion, I am chided for being insufficiently courteous
+to people who do not have the facts on their side.
+
+I have previously suggested that the GNOME team has a reputation for
+obstructionism.  I owe the GNOME team an apology for this; as was made clear
+to me, in my efforts to not overly personalize the discussion, I instead
+erred in the opposite direction by tarring the entire GNOME team with the
+same brush.  I will instead limit my criticism to Josselin, who despite
+giving the impression of being the spokesman for the GNOME team, is
+apparently not speaking for the team as he seeks to cloud the issues around
+the technical choices that face this committee.
+
+Assertions that desktops' dependencies on logind dictate the use of systemd
+as PID1 are at best a self-fulfilling prophecy which creates a climate in
+which people are dissuaded from even trying to do the work to provide
+alternatives because they believe these efforts will be blocked by the GNOME
+team; and at worst, an overt attempt to distort the TC's debate on the init
+question.
+
+Josselin has asserted not only that he considers systemd-as-init a hard
+dependency for GNOME in jessie, but that he expects the release team to side
+with him over the Technical Committee if the TC does not agree with him.
+This is unconscionable, given that there are two very straightforward and
+obvious technical solutions to this problem:
+
+ - split the systemd package (as previously discussed) into separate
+   binaries, for the init system vs. the dbus interfaces, and have GNOME
+   depend on the latter
+ - have the systemd package declare one or more virtual packages via
+   Provides:, which GNOME packages depend on and one or more alternative
+   implementations may also provide.
+
+It is possible that, at the end of the release cycle, there will be only one
+viable implementation of these interfaces, and Josselin's prediction will be
+proven out.  However, it is crucially not the place of GNOME maintainers to
+decide a priori that this *will* be the case, particularly when it should be
+clear to everyone that there are developers (myself included) interested in
+doing the work to make these dbus services work on top of other init
+systems.  This is contrary to the spirit of Debian, and contrary to the very
+principle of "reasonable accomodation" that Russ espoused on this very bug
+last month.
+
+
+And so I am greatly dismayed by the position Russ and Bdale have taken in
+this discussion with respect to packages being allowed to depend on a
+specific init system.  Both have expressed the opinion that Debian should
+remain open to alternative init implementations as long as there are
+developers willing to do the work; but when it comes to concrete examples of
+ways in which conflation between init system (that is, service registration
+and service management) interfaces and dbus service interfaces directly
+interfere with that goal, they have been unwilling to stand up for the
+relevant technical principle.  This despite the fact that the burden on the
+GNOME maintainers to support alternate implementations of these dbus
+services is much lower than the burden of providing sysvinit startup
+compatibility in jessie for an upstream project that doesn't support it.
+
+As Philipp Kern points out in
+<41b26b373019ab39ebff223603a085d1@hub.kern.lc>, this leaves us with the very
+real possibility that we will wind up with mutually incompatible sets of
+packages in the archive for jessie that are no longer coinstallable, not
+because the packages themselves have conflicting functionality, but because
+they've taken sides - intentionally or unintentionally - on the init system
+question.  If we don't think such fragmentation of the Debian archive is an
+acceptable outcome (and I for one don't see any reason it should be), then
+we should say as much in our resolution.  The committee has a duty to
+provide strong technical guidance to the project, not just to get involved
+after something has gone off the rails.
+
+If we *aren't* going to provide such technical guidance about how we expect
+multiple init systems to coexist in the archive, then we should not pay lip
+service to the idea of supporting multiple init systems and should instead
+explicitly declare that only one init system is supported.
+
+Thus, for me, all of the "T" variants in Ian's latest draft
+(<21226.41292.366504.997315@chiark.greenend.org.uk>) rank below FD.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+\
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 19:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 19:33:04 GMT) (full text, mbox, link).

+ +

Message #4992 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sat, 1 Feb 2014 19:28:49 +0000
+
+
Steve Langasek writes ("Bug#727708: multiple init systems - formal resolution proposal"):
+> [stuff]
+
+Thanks for that, which I mostly agree with.
+
+On Wed, Jan 29, 2014 at 10:13:25PM +0200, Adrian Bunk wrote:
+> Thus, for me, all of the "T" variants in Ian's latest draft
+> (<21226.41292.366504.997315@chiark.greenend.org.uk>) rank below FD.
+
+In my mail following the irc meeting I formally proposed the options
+you see listed in that message: {U,D,O,V}{T,F} and GR and FD.
+
+Are you satisfied that the wordings I propose there properly capture
+the essence of the disagreement ?  (You haven't said this explicitly,
+but I get the impression that you think they do.)
+
+If not then please say so right away.  If you have better ideas you
+should probably formally propose amendment(s), since the current
+situation is that we are in the discussion period and are likely to
+start the vote on Monday.
+
+If you _are_ satisfied that the options on the ballot sufficiently
+capture the essence of the dispute, then saying so would be helpful as
+it might allow us to start the vote sooner.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 19:33:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 19:33:08 GMT) (full text, mbox, link).

+ +

Message #4997 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve Langasek <vorlon@debian.org>, + 727708@bugs.debian.org
+
Cc: Adrian Bunk <bunk@stusta.de>, + Russ Allbery <rra@debian.org>, + Josselin Mouette <joss@debian.org>, + Olav Vitters <ovitters@gmail.com>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sat, 1 Feb 2014 19:31:36 +0000
+
+
Steve Langasek writes ("Bug#727708: multiple init systems - formal resolution proposal"):
+> Thus, for me, all of the "T" variants in Ian's latest draft
+> (<21226.41292.366504.997315@chiark.greenend.org.uk>) rank below FD.
+
+Note that there is a difference, of course, between GR and FD, in the
+voting system.  If the vote on option X vs GR is 4:4, Bdale might be
+able to use his casting vote in favour of X.  If the vote on option X
+vs FD is 4:4, the option is eliminated and cannot win.
+
+Personally, for this reason, I am not going to rank any options
+between GR and FD.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 19:45:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 19:45:07 GMT) (full text, mbox, link).

+ +

Message #5002 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org, Adrian Bunk <bunk@stusta.de>, Josselin Mouette <joss@debian.org>, Olav Vitters <ovitters@gmail.com>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sat, 01 Feb 2014 11:41:04 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> And so I am greatly dismayed by the position Russ and Bdale have taken
+> in this discussion with respect to packages being allowed to depend on a
+> specific init system.  Both have expressed the opinion that Debian
+> should remain open to alternative init implementations as long as there
+> are developers willing to do the work; but when it comes to concrete
+> examples of ways in which conflation between init system (that is,
+> service registration and service management) interfaces and dbus service
+> interfaces directly interfere with that goal, they have been unwilling
+> to stand up for the relevant technical principle.
+
+You can be dismayed all you want, but I completely disagree with you about
+the shape of the relevant principle.
+
+There is a huge difference between being open to alternative init
+implementations and requiring that maintainers implement support for
+alternative init systems, which is what the loose coupling option
+requires.  The latter is, in my opinion, effectively an attempt to coerce
+maintainers into doing work they don't want to do by holding their
+packages hostage, which is something that I think we should only do for
+things that are absolutely vital to the project.  And I don't believe this
+is.
+
+What I want to see is people working with the relevant maintainers,
+understanding their concerns and issues, and find a way to provide
+maintainable support, not just asking the Technical Committee to force
+other people to change how they maintain their packages well in advance of
+actual irresolvable impasses.  And when no one has done the work to port a
+particular package to another init system, preventing that current reality
+from being properly represented in dependencies just makes the
+distribution more technically fragile without any real gain for our users.
+
+> This despite the fact that the burden on the GNOME maintainers to
+> support alternate implementations of these dbus services is much lower
+> than the burden of providing sysvinit startup compatibility in jessie
+> for an upstream project that doesn't support it.
+
+The reason why requiring sysvinit startup compatibility makes sense to me
+is because everything in the archive *already* has sysvinit startup
+capability, and therefore what we're asking for is for maintainers to
+sustain the status quo through jessie as much as possible so that we can
+manage an orderly upgrade.
+
+I certainly hope that we're not going to have to maintain sysvinit scripts
+indefinitely.
+
+> As Philipp Kern points out in
+> <41b26b373019ab39ebff223603a085d1@hub.kern.lc>, this leaves us with the
+> very real possibility that we will wind up with mutually incompatible
+> sets of packages in the archive for jessie that are no longer
+> coinstallable, not because the packages themselves have conflicting
+> functionality, but because they've taken sides - intentionally or
+> unintentionally - on the init system question.  If we don't think such
+> fragmentation of the Debian archive is an acceptable outcome (and I for
+> one don't see any reason it should be), then we should say as much in
+> our resolution.  The committee has a duty to provide strong technical
+> guidance to the project, not just to get involved after something has
+> gone off the rails.
+
+If you want to explicitly say that packages are required to support the
+default init system, then you should propose language.  That's not what
+the loose coupling option says.  The loose coupling option says that all
+packages must support *all* init systems, with some possible degredation
+of operation.  I believe that effectively locks us into supporting
+sysvinit scripts forever, since no alternative universal common
+denominator seems to be emerging.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + + + + + +Added indication that bug 727708 blocks 726763 +Request was from Josh Triplett <josh@joshtriplett.org> +to control@bugs.debian.org. + (Sat, 01 Feb 2014 20:09:23 GMT) (full text, mbox, link).

+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 20:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 20:18:04 GMT) (full text, mbox, link).

+ +

Message #5009 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Sat, 1 Feb 2014 12:15:14 -0800
+
+
Steve Langasek wrote:
+> On Tue, Jan 28, 2014 at 09:23:11AM -0800, Keith Packard wrote:
+> > Bdale Garbee <bdale@gag.com> writes:
+> 
+> > > Thus, I believe the only acceptable option for Q2 from among your set is
+> > > "requiring a specific init is permitted even if it is not the default
+> > > one".  But I would prefer to vote a ballot that doesn't mention
+> > > dependencies at all.
+> 
+> > I agree with this; I don't think we should try to force developers into
+> > significant work to satisfy an init system constraint as that may
+> > prevent or delay important fixes and improvements from entering the
+> > repository.
+> 
+> > Of course, nothing would prevent someone else from fixing these kinds of
+> > bugs and having those fixes get merged into the package, potentially
+> > invoking §6.1.4 to have the tech-ctte resolve any conflict as needed.
+> > However, I'd anticipate that most package developers would readily
+> > accept fixes that made their packages work for more people.
+> 
+> I'd like to believe this; however, the fact that bug #726763 is still open
+> leads me to fear otherwise.
+
+I don't see any counterexamples in 726763 to the statement that "nothing
+would prevent someone else from fixing these kinds of bugs and having
+those fixes get merged into the package", or to the statement that "most
+package developers would readily accept fixes that made their packages
+work for more people."  Fixing 726763 just needs a "Depends" from the
+GNOME packages to reflect their dependency on logind and the suspend
+inhibit mechanism, which as stated in the bug log won't happen until the
+resolution of 727708.  Meanwhile, installing either systemd-sysv or
+systemd-shim (or having systemd installed and booting with
+init=/bin/systemd) fixes the issue reported in 726763.
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 20:36:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 20:36:10 GMT) (full text, mbox, link).

+ +

Message #5014 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sat, 1 Feb 2014 15:34:08 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Feb 01, 2014 at 07:28:49PM +0000, Ian Jackson wrote:
+> Steve Langasek writes ("Bug#727708: multiple init systems - formal resolution proposal"):
+
+> > Thus, for me, all of the "T" variants in Ian's latest draft
+> > (<21226.41292.366504.997315@chiark.greenend.org.uk>) rank below FD.
+
+> In my mail following the irc meeting I formally proposed the options
+> you see listed in that message: {U,D,O,V}{T,F} and GR and FD.
+
+> Are you satisfied that the wordings I propose there properly capture
+> the essence of the disagreement ?  (You haven't said this explicitly,
+> but I get the impression that you think they do.)
+
+I believe they capture the essence of the disagreement as it's been framed
+so far in this discussion.  However, I'm hoping that there is a compromise,
+involving being more explicit about the interoperability expected between
+packages so that they remain coinstallable on a Debian system and don't
+fragment the archive, that is agreeable to all members of the TC.
+
+As things stand, it seems that each set of dependency rider options will
+have some members of the TC voting them below FD.  Which means I don't think
+we've actually gotten to the bottom of this issue and identified the
+consensus position, and I think we should be doing so.
+
+Where would this ballot option rank vis-à-vis FD, for those TC members who
+are opposed to the "loose coupling" option?
+
+== dependencies rider version S (split-the-init) ==
+
+   This decision is limited to selecting a default initsystem; we
+   continue to welcome contributions of support for all init systems.
+
+   Software outside of an init system's implementation may not require a
+   specific init system to be pid 1, although degraded operation is
+   tolerable.  Software not part of an init system's implementation may
+   require interfaces unrelated to service management that are provided as
+   part of an init system, but the dependency on such interfaces must be
+   declared in a way that allows the dependency to be satisfied by
+   compatible implementations on other init systems.
+
+   Maintainers are encouraged to accept technically sound patches
+   to enable improved interoperation with various init systems.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 20:51:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 20:51:15 GMT) (full text, mbox, link).

+ +

Message #5019 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sat, 01 Feb 2014 12:49:24 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> Where would this ballot option rank vis-à-vis FD, for those TC members who
+> are opposed to the "loose coupling" option?
+
+> == dependencies rider version S (split-the-init) ==
+
+>    This decision is limited to selecting a default initsystem; we
+>    continue to welcome contributions of support for all init systems.
+
+>    Software outside of an init system's implementation may not require a
+>    specific init system to be pid 1, although degraded operation is
+>    tolerable.  Software not part of an init system's implementation may
+>    require interfaces unrelated to service management that are provided as
+>    part of an init system, but the dependency on such interfaces must be
+>    declared in a way that allows the dependency to be satisfied by
+>    compatible implementations on other init systems.
+
+>    Maintainers are encouraged to accept technically sound patches
+>    to enable improved interoperation with various init systems.
+
+This continues to lock all package maintainers into providing startup
+configuration for all init systems indefinitely, and therefore to me is
+basically equivalent to L.
+
+If you limited the "may not require a specific init system" part to only
+jessie, I would vote it above FD, unless there's some problem with it
+that's not immediately apparent to me.  (I would still find L with that
+modification problematic, although less so than then current L.)
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 21:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 21:15:04 GMT) (full text, mbox, link).

+ +

Message #5024 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sat, 1 Feb 2014 13:12:34 -0800
+
+
Russ Allbery wrote:
+> Steve Langasek <vorlon@debian.org> writes:
+> > And so I am greatly dismayed by the position Russ and Bdale have taken
+> > in this discussion with respect to packages being allowed to depend on a
+> > specific init system.  Both have expressed the opinion that Debian
+> > should remain open to alternative init implementations as long as there
+> > are developers willing to do the work; but when it comes to concrete
+> > examples of ways in which conflation between init system (that is,
+> > service registration and service management) interfaces and dbus service
+> > interfaces directly interfere with that goal, they have been unwilling
+> > to stand up for the relevant technical principle.
+> 
+> You can be dismayed all you want, but I completely disagree with you about
+> the shape of the relevant principle.
+> 
+> There is a huge difference between being open to alternative init
+> implementations and requiring that maintainers implement support for
+> alternative init systems, which is what the loose coupling option
+> requires.  The latter is, in my opinion, effectively an attempt to coerce
+> maintainers into doing work they don't want to do by holding their
+> packages hostage, which is something that I think we should only do for
+> things that are absolutely vital to the project.  And I don't believe this
+> is.
+> 
+> What I want to see is people working with the relevant maintainers,
+> understanding their concerns and issues, and find a way to provide
+> maintainable support, not just asking the Technical Committee to force
+> other people to change how they maintain their packages well in advance of
+> actual irresolvable impasses.  And when no one has done the work to port a
+> particular package to another init system, preventing that current reality
+> from being properly represented in dependencies just makes the
+> distribution more technically fragile without any real gain for our users.
+
+Well said.
+
+In particular, in the case of GNOME, I don't see any package in the
+archive yet for a fork of logind that depends on systemd-shim instead of
+systemd, so there's no alternative available for GNOME to depend on.
+There's little point to adding a virtual package with no providers yet,
+because until the cloud of uncertainty leading to 727708 gets resolved,
+a (direct or indirect) dependency on "systemd-sysv | empty-alternative"
+seems unlikely to fly, and seems likely to lead to more rants against
+the GNOME maintainers for depending on systemd.
+
+It should be completely trivial to introduce a virtual
+"org-freedesktop-login1" package (modulo any complexities introduced by
+interface versioning for new methods added to that interface).  However,
+it also seems pointless until there's a prospective provider of that
+interface.  Do you have a package ready to provide that interface such
+that GNOME can depend on it?  I've seen no signs that the GNOME
+maintainers would refuse to allow alternative providers of those
+interfaces once they exist, just refusals to do any work in that
+direction until those alternatives *do* exist, which seems entirely
+reasonable.
+
+(I'm specifically leaving out the possibility of splitting systemd's
+logind out of the systemd package and forcing it to allow alternatives
+to a systemd dependency.  As effectively demonstrated by the ongoing
+work to port logind >> 204 to cgmanager, there is a non-trivial amount
+of work required for forks of logind to keep up with the ongoing
+development of logind and systemd, and putting that work on the systemd
+package will lead to future packaging delays similar to the one
+currently blocking a transition past 204.  To echo Russ's comments, we
+should not hold the systemd packages hostage to force their maintainers
+to maintain compatibility with non-systemd.  Any such work will
+inherently be a fork; better to properly represent it as one and package
+it as one, to avoid hampering the unforked version.)
+
+> > This despite the fact that the burden on the GNOME maintainers to
+> > support alternate implementations of these dbus services is much lower
+> > than the burden of providing sysvinit startup compatibility in jessie
+> > for an upstream project that doesn't support it.
+> 
+> The reason why requiring sysvinit startup compatibility makes sense to me
+> is because everything in the archive *already* has sysvinit startup
+> capability, and therefore what we're asking for is for maintainers to
+> sustain the status quo through jessie as much as possible so that we can
+> manage an orderly upgrade.
+
+I actually have language written up that would phrase the sysvinit
+compatibility requirement for jessie as specifically a requirement to
+properly support upgrades from wheezy to jessie, which I think would
+make more sense.  In particular, that language defined exactly what degree
+of "degraded functionality" must be supported under sysvinit: enough to
+upgrade from wheezy to jessie, and from sysvinit to not-sysvinit, in
+either order, in any environment [including a graphical one].
+
+> I certainly hope that we're not going to have to maintain sysvinit scripts
+> indefinitely.
+
+Likewise.
+
+> > As Philipp Kern points out in
+> > <41b26b373019ab39ebff223603a085d1@hub.kern.lc>, this leaves us with the
+> > very real possibility that we will wind up with mutually incompatible
+> > sets of packages in the archive for jessie that are no longer
+> > coinstallable, not because the packages themselves have conflicting
+> > functionality, but because they've taken sides - intentionally or
+> > unintentionally - on the init system question.  If we don't think such
+> > fragmentation of the Debian archive is an acceptable outcome (and I for
+> > one don't see any reason it should be), then we should say as much in
+> > our resolution.  The committee has a duty to provide strong technical
+> > guidance to the project, not just to get involved after something has
+> > gone off the rails.
+
+[As an aside, I want to respond to this point: pretty much by
+definition, if the technical committee has to consider an issue at all,
+something has already gone off the rails.  The technical committee is
+not a steering committee; it's a mediation process for when normal
+collaboration has not succeeded.]
+
+> If you want to explicitly say that packages are required to support the
+> default init system, then you should propose language.  That's not what
+> the loose coupling option says.  The loose coupling option says that all
+> packages must support *all* init systems, with some possible degredation
+> of operation.  I believe that effectively locks us into supporting
+> sysvinit scripts forever, since no alternative universal common
+> denominator seems to be emerging.
+
+Furthermore, I'd argue that the "loose coupling" rider as currently
+proposed makes it more *difficult* for alternatives to systemd to
+effectively compete with systemd, precisely because of the requirement
+to support *all* init systems.
+
+Suppose upstart added compatibility for several of systemd's most
+popular daemon interfaces.  L, as written, would prohibit daemons from
+depending on "either systemd or a sufficiently new version of upstart",
+because that makes the daemon depend on specific providers of PID 1.
+Thus, as Russ pointed out, "loose coupling" effectively forces the
+lowest common denominator of not requiring anything sysvinit lacks.
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 21:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 21:24:04 GMT) (full text, mbox, link).

+ +

Message #5029 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Josh Triplett <josh@joshtriplett.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sat, 01 Feb 2014 13:21:19 -0800
+
+
Josh Triplett <josh@joshtriplett.org> writes:
+
+> It should be completely trivial to introduce a virtual
+> "org-freedesktop-login1" package (modulo any complexities introduced by
+> interface versioning for new methods added to that interface).  However,
+> it also seems pointless until there's a prospective provider of that
+> interface.  Do you have a package ready to provide that interface such
+> that GNOME can depend on it?  I've seen no signs that the GNOME
+> maintainers would refuse to allow alternative providers of those
+> interfaces once they exist, just refusals to do any work in that
+> direction until those alternatives *do* exist, which seems entirely
+> reasonable.
+
+Note that I don't think it makes sense for Steve to work on such a package
+right now for exactly the same reason that I don't think it makes sense to
+start adding virtual packages right now, or figuring out the dependency
+structure in GNOME for non-systemd logind right now.  Personally, I
+wouldn't want to work on any of those things until some of the currently
+extremely large probability space collapses.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 21:45:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 21:45:08 GMT) (full text, mbox, link).

+ +

Message #5034 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: debian-ctte@lists.debian.org, + pkg-gnome-maintainers@lists.alioth.debian.org, + 726763@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Processed: block 726763 with 727708
+
Date: Sat, 1 Feb 2014 13:42:23 -0800
+
+
On Sat, Feb 01, 2014 at 03:24:47PM -0500, Steve Langasek wrote:
+> On Sat, Feb 01, 2014 at 08:09:24PM +0000, Debian Bug Tracking System wrote:
+> > Processing commands for control@bugs.debian.org:
+> 
+> > > block 726763 with 727708
+> 
+> On whose behalf are you setting such a block?  You are not listed as a
+> maintainer of gnome-settings-daemon, and even those members of the TC who
+> have been arguing against codifying a requirement to support multiple init
+> systems in the TC resolution have said they want maintainers to work
+> together to provide reasonable support for init systems other than the
+> default.
+> 
+> The above 'block' would be tantamount to an assertion that you have no
+> intention of accepting patches from maintainers of non-default init systems
+> to provide compatibility unless forced to do so by the TC; but as you're not
+> a maintainer of the package, that doesn't seem relevant here.
+
+I'm going to attempt to ignore the confrontational tone of your mail, on
+the assumption that you can't possibly be proposing that nobody other
+than a package maintainer should ever do bug triage for fear of stepping
+on the maintainer's toes.  I've done such triage on numerous bugs in the
+past, including adjustment of blocks, severity (including RC
+severities), and so on, always on the assumption that the maintainer
+will agree with the change; that assumption generally holds true.  Bug
+metadata is trivially changed or reverted, and we already have informal
+policies regarding such metadata, notably the general presumption that
+the maintainer can always change it if they disagree, and that they have
+the final say.  Thus, implicit in the block added above is the
+assumption that the maintainer can trivially change it if they disagree;
+if they did so, I certainly would not change it back and play BTS
+tennis.
+
+The block added above simply reflects the many comments from GNOME folks
+(and systemd folks for that matter) saying that they're waiting for the
+fallout to clear before making any drastic changes.  Furthermore, it
+reflects the reality of the current situation: you explicitly stated in
+the bug log of 726763 that systemd-shim was not ready to serve as an
+alternative to GNOME (though with different assumptions about how to
+resolve that), and you furthermore objected to the suggestion of
+resolving the situation by adding a recommends on systemd-sysv.  Thus, I
+don't see any obvious action the gnome-settings-daemon maintainer could
+take at this point to resolve 726763 without drawing ire.
+
+I would furthermore object strongly to your claim that the block is "an
+assertion that you [sic] have no intention of accepting patches from
+maintainers of non-default init systems to provide compatibility unless
+forced to do so by the TC".  Metadata is a dynamic thing reflecting the
+current reality as it stands, and there are no such patches currently on
+offer.  Patches that the maintainers find acceptable would certainly be
+cause to remove the block (and add the patch tag).
+
+See also Russ's very clear response, which I agree with wholeheartedly;
+thank you, Russ.
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 21:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 21:51:04 GMT) (full text, mbox, link).

+ +

Message #5039 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sat, 1 Feb 2014 13:49:43 -0800
+
+
On Sat, Feb 01, 2014 at 01:21:19PM -0800, Russ Allbery wrote:
+> Josh Triplett <josh@joshtriplett.org> writes:
+> 
+> > It should be completely trivial to introduce a virtual
+> > "org-freedesktop-login1" package (modulo any complexities introduced by
+> > interface versioning for new methods added to that interface).  However,
+> > it also seems pointless until there's a prospective provider of that
+> > interface.  Do you have a package ready to provide that interface such
+> > that GNOME can depend on it?  I've seen no signs that the GNOME
+> > maintainers would refuse to allow alternative providers of those
+> > interfaces once they exist, just refusals to do any work in that
+> > direction until those alternatives *do* exist, which seems entirely
+> > reasonable.
+> 
+> Note that I don't think it makes sense for Steve to work on such a package
+> right now for exactly the same reason that I don't think it makes sense to
+> start adding virtual packages right now, or figuring out the dependency
+> structure in GNOME for non-systemd logind right now.  Personally, I
+> wouldn't want to work on any of those things until some of the currently
+> extremely large probability space collapses.
+
+I agree entirely; I was simply indicating (in other parts of my previous
+mail) that in the absence of a package ready to provide
+org-freedesktop-login1, a dependency (indirect or direct) on systemd's
+logind or org-freedesktop-login1 would reduce to a dependency on systemd
+as PID 1.
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 22:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 22:09:04 GMT) (full text, mbox, link).

+ +

Message #5044 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Uoti Urpala <uoti.urpala@pp1.inet.fi>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Sun, 2 Feb 2014 08:06:33 +1000
+
+
On 2 February 2014 04:05, Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
+> On Sat, 2014-02-01 at 17:10 +0000, Ian Jackson wrote:
+>> Sébastien Villemot writes ("Bug#727708: TC resolution revised draft"):
+>> > P1: DT > UT > DL > UL
+
+> So his example was one where the D/U and L/T choices were independent
+> for every voter,
+
+Formally, there isn't a way to vote for an arbitrary partial order by
+ranking options. ie, you can't vote for:
+
+  DT > UT
+  DL > UL
+  UT > UL
+  DT > DL
+
+without inadvertently and insincerely expressing further preferences.
+
+Err, yes you can:
+
+  DT > UT = DL > UL
+
+works fine. In which case the votes would be:
+
+  P1: DT > UT = DL > UL
+  P2: DL > UL = DT > UT
+  P3: UT > DT = UL > DL
+  P4: UT > DT = UL > DL
+
+and the pairwise defeats are:
+
+  DT > DL : 3 vs 1
+  UT > UL : 3 vs 1
+  DT > UL : 1 vs 0
+  UT > DL : 2 vs 1
+
+  UT = DT : 2 vs 2
+  UL = DL : 2 vs 2
+
+Transitive defeats are then just:
+
+  DT t. defeats DL, UL
+  UT t. defeats DL, UL
+
+Schwartz set: { DT, UT }
+
+There aren't any defeats in the schwartz set, so P1 uses a casting
+vote to choose which of DT, UT is the winner, presumably DT.
+
+Compare that to the corrected example's potential results:
+
+  combined: UT wins
+  D/U first: draw, tie break = D, T wins, so DT
+  L/T first: T wins, draw, tie break = D, so DT
+
+So I think you can put the difference down to either people expressing
+insincere preferences, or that the additional, sincerely held,
+preferences expressable via the combined vote having an effect on the
+outcome, which shouldn't be surprising.
+
+Cheers,
+aj
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 22:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 22:27:04 GMT) (full text, mbox, link).

+ +

Message #5049 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Josh Triplett <josh@joshtriplett.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sat, 1 Feb 2014 17:23:11 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Feb 01, 2014 at 01:12:34PM -0800, Josh Triplett wrote:
+> In particular, in the case of GNOME, I don't see any package in the
+> archive yet for a fork of logind that depends on systemd-shim instead of
+> systemd, so there's no alternative available for GNOME to depend on.
+
+There is no fork of logind *required* today.
+
+This bug would be fixed, today, by a dependency on 'systemd-shim |
+systemd-sysv', which is what I asked for in the bug.
+
+> There's little point to adding a virtual package with no providers yet,
+> because until the cloud of uncertainty leading to 727708 gets resolved,
+> a (direct or indirect) dependency on "systemd-sysv | empty-alternative"
+> seems unlikely to fly, and seems likely to lead to more rants against
+> the GNOME maintainers for depending on systemd.
+
+Of course, because that would be forcing a non-default init system (forcing
+installation of systemd-sysv before the decision has been taken on the
+default init system).  As things stand today, a dependency on systemd-shim |
+systemd-sysv would fix the bug for our users without forcing a change of
+init system on upgrade.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 23:27:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 23:27:11 GMT) (full text, mbox, link).

+ +

Message #5054 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Josh Triplett <josh@joshtriplett.org>
+
Cc: debian-ctte@lists.debian.org, + pkg-gnome-maintainers@lists.alioth.debian.org, + 726763@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Processed: block 726763 with 727708
+
Date: Sat, 1 Feb 2014 15:24:54 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Feb 01, 2014 at 01:42:23PM -0800, Josh Triplett wrote:
+> The block added above simply reflects the many comments from GNOME folks
+> (and systemd folks for that matter) saying that they're waiting for the
+> fallout to clear before making any drastic changes.  Furthermore, it
+> reflects the reality of the current situation: you explicitly stated in
+> the bug log of 726763 that systemd-shim was not ready to serve as an
+> alternative to GNOME (though with different assumptions about how to
+> resolve that), and you furthermore objected to the suggestion of
+> resolving the situation by adding a recommends on systemd-sysv.  Thus, I
+> don't see any obvious action the gnome-settings-daemon maintainer could
+> take at this point to resolve 726763 without drawing ire.
+
+Ok, it seems that wherever I sent my previous note about how I thought this
+should be fixed, it didn't actually manage to go to the bug log.  Sorry
+about that.
+
+While I think the Depends: systemd should be dropped (via a split of the
+systemd package), that's not required for fixing the present problem.  That
+can be addressed by having gnome-settings-daemon Depends: systemd,
+systemd-shim | systemd-sysv.
+
+Would the GNOME maintainers be willing to upload such a change?  Or would
+they be ok with me NMUing gnome-settings-daemon for it?
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 01 Feb 2014 23:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 01 Feb 2014 23:51:05 GMT) (full text, mbox, link).

+ +

Message #5059 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Processed: block 726763 with 727708
+
Date: Sun, 02 Feb 2014 01:48:28 +0200
+
+
On Sat, 2014-02-01 at 15:24 -0800, Steve Langasek wrote:
+> While I think the Depends: systemd should be dropped (via a split of the
+> systemd package), that's not required for fixing the present problem.  That
+> can be addressed by having gnome-settings-daemon Depends: systemd,
+> systemd-shim | systemd-sysv.
+> 
+> Would the GNOME maintainers be willing to upload such a change?  Or would
+> they be ok with me NMUing gnome-settings-daemon for it?
+
+I have the impression that systemd-shim diverts systemd files and you
+don't want to have it installed if you're actually booting with systemd.
+If this is accurate (I didn't check), then such a dependency change
+would not be appropriate - the recommended way to install systemd is
+still to NOT use systemd-sysv, while the above dependency would either
+force installation of systemd-sysv or would incorrectly install
+systemd-shim on systemd-booting systems.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 00:06:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 00:06:08 GMT) (full text, mbox, link).

+ +

Message #5064 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: debian-ctte@lists.debian.org, + pkg-gnome-maintainers@lists.alioth.debian.org, + 726763@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Processed: block 726763 with 727708
+
Date: Sat, 1 Feb 2014 16:03:00 -0800
+
+
On Sat, Feb 01, 2014 at 03:24:54PM -0800, Steve Langasek wrote:
+> On Sat, Feb 01, 2014 at 01:42:23PM -0800, Josh Triplett wrote:
+> > The block added above simply reflects the many comments from GNOME folks
+> > (and systemd folks for that matter) saying that they're waiting for the
+> > fallout to clear before making any drastic changes.  Furthermore, it
+> > reflects the reality of the current situation: you explicitly stated in
+> > the bug log of 726763 that systemd-shim was not ready to serve as an
+> > alternative to GNOME (though with different assumptions about how to
+> > resolve that), and you furthermore objected to the suggestion of
+> > resolving the situation by adding a recommends on systemd-sysv.  Thus, I
+> > don't see any obvious action the gnome-settings-daemon maintainer could
+> > take at this point to resolve 726763 without drawing ire.
+> 
+> Ok, it seems that wherever I sent my previous note about how I thought this
+> should be fixed, it didn't actually manage to go to the bug log.  Sorry
+> about that.
+
+Thanks for that clarification.  That would explain why I hadn't seen
+that mail when I reviewed the full bug log.
+
+> While I think the Depends: systemd should be dropped (via a split of the
+> systemd package), that's not required for fixing the present problem.  That
+> can be addressed by having gnome-settings-daemon Depends: systemd,
+> systemd-shim | systemd-sysv.
+
+While that would DTRT for users with systemd-sysv installed, it will not
+work for a majority of current systemd users in Debian, who use systemd
+via just the "systemd" package and having init=/bin/systemd on the
+kernel command line.  For such users, this change would attempt to
+install systemd-shim, which should not happen on systems running
+systemd.
+
+Do you have a suggestion for how to solve that, given the constraints
+of:
+
+- not having systemd-shim conflict with systemd (since you've stated
+  that you'd like to avoid that),
+- not causing breakage in the systemd package, and
+- not requiring systemd users to install systemd-sysv?
+
+I can think of a few, but none that would be particularly simple to
+implement or apply.
+
+Adding "systemd-shim" as an alternative to the current dependency on
+systemd could partially work, with the caveat that users who have
+systemd installed but are not currently booted into it would experience
+breakage.
+
+As an aside, what is the list of interfaces systemd-shim provides?  I
+previously had the impression that systemd-shim just provided the
+systemd DBus interfaces that logind depended on, but did not provide
+org.freedesktop.login1 directly, counting on a forked logind to provide
+that on top of systemd-shim.  Are you saying systemd-shim provides
+logind's interface directly, and thus satisfies GNOME's full dependency
+needs already?
+
+I'd also point out that there's no reason, other than the common issue
+of init=/bin/systemd systems (which applies to both orderings) and the
+current cloud of uncertainty surrounding init systems in Debian, that
+that dependency couldn't also be written "systemd-sysv | systemd-shim".
+Bug 727708 blocks one of the two alternatives but not the other, and I
+see no reason not to consider both alternatives equally.
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 00:18:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 00:18:05 GMT) (full text, mbox, link).

+ +

Message #5069 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sat, 1 Feb 2014 16:15:19 -0800
+
+
On Sat, Feb 01, 2014 at 05:23:11PM -0500, Steve Langasek wrote:
+> On Sat, Feb 01, 2014 at 01:12:34PM -0800, Josh Triplett wrote:
+> > In particular, in the case of GNOME, I don't see any package in the
+> > archive yet for a fork of logind that depends on systemd-shim instead of
+> > systemd, so there's no alternative available for GNOME to depend on.
+> 
+> There is no fork of logind *required* today.
+
+Only because the same cloud of uncertainty is blocking an update of
+systemd past version 204, and even then only assuming you pull in logind
+from the systemd package and use it with systemd-shim, which leads to
+yet another lovely pile of controversy.
+
+> This bug would be fixed, today, by a dependency on 'systemd-shim |
+> systemd-sysv', which is what I asked for in the bug.
+
+Which would break systems that have the systemd package installed and in
+use via init=/bin/systemd.  (In the interests of keeping discussion in
+one place rather than two, let's keep the discussion of solutions to
+that particular bug in that bug, rather than here, please.)
+
+> > There's little point to adding a virtual package with no providers yet,
+> > because until the cloud of uncertainty leading to 727708 gets resolved,
+> > a (direct or indirect) dependency on "systemd-sysv | empty-alternative"
+> > seems unlikely to fly, and seems likely to lead to more rants against
+> > the GNOME maintainers for depending on systemd.
+> 
+> Of course, because that would be forcing a non-default init system (forcing
+> installation of systemd-sysv before the decision has been taken on the
+> default init system).  As things stand today, a dependency on systemd-shim |
+> systemd-sysv would fix the bug for our users without forcing a change of
+> init system on upgrade.
+
+Leaving the aforementioned breakage aside, there's also the issue that
+other parts of GNOME will need more than just what systemd-shim
+currently provides, and having inconsistent dependencies in the GNOME
+packages makes no sense.  Furthermore, having systemd-shim installed
+will make upgrades to a post-727708 future version of Debian with
+systemd installed that much more painful, since there's no
+straightforward way for package dependencies to switch from
+"systemd-shim" to "systemd|systemd-shim" correctly.
+
+Seems preferable to see the outcome of 727708 first, the result of which
+might well lead the GNOME packages to depend on "systemd-sysv |
+systemd-shim" instead, or perhaps on "systemd-sysv |
+org-freedesktop-login1" if that proves logistically easier.
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 00:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thilos Rich <thilos.rich@aol.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 00:21:04 GMT) (full text, mbox, link).

+ +

Message #5074 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thilos Rich <thilos.rich@aol.com>
+
To: 727708@bugs.debian.org
+
Subject: Init should be simple, secure, and get out of the way. It should not take + over the system. We should not be forced to use one that does.
+
Date: Sat, 1 Feb 2014 19:11:52 -0500 (EST)
+
+
[Message part 1 (text/plain, inline)]
+
Init should be simple, secure, and get out of the way. It should not take over the system. We should not be forced to use an init that does.
+
+This man said it best:
+wizardofbits.tumblr.com/post/45232318557/systemd-more-like-shit-stemd
+
+"
+Init has one other job, which is to keep the process tables clean. See, any process can create a copy of itself (called “forking” (don’t laugh) in Unix terminology); this is usually a precursor to loading some other program. Any process that runs to completion can deliver a status code to the process that created it; the creating (or parent) process is said to “wait” on the status code of the created (or child) process. But what happens if the parent process dies before the child does? What happens is that init is designated to be the adoptive parent of the “orphaned” process, and it waits for, and discards, any status code that may be returned by the orphan on exit. This is to prevent “zombie processes” – process table slots that are filled with status codes but have no running programs attached to them. They are undesirable because they take up process table space that could be used by actual, running programs.
+
+
+So it is important that init run well and not crash.
+
+
+Now, in Unix system design, it is a generally understood principle that a big task not be handled by a big program, but rather a collection of small programs, each tackling one specific, well-defined component of the larger task. You often hear the phrase “do one thing, and do it well” as a guiding principle for writing a Unix program. One major reason for this is that a small program has fewer places for bugs to hide than a big program does.
+"
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 00:30:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to James Rhodes <jrhodes@redpointsoftware.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 00:30:11 GMT) (full text, mbox, link).

+ +

Message #5079 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: James Rhodes <jrhodes@redpointsoftware.com.au>
+
To: Thilos Rich <thilos.rich@aol.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init should be simple, secure, and get out of the + way. It should not take over the system. We should not be forced to use one + that does.
+
Date: Sun, 2 Feb 2014 11:27:09 +1100
+
+
[Message part 1 (text/plain, inline)]
+
If we're going to do block quotes... I refer you to
+http://0pointer.de/blog/projects/the-biggest-myths.html, in which it is
+clearly stated:
+
+"
+Myth: systemd is monolithic.
+
+If you build systemd with all configuration options enabled you will build
+69 individual binaries. These binaries all serve different tasks, and are
+neatly separated for a number of reasons. For example, we designed systemd
+with security in mind, hence most daemons run at minimal privileges (using
+kernel capabilities, for example) and are responsible for very specific
+tasks only, to minimize their security surface and impact. Also, systemd
+parallelizes the boot more than any prior solution. This parallization
+happens by running more processes in parallel. Thus it is essential that
+systemd is nicely split up into many binaries and thus processes. In fact,
+many of these binaries[1] are separated out so nicely, that they are very
+useful outside of systemd, too.
+
+A package involving 69 individual binaries can hardly be called monolithic.
+What is different from prior solutions however, is that we ship more
+components in a single tarball, and maintain them upstream in a single
+repository with a unified release cycle.
+"
+
+systemd is already "a collection of small programs, each tackling one
+specific, well-defined component of the larger task", so I don't see what
+the issue is.
+
+Please take some time to actually research the facts instead of reiterating
+FUD that's already been debunked.  This bug is long enough.
+
+Regards, James Rhodes.
+Redpoint Software
+
+http://about.me/james.rhodes
+
+
+
+On 2 February 2014 11:11, Thilos Rich <thilos.rich@aol.com> wrote:
+
+> Init should be simple, secure, and get out of the way. It should not take
+> over the system. We should not be forced to use an init that does.
+>
+> This man said it best:
+> wizardofbits.tumblr.com/post/45232318557/systemd-more-like-shit-stemd
+>
+> "
+> Init has one other job, which is to keep the process tables clean. See,
+> any process can create a copy of itself (called "forking" (don't laugh) in
+> Unix terminology); this is usually a precursor to loading some other
+> program. Any process that runs to completion can deliver a status code to
+> the process that created it; the creating (or parent) process is said to
+> "wait" on the status code of the created (or child) process. But what
+> happens if the parent process dies before the child does? What happens is
+> that init is designated to be the adoptive parent of the "orphaned"
+> process, and it waits for, and discards, any status code that may be
+> returned by the orphan on exit. This is to prevent "zombie processes" -
+> process table slots that are filled with status codes but have no running
+> programs attached to them. They are undesirable because they take up
+> process table space that could be used by actual, running programs.
+>
+>  So it is important that init run well and not crash.
+>
+>  Now, in Unix system design, it is a generally understood principle that
+> a big task not be handled by a big program, but rather a collection of
+> small programs, each tackling one specific, well-defined component of the
+> larger task. You often hear the phrase "do one thing, and do it well" as a
+> guiding principle for writing a Unix program. One major reason for this is
+> that a small program has fewer places for bugs to hide than a big program
+> does.
+> "
+>
+
+
[Message part 2 (text/html, inline)]
+ +

+ + +Information stored +:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 00:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and filed, but not forwarded. + (Sun, 02 Feb 2014 00:39:04 GMT) (full text, mbox, link).

+ +

Message #5084 received at 727708-quiet@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: Thilos Rich <thilos.rich@aol.com>, 727708-quiet@bugs.debian.org
+
Subject: Re: Bug#727708: Init should be simple, secure, and get out of the + way. It should not take over the system. We should not be forced to use one + that does.
+
Date: Sun, 2 Feb 2014 00:35:21 +0000 (UTC)
+
+
Thilos Rich dixit:
+
+>Init should be simple, secure, and get out of the way. It should not
+>take over the system. We should not be forced to use an init that
+>does.
+>
+>This man said it best:
+>wizardofbits.tumblr.com/post/45232318557/systemd-more-like-shit-stemd
+
+Full ACK! Thanks for this amusing and rather truthful post!
+
+bye,
+//mirabilos
+-- 
+(gnutls can also be used, but if you are compiling lynx for your own use,
+there is no reason to consider using that package)
+	-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 00:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 00:57:04 GMT) (full text, mbox, link).

+ +

Message #5089 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: 727708@bugs.debian.org, pkg-gnome-maintainers@lists.alioth.debian.org
+
Subject: Re: Processed: block 726763 with 727708
+
Date: Sat, 1 Feb 2014 16:53:53 -0800
+
+
[I'm going to avoid responding to the points of this mail that Russ
+already did in his response, in favor of just agreeing entirely with
+that mail.]
+
+Steve Langasek wrote:
+> On Sat, Feb 01, 2014 at 12:34:19PM -0800, Russ Allbery wrote:
+> > Wouldn't it be more reasonable to assume that the proper solution may
+> > depend on the TC decision and the corresponding fallout to package naming
+> > and structure, and hence it's reasonable to wait for the decision and
+> > subsequent fallout (particularly since that's close) rather than doing
+> > work now that may not apply to the final state of the world?
+> 
+> I don't think it's reasonable to leave testing and unstable users of our
+> default desktop environment without working suspend and resume for more than
+> a month (systemd-shim was accepted into unstable on Dec 28, and this was
+> mentioned on the bug) when a one-line change would fix the problem.
+
+As you already noted, your proposed solution had not been posted to the
+bug, and your statement that systemd-shim was not ready had been; thus,
+it doesn't seem particularly unreasonable for the maintainers to assume
+it wasn't yet a viable alternative.  Furthermore, even the "one-line
+change" you're proposing needs some further discussion to evaluate it,
+and it has not yet had that discussion.  Based on both of those points,
+I don't think it's at all reasonable to use 726763 as evidence that
+maintainers are not interested in supporting alternate init systems.  I
+still think it quite likely that the majority of maintainers will take
+reasonable steps to incorporate proposed patches to support alternate
+init systems.
+
+> And that fix would not cease to be correct if the TC decided that only
+> systemd should be supported for jessie, it would just cease to be
+> important.
+[...]
+> I don't see anything in the options the TC
+> is considering, or in the broader discussion generally, which would impact
+> the maintainers' course of action here.
+> 
+> In other words: I think the technically correct thing here is obvious and
+> simple and invariant with respect to any decision the TC is going to make;
+> so the only way it makes sense to me that resolving the bug depends on the
+> TC decision is if the maintainers don't intend to do the correct, obvious,
+> simple thing unless the TC /requires/ them to do so.
+
+I think it's entirely possible that your proposal is not the "correct,
+obvious, simple thing" you see it as; it's not even the "correct,
+obvious, simple thing" for everyone who has been neck-deep in the
+entirety of this discussion, let alone for those who haven't been.
+
+I can also see several reasonable ways in which the appropriate change
+to this or any other involved package might differ based on the outcome
+of the TC decision.  I don't think it's reasonable, given a very large
+solution space, to give preference to proposals based on their ability
+to keep their distance from 727708, rather than evalating all proposed
+solutions equally even if some might get embroiled in 727708.  For that
+reason as well as just to limit complexity, I also think it's perfectly
+reasonable for a maintainer to wait for an outcome to 727708 before even
+enumerating the solution space.
+
+A brief, decidedly non-exhaustive look at the (potentially overlapping)
+solution space many packages could end up facing:
+
+- Add a dependency on "systemd-as-pid-1 (however we end up representing
+  that) | systemd-shim (or similar substitute as applicable)".  That
+  would be appropriate if systemd becomes the default, or if the package
+  provides degraded functionality under the alternative system was
+  degraded.
+- Add a dependency in the reverse order, for the reverse of the above
+  two reasons.
+- Add a "Recommends: systemd-as-pid-1".  (Would work better if
+  alternatives to systemd conflicted with it, so that you end up with
+  systemd-as-pid-1 unless you have an alternative already installed or
+  you intentionally ignore the recommends.)
+- Request a co-maintainer to keep an alternative tested and working.
+- Go up a level in the dependency stack and add an alternative
+  dependency: "package-requiring-systemd |
+  forked-package-maintained-by-someone-else", or an equivalent involving
+  virtual packages, if a package requires invasive changes the
+  maintainer doesn't wish to merge.
+- In the case of a daemon package, split out a foo-bin and foo package,
+  allowing for a foo-otherinit package depending on foo-bin.  Often
+  convenient for other reasons, as well.
+- Change the maintainer to Debian QA Group (to further abuse Russ's
+  metaphor, "shoot the hostage").
+
+> And if we already have examples of this before we've even changed the
+> default init, then I don't think we should pass any resolution that
+> says we welcome multiple init systems while at the same time leaving
+> the door open for maintainers to reject even such simple changes as
+> this.
+
+Given that 726763 does not actually qualify as evidence for your
+conclusion here, do you have any actual evidence that maintainers will
+behave as you fear, rather than that maintainers are capable of ongoing
+cooperative development?
+
+I'd also suggest in general that anyone looking to produce a non-trivial
+patch for a package might want to talk to the maintainer of that package
+to see what form of patch they would accept, which would be a far more
+effective means of avoiding wasted development effort.
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 01:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 01:15:04 GMT) (full text, mbox, link).

+ +

Message #5094 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Cc: Adrian Bunk <bunk@stusta.de>, Russ Allbery <rra@debian.org>, + Josselin Mouette <joss@debian.org>, + Olav Vitters <ovitters@gmail.com>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sun, 2 Feb 2014 02:13:19 +0100
+
+
On Sat, Feb 01, 2014 at 11:25:01AM -0500, Steve Langasek wrote:
+> Josselin has asserted not only that he considers systemd-as-init a hard
+> dependency for GNOME in jessie, but that he expects the release team to side
+> with him over the Technical Committee if the TC does not agree with him.
+> This is unconscionable, given that there are two very straightforward and
+> obvious technical solutions to this problem:
+> 
+>  - split the systemd package (as previously discussed) into separate
+>    binaries, for the init system vs. the dbus interfaces, and have GNOME
+>    depend on the latter
+I the light of what I know about this issue from the systemd side,
+splitting the package into multiple independent components is much
+harder than it looks. For one, logind used to call into PID1 for
+shutdown/suspend/... but not it'll also attempt to start the user
+manager and tell PID1 to manage resource limits. I don't suppose
+systemd-shim is ready for that. Second, logind uses journald for
+logging. This actually is also an issue for gnome: gdm now logs to the
+journal, which makes debugging gdm initialization issues so much
+easier. Recently patches which redirect X logs to the journal have
+been accepted (even if not merged yet afaik) [1]. The hypothethical
+systemd-logind package would not only use a different provider of the
+most crucial services, but would also lose existing logging
+mechanism. Apart from that, loginctl communicates with PID1 to show
+cgroup information... Put in a lot of work to build a more brittle
+system and lose functionality? Even if it might have been easier for
+old systemd versions, the components are now fairly tightly coupled.
+Even if such a split could be done with enough man-hours thrown at it,
+I think it's obvious why Joss and other people who use systemd aren't
+thrilled about the prospect, especially with #727708 undecided.
+
+>  - have the systemd package declare one or more virtual packages via
+>    Provides:, which GNOME packages depend on and one or more alternative
+>    implementations may also provide.
+As argued elsewhere, since there are no alternative providers, this
+would amount to a hard dependency on systemd, which gnome is not allowed
+to do.
+
+Josselin's stance, even if strongly expressed, seems accurate.
+
+[1] https://bugzilla.gnome.org/show_bug.cgi?id=722889
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 02:24:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 02:24:05 GMT) (full text, mbox, link).

+ +

Message #5099 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Uoti Urpala <uoti.urpala@pp1.inet.fi>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Processed: block 726763 with 727708
+
Date: Sat, 1 Feb 2014 18:21:13 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Feb 1, 2014 at 3:48 PM, Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
+
+> On Sat, 2014-02-01 at 15:24 -0800, Steve Langasek wrote:
+> > While I think the Depends: systemd should be dropped (via a split of the
+> > systemd package), that's not required for fixing the present problem.
+>  That
+> > can be addressed by having gnome-settings-daemon Depends: systemd,
+> > systemd-shim | systemd-sysv.
+> >
+> > Would the GNOME maintainers be willing to upload such a change?  Or would
+> > they be ok with me NMUing gnome-settings-daemon for it?
+>
+> I have the impression that systemd-shim diverts systemd files and you
+> don't want to have it installed if you're actually booting with systemd.
+> If this is accurate (I didn't check), then such a dependency change
+> would not be appropriate - the recommended way to install systemd is
+> still to NOT use systemd-sysv, while the above dependency would either
+> force installation of systemd-sysv or would incorrectly install
+> systemd-shim on systemd-booting systems.
+>
+
+I think there is a huge problem with recommending that systemd be installed
+by the user changing the init line in grub: a package can not depend on an
+init system being PID 1. Can a package be made that changes the init line
+to systemd? I think that is preferable, because it folows the upstream
+convention of installing systemd by changing the init value, while also
+allowing packages to depend on systemd being PID 1.
+
+Nevertheless, there still needs to be a org-freedesktop-login1 virtual
+package. This will allow the systemd packagers to bump to systemd(-logind)
+v209 and let someone else maintain a systemd(-logind) v204 package in order
+to use logind without requiring systemd to be PID 1.
+
+I think that, with these two packages (one virtual), the systemd packagers
+will be happy and GNOME can actually function properly with no intervention.
+
+--
+Cameron Norman
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 02:39:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 02:39:05 GMT) (full text, mbox, link).

+ +

Message #5104 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Cameron Norman <camerontnorman@gmail.com>
+
Cc: 727708@bugs.debian.org, Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
Subject: Re: Bug#727708: Processed: block 726763 with 727708
+
Date: Sat, 01 Feb 2014 18:35:15 -0800
+
+
Cameron Norman <camerontnorman@gmail.com> writes:
+
+> I think there is a huge problem with recommending that systemd be
+> installed by the user changing the init line in grub: a package can not
+> depend on an init system being PID 1. Can a package be made that changes
+> the init line to systemd? I think that is preferable, because it folows
+> the upstream convention of installing systemd by changing the init
+> value, while also allowing packages to depend on systemd being PID 1.
+
+I'm not sure that it's ever going to be sane for simple installation of a
+package with no further admin interaction to change your init system.  If
+we're going to support multiple init systems going forward, I think we're
+going to need to figure out some approach to changing the init system that
+requires *something* besides a package installation.
+
+If packages aren't allowed to depend on the functionality of any specific
+init system, there are various straightforward approaches to this, of
+which systemd is one that seems reasonable to me.  If we do introduce
+package dependencies on specific functionality, we need to think about how
+to do this properly.  I *like* systemd, and I would still be very unhappy
+if a routine aptitude upgrade (or even a dist-upgrade) of a system
+currently running sysvinit suddenly resulted in running systemd without
+some sort of critical debconf question or the like.
+
+Maybe we can handle this by having a package that changes the default init
+system but have it throw a critical debconf prompt and fail to install if
+installed noninteractively.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 03:06:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 03:06:05 GMT) (full text, mbox, link).

+ +

Message #5109 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org, Cameron Norman <camerontnorman@gmail.com>
+
Cc: 727708@bugs.debian.org, Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
Subject: Re: Bug#727708: Processed: block 726763 with 727708
+
Date: Sat, 01 Feb 2014 20:02:53 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Russ Allbery <rra@debian.org> writes:
+
+> I *like* systemd, and I would still be very unhappy
+> if a routine aptitude upgrade (or even a dist-upgrade) of a system
+> currently running sysvinit suddenly resulted in running systemd without
+> some sort of critical debconf question or the like.
+
+Indeed.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 03:18:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 03:18:05 GMT) (full text, mbox, link).

+ +

Message #5114 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Processed: block 726763 with 727708
+
Date: Sat, 1 Feb 2014 19:14:21 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Feb 1, 2014 at 6:35 PM, Russ Allbery <rra@debian.org> wrote:
+>
+> I *like* systemd, and I would still be very unhappy
+> if a routine aptitude upgrade (or even a dist-upgrade) of a system
+> currently running sysvinit suddenly resulted in running systemd without
+> some sort of critical debconf question or the like.
+>
+
+In my mind, the package to change init systems would still be separate from
+its respective init systems. So gnome would depend on
+org-freedesktop-login1, and the default provider for that virtual package
+would be (a) a systemd-shim like package if the default debian init system
+is not systemd or (b) systemd and init-systemd (changes the init line) if
+systemd is the default. Obviously, if the user has systemd *and*
+init-systemd installed already, logind would be provided by that.
+
+
+> Maybe we can handle this by having a package that changes the default init
+> system but have it throw a critical debconf prompt and fail to install if
+> installed noninteractively.
+>
+
+I undeservedly thought this was a given.
+
+Thanks for the thoughts,
+--
+Cameron Norman
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 04:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Chris.Knadle@coredump.us:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 04:39:04 GMT) (full text, mbox, link).

+ +

Message #5119 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Chris Knadle <Chris.Knadle@coredump.us>
+
To: Cameron Norman <camerontnorman@gmail.com>, 727708@bugs.debian.org
+
Subject: package to change init systems [was: Bug#727708: Processed: block 726763 with 727708]
+
Date: Sat, 01 Feb 2014 23:36:29 -0500
+
+
On Saturday, February 01, 2014 19:14:21 Cameron Norman wrote:
+> On Sat, Feb 1, 2014 at 6:35 PM, Russ Allbery <rra@debian.org> wrote:
+> > I *like* systemd, and I would still be very unhappy
+> > if a routine aptitude upgrade (or even a dist-upgrade) of a system
+> > currently running sysvinit suddenly resulted in running systemd without
+> > some sort of critical debconf question or the like.
+> 
+> In my mind, the package to change init systems would still be separate from
+> its respective init systems.
+
+There's a work-in-progress tool starting to implement this, it currently works
+for switching between sysvinit and systemd, and will work with others later
+(assuming the package interdependencies can be worked out).
+
+
+$ apt-cache show init-select
+
+Package: init-select
+Version: 1.20140109
+Installed-Size: 50
+Maintainer: Michael Gilbert <mgilbert@debian.org>
+Architecture: all
+Depends: debconf (>= 0.5) | debconf-2.0, grub-coreboot | grub-efi-amd64 | grub-efi-i386 | grub-emu | grub-ieee1275 | grub-pc
+Suggests: systemd
+Description-en: init system selection tool
+ init-select makes it easy to select among the available init systems (the
+ first process initiated when the system starts).  To select an init other than
+ the default, please run the command 'dpkg-reconfigure init-select' after this
+ package has been installed.  Note that this will change the init used for all
+ of the available Linux kernel selections in the bootloader menu.
+ .
+ init-select currently only supports the grub bootloader, but this will be
+ expanded to lilo and other bootloaders in the future.
+
+
+
+This is working for me so far.  Doesn't yet work for upstart or openrc, but
+supporting them is in the TODO list.
+
+  -- Chris
+
+--
+Chris Knadle
+Chris.Knadle@coredump.us
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 04:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 04:57:04 GMT) (full text, mbox, link).

+ +

Message #5124 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sat, 1 Feb 2014 23:52:15 -0500
+
+
On Sat, Feb 1, 2014 at 11:25 AM, Steve Langasek wrote:
+> On Wed, Jan 29, 2014 at 10:13:25PM +0200, Adrian Bunk wrote:
+>> And that does matter a lot, since such claims seem to be the basis
+>> of all these "GNOME in jessie needs systemd" or "with multiple init
+>> systems, GNOME will need a dependency on systemd" (and Josselin even
+>> expects an exception from the release managers for that if the TC
+>> decision would not allow such a dependency [1]).
+>
+> Whether or not it's possible for GNOME in jessie to be made to work without
+> logind, I agree with the GNOME team that logind is a reasonable dependency
+> for GNOME to have on Linux.
+>
+> What is not reasonable is the chain of logic that leads from "GNOME should
+> use logind" to "GNOME will require systemd as the init system".
+
+The logic is simple.  That is now clearly the direction that gnome
+upstream is heading.  If the gnome maintainers don't want to diverge
+too much from upstream, why force them?
+
+> Yet when I challenge the assertion that "desktop N will require systemd,
+> therefore Debian must adopt systemd as PID 1", which has been repeated
+> endlessly in this discussion, I am chided for being insufficiently courteous
+> to people who do not have the facts on their side.
+
+I think it would be far more effective to redirect the debate toward
+figuring out how to support a gnome island that is systemd-only
+without forcibly changing the rest of Debian to accommodate their
+world (i.e. deciding a new default init), and to do so without
+criticizing those involved.  Criticism only fortifies your
+opposition's resolve, and that is why it is now so difficult to work
+toward out any compromise.
+
+Let's stick with sysvinit for jessie, and in the meantime let the
+project evolve technical solutions less tied to the gnome island.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 05:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 05:51:04 GMT) (full text, mbox, link).

+ +

Message #5129 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Chris.Knadle@coredump.us, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: package to change init systems [was: Bug#727708: + Processed: block 726763 with 727708]
+
Date: Sat, 1 Feb 2014 21:49:50 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Feb 1, 2014 at 8:36 PM, Chris Knadle <Chris.Knadle@coredump.us>wrote:
+
+> On Saturday, February 01, 2014 19:14:21 Cameron Norman wrote:
+> > On Sat, Feb 1, 2014 at 6:35 PM, Russ Allbery <rra@debian.org> wrote:
+> > > I *like* systemd, and I would still be very unhappy
+> > > if a routine aptitude upgrade (or even a dist-upgrade) of a system
+> > > currently running sysvinit suddenly resulted in running systemd without
+> > > some sort of critical debconf question or the like.
+> >
+> > In my mind, the package to change init systems would still be separate
+> from
+> > its respective init systems.
+>
+> There's a work-in-progress tool starting to implement this, it currently
+> works
+> for switching between sysvinit and systemd, and will work with others later
+> (assuming the package interdependencies can be worked out).
+>
+>
+This is not really what I was interested in. I want a package for each init
+system (init-systemd, init-upstart, etc.) that uses something like
+init-select (under the hood) to prompt the user to change the init system.
+This will allow packages to depend on a certain init being pid 1, which is
+essential seeing as the current TC members seem to be leaning towards
+allowing tight coupling.
+
+--
+Cameron Norman
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 06:48:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 06:48:05 GMT) (full text, mbox, link).

+ +

Message #5134 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Sat, 01 Feb 2014 22:44:27 -0800
+
+
Cameron Norman <camerontnorman@gmail.com> writes:
+
+> This is not really what I was interested in. I want a package for each
+> init system (init-systemd, init-upstart, etc.) that uses something like
+> init-select (under the hood) to prompt the user to change the init
+> system.  This will allow packages to depend on a certain init being pid
+> 1, which is essential seeing as the current TC members seem to be
+> leaning towards allowing tight coupling.
+
+More generally, this is going to be required as soon as we have a package
+in the archive that provides a daemon and doesn't have a sysvinit script,
+pretty much no matter how we get there.  Even if we decide on only having
+a single init system, we still have upgrades from older systems running
+sysvinit to think of.  We *might* be able to dodge out of it if we somehow
+force the init system switch during a stable release cycle, but even
+there, it would be a mess in testing during the transition, and I don't
+think it's a good idea to dodge out of it.
+
+Sooner or later, we have to have some way to express the fact that a
+particular package only has startup configuration for a specific list of
+init systems as a package dependency, unless we think either that (a)
+we're going to continue to require all packages with daemons to provide
+sysvinit scripts forever, or (b) it's acceptable to install a daemon
+package and have it not provide a mechanism to start the daemon.
+
+(b) is probably okay in a few cases, but it's something that Debian has
+generally tried to avoid, and I support our current approach that the user
+who installs a daemon is asking for that daemon to actually be installed,
+configured, and running, not just present on the system waiting for some
+additional configuration (unless that's somehow unavoidable).  I don't
+think our model of "support an init system" should be "when you use this
+init system, daemon packages will just randomly not work without any
+warning until you notice and write configurations for them."  If the
+package doesn't provide configuration for a particular init system, that
+should be clear from the dependency structure; if the local administrator
+wants to install the package anyway and provide their own configuration,
+we have well-established mechanisms to allow for that (such as equivs).
+
+I think L is a bad technical design, regardless of the relative merits of
+the possible init systems that we might switch to.  It's effectively
+equivalent to requiring sysvinit support for all packages indefinitely,
+and if we thought that was a reasonable design, we would be having a much
+different discussion.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 09:39:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 09:39:10 GMT) (full text, mbox, link).

+ +

Message #5139 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sun, 2 Feb 2014 09:34:45 +0000
+
+
Steve Langasek writes ("Re: Bug#727708: multiple init systems - formal resolution proposal"):
+> As things stand, it seems that each set of dependency rider options will
+> have some members of the TC voting them below FD.  Which means I don't think
+> we've actually gotten to the bottom of this issue and identified the
+> consensus position, and I think we should be doing so.
+
+I think that there probably isn't a consensus position.
+
+> Where would this ballot option rank vis-à-vis FD, for those TC members who
+> are opposed to the "loose coupling" option?
+
+Well, I'm not one of those so your question is not really aimed at me.
+But your S is for me basically a version of T, so I don't like it for
+that reason.  (To an extent, the first and second sentences of the 2nd
+para are contradictory, and I don't think that's helpful.)
+
+And the requirement you set out about dependencies is IMO too
+technologically specific, and ought to be covered by the 3rd
+paragraph about reasonable patches.
+
+AFAICT neither Russ or Bdale have directly answered your question.
+
+Given that and what I have said, do you want (a) to discuss this
+further (perhaps with another irc drafting meeting) (b) to vote on
+{T,L}{D,U,O,R} etc. (c) to propose your S or some variant on it as
+well (as S{D,U,O,R} I expect) (d) something else ?
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 10:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 10:03:04 GMT) (full text, mbox, link).

+ +

Message #5144 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Sun, 2 Feb 2014 12:00:51 +0200
+
+
On Sat, Feb 01, 2014 at 10:44:27PM -0800, Russ Allbery wrote:
+>...
+> I think L is a bad technical design, regardless of the relative merits of
+> the possible init systems that we might switch to.  It's effectively
+> equivalent to requiring sysvinit support for all packages indefinitely,
+> and if we thought that was a reasonable design, we would be having a much
+> different discussion.
+
+No, it does not require sysvinit support for all packages indefinitely.
+
+The current TC decision is *for jessie*.
+
+Since the current proposal sets the default only for jessie,
+it basically implies that a new TC decision and/or GR about
+init systems will have to be discussed and voted on for jessie+1.
+
+AFAIR so far noone has suggested dropping sysvinit support in jessie
+if jessie supports multiple init systems, but for jessie+1 that can be 
+discussed when the init system discussion for jessie+1 will take place.
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 11:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 11:09:04 GMT) (full text, mbox, link).

+ +

Message #5149 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Processed: block 726763 with 727708
+
Date: Sun, 2 Feb 2014 11:06:25 +0000
+
+
On Sat, Feb 01, 2014 at 06:21:13PM -0800, Cameron Norman wrote:
+> I think there is a huge problem with recommending that systemd be installed
+> by the user changing the init line in grub: a package can not depend on an
+> init system being PID 1. Can a package be made that changes the init line
+> to systemd? I think that is preferable, because it folows the upstream
+> convention of installing systemd by changing the init value, while also
+> allowing packages to depend on systemd being PID 1.
+
+There are a few reasonable possibilities for that; see my comments in
+#736678.
+
+I don't particularly like the convention of passing init=, for much the
+same kind of reason as I'm in favour of the injunction in
+http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.9 that a
+program "must not depend on environment variables to get reasonable
+defaults"; the set of boot parameters is user-visible configuration, and
+I think that the preferred init on any given system, not to mention
+Debian's default, should be the default value.  I can understand the
+pragmatic reasons for systemd being hooked in using init= while it's a
+non-default system trying to gain acceptance and to be easy to
+experiment with on an ad-hoc basis, but as a GRUB maintainer I would
+prefer that GRUB not need to be involved in the establishment of a
+default.  Furthermore, not everyone uses GRUB and it's going to be
+pretty tedious to go round all the boot loaders.
+
+The de facto interface for making an init system the default is to
+install it as /sbin/init.  While I'm coming at this from a starting
+point different from Cameron's above - I haven't yet decided whether I
+think it would be good for packages to be able to depend on specific pid
+1 implementations - nevertheless, if we select systemd as the default I
+would argue that there should be some arrangement in packaging to put it
+in place as /sbin/init, even if that isn't upstream's advertised method.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 12:00:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 12:00:10 GMT) (full text, mbox, link).

+ +

Message #5154 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Processed: block 726763 with 727708
+
Date: Sun, 02 Feb 2014 12:57:39 +0100
+
+
]] Colin Watson 
+
+
+> The de facto interface for making an init system the default is to
+> install it as /sbin/init.  While I'm coming at this from a starting
+> point different from Cameron's above - I haven't yet decided whether I
+> think it would be good for packages to be able to depend on specific
+> pid 1 implementations - nevertheless, if we select systemd as the
+> default I would argue that there should be some arrangement in
+> packaging to put it in place as /sbin/init, even if that isn't
+> upstream's advertised method.
+
+You mean, like installing the systemd-sysv package?
+
+(Those packaging choices are done by us in Debian, not upstream.)
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 19:45:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 19:45:05 GMT) (full text, mbox, link).

+ +

Message #5159 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sun, 02 Feb 2014 11:42:11 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Steve Langasek writes:
+
+>> Where would this ballot option rank vis-à-vis FD, for those TC members
+>> who are opposed to the "loose coupling" option?
+
+[...]
+
+> AFAICT neither Russ or Bdale have directly answered your question.
+
+I thought I did, sorry.  I would rank those options below FD for any init
+system other than systemd.  I'm still unsure how to vote option L with
+systemd.  I'm not certain whether it would be better to adopt systemd with
+a bad package dependency model or adopt upstart with what I think is the
+correct package dependency model.  It's a rather annoying decision to have
+to make.
+
+upstart with a bad package dependency model just seems all-around awful
+and worse in some respects than the status quo.
+
+But regardless, I would vote S next to L in all cases; there's no
+functional difference for me.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 19:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 19:48:04 GMT) (full text, mbox, link).

+ +

Message #5164 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Sun, 02 Feb 2014 11:44:55 -0800
+
+
Adrian Bunk <bunk@stusta.de> writes:
+
+> No, it does not require sysvinit support for all packages indefinitely.
+
+> The current TC decision is *for jessie*.
+
+The D/U/O/V/GR options are for jessie.  T and L aren't.  Nothing in T or L
+are limited to jessie.  If that's what you think they should say, then you
+need to convince someone to change the current wording, but that's not
+what we're talking about voting on right now.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 21:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 21:09:04 GMT) (full text, mbox, link).

+ +

Message #5169 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Sun, 2 Feb 2014 23:05:42 +0200
+
+
On Sun, Feb 02, 2014 at 11:44:55AM -0800, Russ Allbery wrote:
+> Adrian Bunk <bunk@stusta.de> writes:
+> 
+> > No, it does not require sysvinit support for all packages indefinitely.
+> 
+> > The current TC decision is *for jessie*.
+> 
+> The D/U/O/V/GR options are for jessie.  T and L aren't.  Nothing in T or L
+> are limited to jessie.  If that's what you think they should say, then you
+> need to convince someone to change the current wording, but that's not
+> what we're talking about voting on right now.
+
+My reading of the current wording in [1] is that in
+
+<--  snip  -->
+
+   The default init system for Linux architectures in jessie should
+   be ... .
+
+   This decision is limited to selecting a default initsystem; we
+   continue to welcome contributions of support for all init systems.
+
+   Software outside of an init system's implementation may not require
+   a specific init system to be pid 1, although degraded operation is
+   tolerable.
+
+   Maintainers are encouraged to accept technically sound patches
+   to enable improved interoperation with various init systems.
+
+   This decision is automatically vacated by any contrary General
+   Resolution which passes by a simple majority.  In that case the
+   General Resolution takes effect and the whole of this TC resolution
+   is to be taken as withdrawn by the TC, just as if the TC had
+   explicitly withdrawn it by a subsequent TC resolution.
+
+<--  snip  -->
+
+there is an "in jessie" at the top, and it is stated nowhere that any 
+part of this resolution would be outside of the scope of the "in jessie".
+
+The M option Ian previously suggested [2] had an explicit
+"for the foreseeable future" that made the intention clear.
+
+If all TC members agree that the T/L riders are not intended to be 
+limited to jessie, can you make that clear by adding a statement
+like "For jessie and later releases, " to the front of the middle 
+sections (the ones starting with "Software") in the T/L riders?
+
+Thanks
+Adrian
+
+[1] https://lists.debian.org/debian-ctte/2014/01/msg00603.html
+[2] https://lists.debian.org/debian-ctte/2014/01/msg00486.html
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 21:27:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 21:27:05 GMT) (full text, mbox, link).

+ +

Message #5174 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Sun, 2 Feb 2014 16:23:36 -0500
+
+
On Sun, Feb 2, 2014 at 1:44 AM, Russ Allbery wrote:
+> Cameron Norman writes:
+>
+>> This is not really what I was interested in. I want a package for each
+>> init system (init-systemd, init-upstart, etc.) that uses something like
+>> init-select (under the hood) to prompt the user to change the init
+>> system.  This will allow packages to depend on a certain init being pid
+>> 1, which is essential seeing as the current TC members seem to be
+>> leaning towards allowing tight coupling.
+
+That can be done now with init-select.  For example, any package that
+requires systemd can currently set /etc/default/init to /bin/systemd,
+and tell the user that a reboot is required.  It will, however, need
+to manually to check that the user hasn't changed the init setting to
+something else every time it starts up.  That may be as simple as
+checking that /proc/1/cmdline is /bin/systemd.
+
+> More generally, this is going to be required as soon as we have a package
+> in the archive that provides a daemon and doesn't have a sysvinit script,
+> pretty much no matter how we get there.  Even if we decide on only having
+> a single init system, we still have upgrades from older systems running
+> sysvinit to think of.  We *might* be able to dodge out of it if we somehow
+> force the init system switch during a stable release cycle, but even
+> there, it would be a mess in testing during the transition, and I don't
+> think it's a good idea to dodge out of it.
+
+If there is no change in default, then we can let users switch inits
+as they see fit.  We can also watch popcon to see which really become
+popular.  Users willing to make a non-default init decision are
+presumably more capable of dealing with any complications themselves.
+
+> Sooner or later, we have to have some way to express the fact that a
+> particular package only has startup configuration for a specific list of
+> init systems as a package dependency, unless we think either that (a)
+> we're going to continue to require all packages with daemons to provide
+> sysvinit scripts forever, or (b) it's acceptable to install a daemon
+> package and have it not provide a mechanism to start the daemon.
+
+sysvinit support will not be required for packages that have specific
+init dependencies, since the presence of systemd as init can be
+checked by those tools that require it.  Plus sysvinit support isn't
+forever, since eventually it will be deprecated as more and more parts
+of the system drop support for it.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Feb 2014 23:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Feb 2014 23:51:04 GMT) (full text, mbox, link).

+ +

Message #5179 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Adrian Bunk <bunk@stusta.de>, + 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Sun, 2 Feb 2014 23:48:42 +0000
+
+
Adrian Bunk writes ("Bug#727708: package to change init systems"):
+>    This decision is limited to selecting a default initsystem; we
+>    continue to welcome contributions of support for all init systems.
+...
+> there is an "in jessie" at the top, and it is stated nowhere that any 
+> part of this resolution would be outside of the scope of the "in jessie".
+
+This is a good point.  I think we should fix it.  This is IMO a reason
+not to call the vote tomorrow evening (unless we get a consensus fix
+before then).
+
+> The M option Ian previously suggested [2] had an explicit
+> "for the foreseeable future" that made the intention clear.
+
+Yes.  I would still prefer to see something like that.  I don't
+remember exactly what the objections were and I'm very very tired now
+but perhaps something like
+
+  We expect that Debian will continue to support mkultiple init
+  systems for the foreseeable future.
+
+would be acceptable to everyone ?  I can't remember what the
+objections were to my previous wording.  Or some other phrasing.
+
+> If all TC members agree that the T/L riders are not intended to be 
+> limited to jessie, can you make that clear by adding a statement
+> like "For jessie and later releases, " to the front of the middle 
+> sections (the ones starting with "Software") in the T/L riders?
+
+I would be happy to clarify them like that.  I prefer the "multiple
+... foreseeable future" approach if we can get consensus on a
+particular form of words.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 01:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thilos Rich <thilos.rich@aol.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 01:51:04 GMT) (full text, mbox, link).

+ +

Message #5184 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thilos Rich <thilos.rich@aol.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sun, 2 Feb 2014 20:48:20 -0500 (EST)
+
+
[Message part 1 (text/plain, inline)]
+
>Plus sysvinit support isn't
+>forever, since eventually it will be deprecated as more and more parts
+>of the system drop support for it.
+
+Why? There is nothing wrong with sysv init for most of us.
+Why is there insistance (or seemingly triumphal predictions)
+that those of us who are happy with the status quo ante bellum
+(aka: *NIX) be left out in the cold.
+
+In Debian you can choose your file system during install.
+You can choose if you want a desktop or server style of install
+(different sets of packages).
+You can choose your language. And all these are supported
+yea after year after year, even hard things like language.
+
+Yet we cannot have the same for system five init, in perpetuity,
+like the rest? Sysv just has to "bit rot" away (it's made of wood?)
+It usually doesn't need to be touched for years on end, because
+it, like an SLR lens, just works, for decades, and if 
+allowed to simply continue to exist: a century, more.
+
+It is stable, it does its job, it is simple.
+Like a lens. Unless you go and destroy it, it will continue
+to bend light long past you or I are dead.
+
+I think that's the problem some people have with it:
+they want to make their mark on linux, they see the init 
+system as a old and thus frail target to execute and replace.
+For their own glory.
+
+Sysvinit is old, but it is not frail. It is as solid as
+any piece of software can possibly be, and it doesn't
+require mutilation for the benefit and glory of some
+new upstarts who were conceived 20 years into its reign.
+
+Thus it needs to be murdered apparently, and all of us
+who know it, appreciate it, have our knowlge based on it
+and other parts of traditional unix,
+well we can go into the grave with it apparently.
+
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 02:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to James Rhodes <jrhodes@redpointsoftware.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 02:03:04 GMT) (full text, mbox, link).

+ +

Message #5189 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: James Rhodes <jrhodes@redpointsoftware.com.au>
+
To: Thilos Rich <thilos.rich@aol.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Mon, 3 Feb 2014 12:59:29 +1100
+
+
[Message part 1 (text/plain, inline)]
+
The point that is being made is not "you can't run software with shell
+scripts if you want", it's "don't expect developers to write or maintain
+them for you".
+
+Regards, James Rhodes.
+
+
+
+On 3 February 2014 12:48, Thilos Rich <thilos.rich@aol.com> wrote:
+
+> >Plus sysvinit support isn't
+> >forever, since eventually it will be deprecated as more and more parts
+> >of the system drop support for it.
+>
+> Why? There is nothing wrong with sysv init for most of us.
+> Why is there insistance (or seemingly triumphal predictions)
+> that those of us who are happy with the status quo ante bellum
+> (aka: *NIX) be left out in the cold.
+>
+> In Debian you can choose your file system during install.
+> You can choose if you want a desktop or server style of install
+> (different sets of packages).
+> You can choose your language. And all these are supported
+> yea after year after year, even hard things like language.
+>
+> Yet we cannot have the same for system five init, in perpetuity,
+> like the rest? Sysv just has to "bit rot" away (it's made of wood?)
+> It usually doesn't need to be touched for years on end, because
+> it, like an SLR lens, just works, for decades, and if
+> allowed to simply continue to exist: a century, more.
+>
+> It is stable, it does its job, it is simple.
+> Like a lens. Unless you go and destroy it, it will continue
+> to bend light long past you or I are dead.
+>
+> I think that's the problem some people have with it:
+> they want to make their mark on linux, they see the init
+> system as a old and thus frail target to execute and replace.
+> For their own glory.
+>
+> Sysvinit is old, but it is not frail. It is as solid as
+> any piece of software can possibly be, and it doesn't
+> require mutilation for the benefit and glory of some
+> new upstarts who were conceived 20 years into its reign.
+>
+> Thus it needs to be murdered apparently, and all of us
+> who know it, appreciate it, have our knowlge based on it
+> and other parts of traditional unix,
+> well we can go into the grave with it apparently.
+>
+>
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 02:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thilos Rich <thilos.rich@aol.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 02:33:04 GMT) (full text, mbox, link).

+ +

Message #5194 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thilos Rich <thilos.rich@aol.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sun, 2 Feb 2014 21:30:36 -0500 (EST)
+
+
[Message part 1 (text/plain, inline)]
+
+ Don't be facetious. The point that is being made is:
+F U C K system v init. F U C K anyone who relies on it,
+uses it, likes it, we will not help you, we will not
+continue on with it, F U C K U N I X, F U C K old sys
+admins.
+
+You say it in many clever ways, but don't think we don't
+get the message.
+
+As was said before:
+
+SystemD feels like an invasion, because it and its priests
+are spearheading just that.
+
+I now know to 1/100th of a degree what the pagans of europe felt.
+
+
+
+Debian provides all manners of different languages and support for them
+Debian provides various different kernels to run,
+and different versions of different kernels aswell as
+build systems should you choose to run some other kernel.
+
+Debian should continue to provide the simple sysvinit
+(for most daemons) scripts
+that it always has. It is usually not hard to start up a 
+daemon. The standard debian init scripts are usually fine,
+just change which binary it runs etc.
+
+Not much support is needed: keep your hands off the init
+scripts and they'll keep working as they have for most
+daemons. So stop being facetious and telling us to 
+go and fk ourselves while claiming you arent.
+
+And respect your elders please too, they use, like,
+would like to continue to use system V init, and
+not be goaded into being corralled into your
+new cattle pen.
+
+
+
+
+ 
+
+ 
+
+-----Original Message-----
+From: James Rhodes <jrhodes@redpointsoftware.com.au>
+To: Thilos Rich <thilos.rich@aol.com>; 727708 <727708@bugs.debian.org>
+Sent: Mon, Feb 3, 2014 2:00 am
+Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
+
+
+The point that is being made is not "you can't run software with shell scripts if you want", it's "don't expect developers to write or maintain them for you".
+
+
+Regards, James Rhodes.
+
+
+
+
+
+
+
+
+On 3 February 2014 12:48, Thilos Rich <thilos.rich@aol.com> wrote:
+
+>Plus sysvinit support isn't
+>forever, since eventually it will be deprecated as more and more parts
+>of the system drop support for it.
+
+Why? There is nothing wrong with sysv init for most of us.
+Why is there insistance (or seemingly triumphal predictions)
+that those of us who are happy with the status quo ante bellum
+(aka: *NIX) be left out in the cold.
+
+In Debian you can choose your file system during install.
+You can choose if you want a desktop or server style of install
+(different sets of packages).
+You can choose your language. And all these are supported
+yea after year after year, even hard things like language.
+
+Yet we cannot have the same for system five init, in perpetuity,
+like the rest? Sysv just has to "bit rot" away (it's made of wood?)
+It usually doesn't need to be touched for years on end, because
+it, like an SLR lens, just works, for decades, and if 
+allowed to simply continue to exist: a century, more.
+
+It is stable, it does its job, it is simple.
+Like a lens. Unless you go and destroy it, it will continue
+to bend light long past you or I are dead.
+
+I think that's the problem some people have with it:
+they want to make their mark on linux, they see the init 
+system as a old and thus frail target to execute and replace.
+For their own glory.
+
+Sysvinit is old, but it is not frail. It is as solid as
+any piece of software can possibly be, and it doesn't
+require mutilation for the benefit and glory of some
+new upstarts who were conceived 20 years into its reign.
+
+Thus it needs to be murdered apparently, and all of us
+who know it, appreciate it, have our knowlge based on it
+and other parts of traditional unix,
+well we can go into the grave with it apparently.
+
+
+
+
+
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 02:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to James Rhodes <jrhodes@redpointsoftware.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 02:51:04 GMT) (full text, mbox, link).

+ +

Message #5199 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: James Rhodes <jrhodes@redpointsoftware.com.au>
+
To: Thilos Rich <thilos.rich@aol.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Mon, 3 Feb 2014 13:46:30 +1100
+
+
[Message part 1 (text/plain, inline)]
+
> we will not help you
+
+If you want to run a configuration that is not supported by a developer,
+then no, I would not expect them to help you.
+
+Free software does not entitle you to free help, nor does it entitle you to
+demand others do or don't do things a particular way.
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 02:51:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 02:51:07 GMT) (full text, mbox, link).

+ +

Message #5204 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Thilos Rich <thilos.rich@aol.com>, 727708@bugs.debian.org, + James Rhodes <jrhodes@redpointsoftware.com.au>
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sun, 2 Feb 2014 18:49:07 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sun, Feb 02, 2014 at 09:30:36PM -0500, Thilos Rich wrote:
+> 
+>  Don't be facetious. The point that is being made is:
+
+Thilos, James, this is not the appropriate place for you to have this
+conversation.  Please leave this bug for its intended purpose, which is the
+technical commitee's discussion of init system selection for Debian.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 03:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to William Giokas <1007380@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 03:39:04 GMT) (full text, mbox, link).

+ +

Message #5209 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: William Giokas <1007380@gmail.com>
+
To: Thilos Rich <thilos.rich@aol.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Sun, 2 Feb 2014 20:48:21 -0600
+
+
[Message part 1 (text/plain, inline)]
+
On Sun, Feb 02, 2014 at 09:30:36PM -0500, Thilos Rich wrote:
+> 
+>  Don't be facetious. The point that is being made is:
+> F U C K system v init. F U C K anyone who relies on it,
+> uses it, likes it, we will not help you, we will not
+> continue on with it, F U C K U N I X, F U C K old sys
+> admins.
+
+No, what they're saying, if anything, is "If you're not willing
+to learn, you really should be."
+
+> 
+> You say it in many clever ways, but don't think we don't
+> get the message.
+> 
+> As was said before:
+> 
+> SystemD feels like an invasion, because it and its priests
+> are spearheading just that.
+> 
+> I now know to 1/100th of a degree what the pagans of europe felt.
+> 
+> 
+> 
+> Debian provides all manners of different languages and support for them
+> Debian provides various different kernels to run,
+> and different versions of different kernels aswell as
+> build systems should you choose to run some other kernel.
+> 
+> Debian should continue to provide the simple sysvinit
+> (for most daemons) scripts
+> that it always has. It is usually not hard to start up a 
+> daemon. The standard debian init scripts are usually fine,
+> just change which binary it runs etc.
+> 
+> Not much support is needed: keep your hands off the init
+> scripts and they'll keep working as they have for most
+> daemons. So stop being facetious and telling us to 
+> go and fk ourselves while claiming you arent.
+
+Um, that's exactly what he's saying they're going to do. The maintainers
+are probably going to keep the SysV scripts in there, however most will
+probably not want to bother maintaining them, as systemd units (and I
+would suspect) upstart jobs are much easier to write and maintain. If
+you've got a serious problem with that, then you can always write or
+maintain your own. If the init script needs no changing, then you're all
+good, but eventually some are going to need changes, and that burden
+might very well fall on the users.
+
+> 
+> And respect your elders please too, they use, like,
+> would like to continue to use system V init, and
+> not be goaded into being corralled into your
+> new cattle pen.
+
+I've only been using Linux for 5 years, so what I say probably means
+nothing to you, however people that have been using Linux and Unix for
+decades are not all opposed to using systemd or Upstart. I really would
+do some research if I were you on why they're wanting to switch. It
+would probably shed a lot more light on your problems than what I can
+say in this email.
+
+-- 
+William Giokas | KaiSforza | http://kaictl.net/
+GnuPG Key: 0x73CD09CF
+Fingerprint: F73F 50EF BBE2 9846 8306  E6B8 6902 06D8 73CD 09CF
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 14:21:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 14:21:15 GMT) (full text, mbox, link).

+ +

Message #5214 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Vote sysvinit 4 jessie
+
Date: Mon, 3 Feb 2014 09:17:33 -0500
+
+
I'd like to make one last plea in support of sysvinit, since I see no
+compelling reason to rush to something else in time for jessie.
+
+Firstly, it is already much easier to use alternative init systems
+since the TC discussion really got going in December.  init-select
+makes it super easy to swap between sysvinit and systemd.  There is
+now less reason to change the default since the user can do so him or
+herself.
+
+Secondly, leaving sysvinit in place makes it possible to gauge the
+organic adoption of the newer init systems.  In the future, when it
+really makes sense to change the default, concrete facts like popcon
+numbers the number of packages providing support can be used to
+support the decision, rather than smells and feels.
+
+Thirdly, it lets the project evolve its own meritocratic solution.
+Soon enough there will be a strong desire for gnome to drop support
+for all other inits, and slowly over time fewer packages will support
+the non-winning init systems, which can eventually be fully deprecated
+slowly over time.
+
+It also gives the alternatives more time to "catch up".  openrc was
+easily discarded from the discussion since the packaging was not yet
+complete, but that isn't really fair from a technical viewpoint.
+upstart has some technical issues that might improve given more time
+and the possibility that it may still be under consideration.
+
+Finally, it is worth considering that there is very little chance for
+upstart to win this particular vote.  Given the 4:4 systemd:upstart
+split and existing statements from the 4 on the systemd side, there is
+very little chance that they will vote upstart high.  Hence those TC
+members that don't want to see its default should be trying to figure
+out how to get 1 of the 4 to vote something else above systemd.
+sysvinit is probably the only option that has any possibility of
+getting 5 or more votes over something else.  For that reason, the
+upstart supporters should really be campaigning sysvinit to the 4
+systemd supporters.  At least if sysvinit wins, that gives upstart
+another cycle to get in better shape, rather than being disqualified
+now.
+
+So, is sysvinit the status quo?  Yes and no.  Yes its the same init
+system we've seen for a long time.  No, because concurrently all of
+the other systems are becoming usable and more viable options that are
+easy enough to switch to.
+
+So, for all those reasons, please vote sysvinit for jessie.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 14:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 14:48:04 GMT) (full text, mbox, link).

+ +

Message #5219 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, Adrian Bunk <bunk@stusta.de>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Mon, 03 Feb 2014 07:45:19 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> Yes.  I would still prefer to see something like that.  I don't
+> remember exactly what the objections were and I'm very very tired now
+> but perhaps something like
+>
+>   We expect that Debian will continue to support mkultiple init
+>   systems for the foreseeable future.
+>
+> would be acceptable to everyone ?  I can't remember what the
+> objections were to my previous wording.  Or some other phrasing.
+
+I've been trying to avoid making decisions now about what happens beyond
+jessie, but I would not object to including that text since I think it's
+true for at least some values of "support".
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 14:51:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Marko Randjelovic <markoran@eunet.rs>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 14:51:10 GMT) (full text, mbox, link).

+ +

Message #5224 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Marko Randjelovic <markoran@eunet.rs>
+
To: 727708@bugs.debian.org
+
Cc: Thilos Rich <thilos.rich@aol.com>, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: Init should be simple, secure, and get out of the + way. It should not take over the system. We should not be forced to use one + that does.
+
Date: Mon, 3 Feb 2014 14:32:21 +0000
+
+
On Sat, 1 Feb 2014 19:11:52 -0500 (EST)
+Thilos Rich <thilos.rich@aol.com> wrote:
+
+> Init should be simple, secure, and get out of the way. It should not take over the system. We should not be forced to use an init that does.
+> 
+> This man said it best:
+> wizardofbits.tumblr.com/post/45232318557/systemd-more-like-shit-stemd
+> 
+> "
+> Init has one other job, which is to keep the process tables clean. See, any process can create a copy of itself (called “forking” (don’t laugh) in Unix terminology); this is usually a precursor to loading some other program. Any process that runs to completion can deliver a status code to the process that created it; the creating (or parent) process is said to “wait” on the status code of the created (or child) process. But what happens if the parent process dies before the child does? What happens is that init is designated to be the adoptive parent of the “orphaned” process, and it waits for, and discards, any status code that may be returned by the orphan on exit. This is to prevent “zombie processes” – process table slots that are filled with status codes but have no running programs attached to them. They are undesirable because they take up process table space that could be used by actual, running programs.
+> 
+> 
+> So it is important that init run well and not crash.
+> 
+> 
+> Now, in Unix system design, it is a generally understood principle that a big task not be handled by a big program, but rather a collection of small programs, each tackling one specific, well-defined component of the larger task. You often hear the phrase “do one thing, and do it well” as a guiding principle for writing a Unix program. One major reason for this is that a small program has fewer places for bugs to hide than a big program does.
+> "
+
+Real power is in communicability, not in monolithic software, not
+even in modular software. It's like 2^N. 2 is a small number, but if
+you have enough bits, you can represent enormous number of numbers:
+0,1,2,...,2^N-1.
+
+Another example, in theory of approximation, a function f is
+represented by function g. And if you tend to approximate f with g on
+interval (a,b), then you your function g will start to diverge very
+rapidly as soon x gets out of (a,b). 
+
+When one software wants to cover all cases, they can never achieve this
+goal. They can make it work perfectly for 99% of users, but then the
+remaining 1% will have big problems.
+
+Such an application not only do not provide infrastructure for
+satisfying remaining cases, it can even become useless, and the typical
+solution is replacing it with another software which is incomparably
+less powerful, but yet much more usable for a particular purpose.
+Moreover, they are bad psychologically, because the user is frustrated,
+he has all that power in his hands, but in spite of that he cannot
+achieve something he has in mind.
+
+--
+https://en.wikipedia.org/wiki/Machiavellianism
+http://markorandjelovic.hopto.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 15:00:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 15:00:09 GMT) (full text, mbox, link).

+ +

Message #5229 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Marko Randjelovic <markoran@eunet.rs>, + 727708@bugs.debian.org
+
Cc: debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: Init should be simple, secure, and get out of the way. It should not take over the system. We should not be forced to use one that does.
+
Date: Mon, 3 Feb 2014 14:58:54 +0000
+
+
Marko Randjelovic writes ("Bug#727708: Init should be simple, secure, and get out of the way. It should not take over the system. We should not be forced to use one that does."):
+> Real power is in communicability, [etc. etc.]
+
+Please stop.  This kind of argument has been made many times already.
+Repeating it is not going to change anyone's mind, and is distracting
+the TC from what we currently ought to be doing, which is finalising
+the text of our resolution options so that we can vote.
+
+Also, I don't know who introduced the CC to debian-devel but please
+don't do that.  Anyone who wants to follow this discussion can do so
+via the bug and the TC list.  Keep the noise off debian-devel.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 15:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 15:09:05 GMT) (full text, mbox, link).

+ +

Message #5234 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Bdale Garbee <bdale@gag.com>
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, + Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Mon, 3 Feb 2014 17:06:16 +0200
+
+
On Mon, Feb 03, 2014 at 07:45:19AM -0700, Bdale Garbee wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> 
+> > Yes.  I would still prefer to see something like that.  I don't
+> > remember exactly what the objections were and I'm very very tired now
+> > but perhaps something like
+> >
+> >   We expect that Debian will continue to support mkultiple init
+> >   systems for the foreseeable future.
+> >
+> > would be acceptable to everyone ?  I can't remember what the
+> > objections were to my previous wording.  Or some other phrasing.
+> 
+> I've been trying to avoid making decisions now about what happens beyond
+> jessie, but I would not object to including that text since I think it's
+> true for at least some values of "support".
+
+This discussion started since the
+
+   Software outside of an init system's implementation may not require
+   a specific init system to be pid 1, although degraded operation is
+   tolerable.
+
+in the L rider was interpreted by Russ as being valid forever, while
+I read the whole resolution text (including this part) as only being 
+valid for jessie.
+
+Does a TC vote for this strict rule in the L rider make it binding only 
+for jessie, or forever?
+This is the important question here.
+
+I am pretty sure the TC will anyway have to debate and decide on the 
+init system(s) for jessie+1 in 1-2 years.
+
+Note that if a GR would re-affirm the TC decision, then a new GR might
+be needed to change a T/L rider decision if it is not limted to jessie.
+
+> Bdale
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 15:15:20 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 15:15:20 GMT) (full text, mbox, link).

+ +

Message #5239 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Bdale Garbee <bdale@gag.com>, + 727708@bugs.debian.org
+
Cc: Adrian Bunk <bunk@stusta.de>, + Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Mon, 3 Feb 2014 15:13:06 +0000
+
+
Bdale Garbee writes ("Bug#727708: package to change init systems"):
+> I've been trying to avoid making decisions now about what happens beyond
+> jessie, but I would not object to including that text since I think it's
+> true for at least some values of "support".
+
+OK, good.
+
+After a bit of wordsmithing and rearrangement I now have this:
+
+  == clarification text for all versions except GR ==
+
+     This decision is limited to selecting a default initsystem for
+     jessie.  We expect that Debian will continue to support multiple
+     init systems for the foreseeable future; we continue to welcome
+     contributions of support for all init systems.
+
+The additions, compared to the previous version, are
+ * add "for jessie" to the first sentence
+ * add the new "expect continue to support" wording as discussed
+   above (and make it the start of a new sentence as that seems
+   to read better).
+
+As I say in the heading comment, this text would appear in both the
+T (tight coupling) and L (loose coupling) versions.
+
+Adrian, does that address your point ?  I think that phrasing makes it
+clear that the remaining text (whether T or L) applies past jessie,
+too.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 15:21:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Jonathan Dowland <jmtd@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 15:21:05 GMT) (full text, mbox, link).

+ +

Message #5244 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Jonathan Dowland <jmtd@debian.org>
+
To: Michael Gilbert <mgilbert@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Vote sysvinit 4 jessie
+
Date: Mon, 03 Feb 2014 14:31:47 +0000
+
+
On 03/02/2014 14:17, Michael Gilbert wrote:
+> Hence those TC members that don't want to see its default should be
+> trying to figure out how to get 1 of the 4 to vote something else
+> above systemd.
+
+Shouldn't the TC members focus on their own vote and leave the others
+to focus on theirs? Likewise, if one finds themselves in the minority,
+should they not accept that gracefully?
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 15:21:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 15:21:08 GMT) (full text, mbox, link).

+ +

Message #5249 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: Bdale Garbee <bdale@gag.com>, + 727708@bugs.debian.org, + Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Mon, 3 Feb 2014 15:17:08 +0000
+
+
Adrian Bunk writes ("Re: Bug#727708: package to change init systems"):
+> On Mon, Feb 03, 2014 at 07:45:19AM -0700, Bdale Garbee wrote:
+> > I've been trying to avoid making decisions now about what happens beyond
+> > jessie, but I would not object to including that text since I think it's
+> > true for at least some values of "support".
+> 
+> This discussion started since the
+> 
+>    Software outside of an init system's implementation may not require
+>    a specific init system to be pid 1, although degraded operation is
+>    tolerable.
+> 
+> in the L rider was interpreted by Russ as being valid forever, while
+> I read the whole resolution text (including this part) as only being 
+> valid for jessie.
+> 
+> Does a TC vote for this strict rule in the L rider make it binding only 
+> for jessie, or forever?
+> This is the important question here.
+
+My view is that the T/L rider should apply to jessie+1 and beyond, as
+well as to jessie.  The text I have just emailed would IMO do that.
+
+It would be IMO better to make a decision now and explicitly revisit
+it if it turns out to be wrong, than to make no decision on T/L for
+jessie+1 and definitely have to have the argument again then.
+
+> Note that if a GR would re-affirm the TC decision, then a new GR might
+> be needed to change a T/L rider decision if it is not limted to jessie.
+
+A GR can selectively uphold the TCs decision if it wants to.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 15:27:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 15:27:05 GMT) (full text, mbox, link).

+ +

Message #5254 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Cc: Bdale Garbee <bdale@gag.com>, + Adrian Bunk <bunk@stusta.de>, + Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Mon, 3 Feb 2014 15:24:26 +0000
+
+
Ian Jackson writes ("Bug#727708: package to change init systems"):
+> Adrian, does that address your point ?  I think that phrasing makes it
+> clear that the remaining text (whether T or L) applies past jessie,
+> too.
+
+To expand on what Adrian says in his next mails, the result is that
+you might have something like this (arbitrarily, I have picked VL to
+illustrate):
+
+   The default init system for Linux architectures in jessie should
+   be sysvinit (no change).
+
+   This decision is limited to selecting a default initsystem for
+   jessie.  We expect that Debian will continue to support multiple
+   init systems for the foreseeable future; we continue to welcome
+   contributions of support for all init systems.
+
+   Software outside of an init system's implementation may not require
+   a specific init system to be pid 1, although degraded operation is
+   tolerable.
+
+   Maintainers are encouraged to accept technically sound patches
+   to enable improved interoperation with various init systems.
+
+   This decision is automatically vacated by any contrary General
+   Resolution which passes by a simple majority.  In that case the
+   General Resolution takes effect and the whole of this TC resolution
+   is to be taken as withdrawn by the TC, just as if the TC had
+   explicitly withdrawn it by a subsequent TC resolution.
+
+I think this wording is unambiguous.  The first paragraph applies only
+to jessie, but the rest of the resolution applies afterwards as well.
+
+Bdale, if this is not acceptable to you then please say.
+
+Personally I think it is essential for the TC to give now an answer on
+T-vs-L for jessie+1 and beyond.  If the situation changes radically
+and relevantly between now and then, the TC can of course revisit and
+modify its own decision.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 15:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 15:33:05 GMT) (full text, mbox, link).

+ +

Message #5259 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Jonathan Dowland <jmtd@debian.org>, + 727708@bugs.debian.org
+
Cc: Michael Gilbert <mgilbert@debian.org>
+
Subject: Re: Bug#727708: Vote sysvinit 4 jessie
+
Date: Mon, 3 Feb 2014 15:28:44 +0000
+
+
Jonathan Dowland writes ("Bug#727708: Vote sysvinit 4 jessie"):
+> On 03/02/2014 14:17, Michael Gilbert wrote:
+> > Hence those TC members that don't want to see its default should be
+> > trying to figure out how to get 1 of the 4 to vote something else
+> > above systemd.
+> 
+> Shouldn't the TC members focus on their own vote and leave the others
+> to focus on theirs? Likewise, if one finds themselves in the minority,
+> should they not accept that gracefully?
+
+What we are actually doing right now is focusing on the details of
+drafting to make sure that:
+ - the parts of the resolution that are in every ballot option
+   are unambiguous (so they won't result in more arguments) and
+   properly reflect the TC consensus
+ - the parts of the resolution that are contentious are the clearest
+   possible but also the most reasonable approach
+ - we don't accidentally prejudge something we don't intend to;
+   or conversely accidentally fail to specify something which is
+   important.
+
+Frankly right now I'm not even reading messages which are trying to
+persuade us to change our minds about the key questions.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 15:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 15:57:04 GMT) (full text, mbox, link).

+ +

Message #5264 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Mon, 3 Feb 2014 15:54:23 +0000
+
+
Ian Jackson writes ("Re: Bug#727708: package to change init systems"):
+> Bdale, if this is not acceptable to you then please say.
+
+Bdale has said on irc that he's happy.  So I hereby withdraw my
+previous amendments and propose and accept and do not accept
+amendments so as to produce the following set of options.
+
+I will postpone my CFV until 16:00 UTC on Wednesday.
+Last call for comments/amendments.
+
+Thanks,
+Ian.
+
+Options on the ballot:
+
+  DT   systemd default in jessie, requiring specific init is allowed
+  DL   systemd default in jessie, requiring specific init NOT allowed
+
+  UT   upstart default in jessie, requiring specific init is allowed
+  UL   upstart default in jessie, requiring specific init NOT allowed
+
+  OT   openrc default in jessie, requiring specific init is allowed
+  OL   openrc default in jessie, requiring specific init NOT allowed
+
+  VT   sysvinit default in jessie, requiring specific init is allowed
+  VL   sysvinit default in jessie, requiring specific init NOT allowed
+
+  GR   project should decide via GR
+
+  FD   further discussion
+
+== version D (systemD) ==
+
+   The default init system for Linux architectures in jessie should
+   be systemd.
+
+== version U (Upstart) ==
+
+   The default init system for Linux architectures in jessie should
+   be upstart.
+
+== version O (Openrc) ==
+
+   The default init system for Linux architectures in jessie should
+   be openrc.
+
+== version V (sysVinit) ==
+
+   The default init system for Linux architectures in jessie should
+   be sysvinit (no change).
+
+== version GR (General Resolution) ==
+
+   The Technical Committee requests that the project decide the
+   default init system for jessie by means of General Resolution.
+
+== clarification text for all versions except GR ==
+
+   This decision is limited to selecting a default initsystem for
+   jessie.  We expect that Debian will continue to support multiple
+   init systems for the foreseeable future; we continue to welcome
+   contributions of support for all init systems.
+
+== dependencies rider version T (Tight coupling) ==
+
+   Software may require a specific init system to be pid 1.
+
+   However, where feasible, software should interoperate with
+   all init systems; maintainers are encouraged to accept
+   technically sound patches to enable interoperation, even if it
+   results in degraded operation while running under the init system
+   the patch enables interoperation with.
+
+== dependencies rider version L (Loose coupling) ==
+
+   Software outside of an init system's implementation may not require
+   a specific init system to be pid 1, although degraded operation is
+   tolerable.
+
+   Maintainers are encouraged to accept technically sound patches
+   to enable improved interoperation with various init systems.
+
+== rider for all versions except GR ==
+
+   This decision is automatically vacated by any contrary General
+   Resolution which passes by a simple majority.  In that case the
+   General Resolution takes effect and the whole of this TC resolution
+   is to be taken as withdrawn by the TC, just as if the TC had
+   explicitly withdrawn it by a subsequent TC resolution.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 16:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 16:00:04 GMT) (full text, mbox, link).

+ +

Message #5269 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: Bdale Garbee <bdale@gag.com>, 727708@bugs.debian.org, + Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Mon, 3 Feb 2014 17:57:48 +0200
+
+
On Mon, Feb 03, 2014 at 03:13:06PM +0000, Ian Jackson wrote:
+> Bdale Garbee writes ("Bug#727708: package to change init systems"):
+> > I've been trying to avoid making decisions now about what happens beyond
+> > jessie, but I would not object to including that text since I think it's
+> > true for at least some values of "support".
+> 
+> OK, good.
+> 
+> After a bit of wordsmithing and rearrangement I now have this:
+> 
+>   == clarification text for all versions except GR ==
+> 
+>      This decision is limited to selecting a default initsystem for
+>      jessie.  We expect that Debian will continue to support multiple
+>      init systems for the foreseeable future; we continue to welcome
+>      contributions of support for all init systems.
+> 
+> The additions, compared to the previous version, are
+>  * add "for jessie" to the first sentence
+>  * add the new "expect continue to support" wording as discussed
+>    above (and make it the start of a new sentence as that seems
+>    to read better).
+> 
+> As I say in the heading comment, this text would appear in both the
+> T (tight coupling) and L (loose coupling) versions.
+> 
+> Adrian, does that address your point ?  I think that phrasing makes it
+> clear that the remaining text (whether T or L) applies past jessie,
+> too.
+
+Unfortunately it makes it even worse, this is just adding some 
+(non-binding) expectations to a paragraph that now starts with
+  This decision is limited to selecting a default initsystem
+  for jessie
+
+I would still read the paragraphs starting with "Software" as 
+implicitely being covered by the (now twice) "in/for jessie"
+that is there previously.
+
+Please add some kind of either "For jessie and later releases, "
+or "For jessie, " to the "Software" paragraphs to make it clear.
+
+> Ian.
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 16:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 16:15:04 GMT) (full text, mbox, link).

+ +

Message #5274 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Adrian Bunk <bunk@stusta.de>, + 727708@bugs.debian.org
+
Cc: Bdale Garbee <bdale@gag.com>, + Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Mon, 3 Feb 2014 16:10:58 +0000
+
+
Adrian Bunk writes ("Bug#727708: package to change init systems"):
+> On Mon, Feb 03, 2014 at 03:13:06PM +0000, Ian Jackson wrote:
+> >   == clarification text for all versions except GR ==
+> > 
+> >      This decision is limited to selecting a default initsystem for
+> >      jessie.  We expect that Debian will continue to support multiple
+> >      init systems for the foreseeable future; we continue to welcome
+> >      contributions of support for all init systems.
+...
+> Please add some kind of either "For jessie and later releases, "
+> or "For jessie, " to the "Software" paragraphs to make it clear.
+
+I would be happy to do this.  Anyone object to me prefixing
+
+   Therefore, for jessie and later releases:
+
+before the T/L "Software ..." paragraphs ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 16:21:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 16:21:08 GMT) (full text, mbox, link).

+ +

Message #5279 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Cc: Adrian Bunk <bunk@stusta.de>, + Bdale Garbee <bdale@gag.com>, + Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Mon, 3 Feb 2014 16:20:06 +0000
+
+
Ian Jackson writes ("Bug#727708: package to change init systems"):
+> I would be happy to do this.  Anyone object to me prefixing
+>    Therefore, for jessie and later releases:
+> before the T/L "Software ..." paragraphs ?
+
+Following another exchange on IRC I have now done this in git, and I
+hereby propose and accept that amendment (to all versions).  The
+result is as below.
+
+I now intend to do the CFV at 16:30 UTC on Wednesday.
+
+Thanks,
+Ian.
+
+Options on the ballot:
+
+  DT   systemd default in jessie, requiring specific init is allowed
+  DL   systemd default in jessie, requiring specific init NOT allowed
+
+  UT   upstart default in jessie, requiring specific init is allowed
+  UL   upstart default in jessie, requiring specific init NOT allowed
+
+  OT   openrc default in jessie, requiring specific init is allowed
+  OL   openrc default in jessie, requiring specific init NOT allowed
+
+  VT   sysvinit default in jessie, requiring specific init is allowed
+  VL   sysvinit default in jessie, requiring specific init NOT allowed
+
+  GR   project should decide via GR
+
+  FD   further discussion
+
+== version D (systemD) ==
+
+   The default init system for Linux architectures in jessie should
+   be systemd.
+
+== version U (Upstart) ==
+
+   The default init system for Linux architectures in jessie should
+   be upstart.
+
+== version O (Openrc) ==
+
+   The default init system for Linux architectures in jessie should
+   be openrc.
+
+== version V (sysVinit) ==
+
+   The default init system for Linux architectures in jessie should
+   be sysvinit (no change).
+
+== version GR (General Resolution) ==
+
+   The Technical Committee requests that the project decide the
+   default init system for jessie by means of General Resolution.
+
+== clarification text for all versions except GR ==
+
+   This decision is limited to selecting a default initsystem for
+   jessie.  We expect that Debian will continue to support multiple
+   init systems for the foreseeable future; we continue to welcome
+   contributions of support for all init systems.
+
+   Therefore, for jessie and later releases:
+
+== dependencies rider version T (Tight coupling) ==
+
+   Software may require a specific init system to be pid 1.
+
+   However, where feasible, software should interoperate with
+   all init systems; maintainers are encouraged to accept
+   technically sound patches to enable interoperation, even if it
+   results in degraded operation while running under the init system
+   the patch enables interoperation with.
+
+== dependencies rider version L (Loose coupling) ==
+
+   Software outside of an init system's implementation may not require
+   a specific init system to be pid 1, although degraded operation is
+   tolerable.
+
+   Maintainers are encouraged to accept technically sound patches
+   to enable improved interoperation with various init systems.
+
+== rider for all versions except GR ==
+
+   This decision is automatically vacated by any contrary General
+   Resolution which passes by a simple majority.  In that case the
+   General Resolution takes effect and the whole of this TC resolution
+   is to be taken as withdrawn by the TC, just as if the TC had
+   explicitly withdrawn it by a subsequent TC resolution.
+
+-- 
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 16:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Olav Vitters <ovitters@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 16:27:05 GMT) (full text, mbox, link).

+ +

Message #5284 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Olav Vitters <ovitters@gmail.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Mon, 3 Feb 2014 17:23:42 +0100
+
+
On Mon, Feb 3, 2014 at 4:54 PM, Ian Jackson
+<ijackson@chiark.greenend.org.uk> wrote:
+>   UT   upstart default in jessie, requiring specific init is allowed
+
+So just to ensure I don't misunderstand:
+The way I read the texts, you could have e.g. Upstart as default init
+system and GNOME depend on systemd with UT? Meaning: software could
+depend on another init system than the default? Just wanting to make
+sure I am reading this correctly. I was sort of assuming that there
+would be a preference to rely on the default one. E.g. if you go for
+Upstart, then preferred to ensure that works.
+
+FWIW, I did read all the emails and likely this was explained, but
+kind of difficult to follow discussions on a phone.
+
+Regards,
+Olav
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 16:33:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 16:33:10 GMT) (full text, mbox, link).

+ +

Message #5289 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Olav Vitters <ovitters@gmail.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: package to change init systems
+
Date: Mon, 3 Feb 2014 16:30:36 +0000
+
+
Olav Vitters writes ("Re: Bug#727708: package to change init systems"):
+> On Mon, Feb 3, 2014 at 4:54 PM, Ian Jackson
+> <ijackson@chiark.greenend.org.uk> wrote:
+> >   UT   upstart default in jessie, requiring specific init is allowed
+> 
+> So just to ensure I don't misunderstand:
+> The way I read the texts, you could have e.g. Upstart as default init
+> system and GNOME depend on systemd with UT? Meaning: software could
+> depend on another init system than the default?
+
+Yes, that's what UT says.
+
+> Just wanting to make sure I am reading this correctly. I was sort of
+> assuming that there would be a preference to rely on the default
+> one. E.g. if you go for Upstart, then preferred to ensure that
+> works.
+
+No, none of the options currently proposed make that distinction.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 18:45:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 18:45:09 GMT) (full text, mbox, link).

+ +

Message #5294 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Michael Gilbert <mgilbert@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Vote sysvinit 4 jessie
+
Date: Mon, 3 Feb 2014 10:42:25 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Feb 03, 2014 at 09:17:33AM -0500, Michael Gilbert wrote:
+> Finally, it is worth considering that there is very little chance for
+> upstart to win this particular vote.  Given the 4:4 systemd:upstart
+> split and existing statements from the 4 on the systemd side, there is
+> very little chance that they will vote upstart high.  Hence those TC
+> members that don't want to see its default should be trying to figure out
+> how to get 1 of the 4 to vote something else above systemd.
+
+Only if upstart supporters actually believe it would be better for Debian to
+keep sysvinit as the default in jessie instead of adopting systemd, which we
+don't.  I'm not going to try to manipulate an outcome that leaves Debian
+with a bad solution for jessie, just because I think there's a slim chance
+it might give a better solution down the line for jessie+1.
+
+> sysvinit is probably the only option that has any possibility of
+> getting 5 or more votes over something else.
+
+That's incorrect.  From what I've seen of the TC's stated positions so far,
+I believe both upstart and systemd have *8* votes over sysvinit.
+
+> At least if sysvinit wins, that gives upstart another cycle to get in
+> better shape, rather than being disqualified now.
+
+Most of the reasons given by those members of the TC that favor systemd do
+not change with the passage of time.  If the only issue was feature parity,
+that could certainly be addressed by a concerted focus of resources.  But
+the #1 reason given is alignment with other distributions, which doesn't go
+away next cycle.  The #2 reason given concerns the fundamental difference
+between upstart's and systemd's modeling of the universe, which also isn't
+going to go away.
+
+So all deferring for another cycle does is leave Debian with annoying
+cumbersome init scripts and unsolvable race conditions for another cycle.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 21:21:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bill Myers <bill_myers@outlook.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 21:21:10 GMT) (full text, mbox, link).

+ +

Message #5299 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bill Myers <bill_myers@outlook.com>
+
To: "727708@bugs.debian.org" <727708@bugs.debian.org>
+
Subject: Depending on an init to be pid 1 == depending on a kernel to be + running
+
Date: Mon, 3 Feb 2014 21:11:57 +0000
+
+
I think the issue of whether packages can depend on a specific init to be pid 1 is essentially identical to whether packages can depend on a specific kernel (Linux vs FreeBSD vs Hurd) to be running.
+
+I'm not sure what the exact Debian policy is for that, but just copying that seems to me the most natural decision. 		 	   		  
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 21:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 21:30:04 GMT) (full text, mbox, link).

+ +

Message #5304 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Bill Myers <bill_myers@outlook.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Depending on an init to be pid 1 == depending on a kernel to be running
+
Date: Mon, 03 Feb 2014 13:26:26 -0800
+
+
Bill Myers <bill_myers@outlook.com> writes:
+
+> I think the issue of whether packages can depend on a specific init to
+> be pid 1 is essentially identical to whether packages can depend on a
+> specific kernel (Linux vs FreeBSD vs Hurd) to be running.
+
+> I'm not sure what the exact Debian policy is for that, but just copying
+> that seems to me the most natural decision.
+
+It's conceptually similar, but since kernels are tied directly to a Debian
+architecture, it's easier to handle the kernel case using our existing
+infrastructure.  There just isn't a binary package for that architecture
+if it doesn't work with that kernel, and most of the problematic cases,
+such as switching between init systems, don't apply in an analogous way.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Feb 2014 22:06:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Feb 2014 22:06:05 GMT) (full text, mbox, link).

+ +

Message #5309 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: Depending on an init to be pid 1 == depending on a + kernel to be running
+
Date: Mon, 3 Feb 2014 14:02:59 -0800
+
+
Russ Allbery wrote:
+> It's conceptually similar, but since kernels are tied directly to a
+> Debian architecture, it's easier to handle the kernel case using our
+> existing infrastructure.  There just isn't a binary package for that
+> architecture if it doesn't work with that kernel, and most of the
+> problematic cases, such as switching between init systems, don't apply
+> in an analogous way.
+
+There's a related case that seems exactly similar, though: some packages
+need to depend on specific kernel features or versions, but that's not
+currently representable in the packaging system.  You can't currently
+depend on "a kernel with CONFIG_FOO available (or with the module
+installed)", or "a kernel with the foo syscall", or "kernel version >>
+3.10".  That restriction against depending on a kernel applies for a
+variety of reasons: to support locally compiled and installed kernels,
+to allow for multiple installed kernels chosen at boot time, and to cope
+with having a kernel installed without having booted into it (perhaps
+because you haven't rebooted yet).
+
+While we don't need to support locally compiled and installed init
+systems (anyone doing that can use equivs or package it properly), we
+may potentially want to support multiple installed inits in parallel, we
+may want to support selecting them at boot time, and we *definitely*
+have to handle the case where you've installed a new init but not yet
+rebooted into it.
+
+It'd be nice to have a solution to both of those problems.  Perhaps we
+could (start the multi-release process to) augment dpkg to support
+special dependencies such as kernels and init systems, for instance.
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 04 Feb 2014 01:24:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 04 Feb 2014 01:24:17 GMT) (full text, mbox, link).

+ +

Message #5314 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Vote sysvinit 4 jessie
+
Date: Mon, 3 Feb 2014 20:22:18 -0500
+
+
On Mon, Feb 3, 2014 at 1:42 PM, Steve Langasek wrote:
+> So all deferring for another cycle does is leave Debian with annoying
+> cumbersome init scripts and unsolvable race conditions for another cycle.
+
+Which have already been solved for a long time now.  It's not like a
+bunch of new sysvinit bugs magically appear now.
+
+Anyway, like I said, the real gain is that this allows users to "vote"
+on direction with their feet (i.e. if most are choosing systemd or
+anything else, that is going to be clear in popcon).  That is better,
+I think, than making decisions on smells and feels.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 04 Feb 2014 02:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 04 Feb 2014 02:09:04 GMT) (full text, mbox, link).

+ +

Message #5319 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Vote sysvinit 4 jessie
+
Date: Mon, 3 Feb 2014 21:04:10 -0500
+
+
On Mon, Feb 3, 2014 at 9:31 AM, Jonathan Dowland wrote:
+> On 03/02/2014 14:17, Michael Gilbert wrote:
+>> Hence those TC members that don't want to see its default should be
+>> trying to figure out how to get 1 of the 4 to vote something else
+>> above systemd.
+>
+> Shouldn't the TC members focus on their own vote and leave the others
+> to focus on theirs?
+
+It's a discussion, so its perfectly reasonable to think about the
+various alternatives and make arguments that may or may not be
+persuasive.
+
+> Likewise, if one finds themselves in the minority,
+> should they not accept that gracefully?
+
+Absolutely.  The point is more about considering the long term
+effects.  Any init system that is decided now, will be very hard to
+unseat in the future thanks to momentum (just like sysvinit is really
+hard to unseat right now).  So any solution that loses now, will
+effectively never have another chance, so let's take the time to get
+it right.  If we can find a way to let users make that direction
+clearer, that would be ideal.
+
+That "take the time to get it right" option is sysvinit, and its a
+perfectly reasonable solution for another couple years.  It works
+pretty well now without any changes or imposition on the project and
+has a 30 year history.
+
+Sometimes it makes more sense to maintain the status quo than to rush
+into something.  The project is in the process of evolving technical
+solutions in the meantime anyway, so a forced decision from the TC
+isn't at all necessary, but they seem dead set on it, even in the face
+of causing themselves their own loss, which is a rather peculiar bit
+of psychology on its own.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 04 Feb 2014 04:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 04 Feb 2014 04:48:04 GMT) (full text, mbox, link).

+ +

Message #5324 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Michael Gilbert <mgilbert@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Vote sysvinit 4 jessie
+
Date: Mon, 03 Feb 2014 20:44:17 -0800
+
+
Michael Gilbert <mgilbert@debian.org> writes:
+> On Mon, Feb 3, 2014 at 1:42 PM, Steve Langasek wrote:
+>> So all deferring for another cycle does is leave Debian with annoying
+>> cumbersome init scripts and unsolvable race conditions for another cycle.
+>
+> Which have already been solved for a long time now.
+
+No, they haven't. Try eg. various combinations of layering md-raid,
+cryptsetup, lvm and btrfs on top of each other. If you feel particularly
+adventurous, add some storage devices that take minutes to initialize or
+need a working network connection (disclaimer: I haven't personally
+tried the latter, but I'm pretty sure it's not going to make things work
+better).
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 04 Feb 2014 05:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 04 Feb 2014 05:12:05 GMT) (full text, mbox, link).

+ +

Message #5329 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Vote sysvinit 4 jessie
+
Date: Tue, 4 Feb 2014 00:09:14 -0500
+
+
On Mon, Feb 3, 2014 at 11:44 PM, Nikolaus Rath wrote:
+> Michael Gilbert writes:
+>> On Mon, Feb 3, 2014 at 1:42 PM, Steve Langasek wrote:
+>>> So all deferring for another cycle does is leave Debian with annoying
+>>> cumbersome init scripts and unsolvable race conditions for another cycle.
+>>
+>> Which have already been solved for a long time now.
+>
+> No, they haven't. Try eg. various combinations of layering md-raid,
+> cryptsetup, lvm and btrfs on top of each other. If you feel particularly
+> adventurous, add some storage devices that take minutes to initialize or
+> need a working network connection (disclaimer: I haven't personally
+> tried the latter, but I'm pretty sure it's not going to make things work
+> better).
+
+For use cases like this where sysvinit is insufficient, the user can
+use init-select or whatever to use a newer init that does handle this
+better.
+
+Clearly using sysvinit as default does not preclude progress in these
+areas.  It just means that the user manually decides to use a
+different init to "solve" these kinds of tricky problems.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 04 Feb 2014 13:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to peter@pblackman.plus.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 04 Feb 2014 13:21:04 GMT) (full text, mbox, link).

+ +

Message #5334 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Peter <peter@pblackman.plus.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Vote sysvinit 4 jessie
+
Date: Tue, 04 Feb 2014 13:13:33 +0000
+
+
Users "votes" so far are;- (out of a pop. of~ 151,000)
+
+systemd    9473
+upstart        64
+openrc        5
+
+http://qa.debian.org/popcon.php?package=systemd
+http://qa.debian.org/popcon.php?package=upstart
+http://qa.debian.org/popcon.php?package=openrc
+
+
+
+ 
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 04 Feb 2014 14:45:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nick Rhodes <nick@ngrhodes.co.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 04 Feb 2014 14:45:05 GMT) (full text, mbox, link).

+ +

Message #5339 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nick Rhodes <nick@ngrhodes.co.uk>
+
To: 727708@bugs.debian.org
+
Date: Tue, 4 Feb 2014 14:41:51 +0000
+
+
[Message part 1 (text/plain, inline)]
+
>
+> Users "votes" so far are;- (out of a pop. of~ 151,000)
+>
+> systemd    9473
+> upstart        64
+> openrc        5
+>
+> http://qa.debian.org/popcon.php?package=systemd
+> http://qa.debian.org/popcon.php?package=upstart
+> http://qa.debian.org/popcon.php?package=openrc
+>
+
+So what are the "votes" for sysvinit, approx 130,000 ?
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 04 Feb 2014 14:51:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 04 Feb 2014 14:51:09 GMT) (full text, mbox, link).

+ +

Message #5344 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Nick Rhodes <nick@ngrhodes.co.uk>, + Peter <peter@pblackman.plus.com>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708:
+
Date: Tue, 4 Feb 2014 14:49:58 +0000
+
+
Nick Rhodes writes ("Bug#727708: "):
+> So what are the "votes" for sysvinit, approx 130,000 ?
+
+Please, STOP.  These kind of messages aren't going to change anyone's
+mind at this stage.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 04 Feb 2014 16:57:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 04 Feb 2014 16:57:10 GMT) (full text, mbox, link).

+ +

Message #5349 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Processed: block 726763 with 727708
+
Date: Tue, 4 Feb 2014 16:53:21 +0000
+
+
On Sun, Feb 02, 2014 at 12:57:39PM +0100, Tollef Fog Heen wrote:
+> ]] Colin Watson 
+> > The de facto interface for making an init system the default is to
+> > install it as /sbin/init.  While I'm coming at this from a starting
+> > point different from Cameron's above - I haven't yet decided whether I
+> > think it would be good for packages to be able to depend on specific
+> > pid 1 implementations - nevertheless, if we select systemd as the
+> > default I would argue that there should be some arrangement in
+> > packaging to put it in place as /sbin/init, even if that isn't
+> > upstream's advertised method.
+> 
+> You mean, like installing the systemd-sysv package?
+
+Indeed; but people earlier in this thread have said that this isn't the
+preferred approach, so I was arguing that this *should* be the preferred
+approach in Debian if systemd is selected as the default, rather than
+having helper packages that have to wander around fiddling with the
+configuration of half a dozen different boot loaders to point them to
+the right place.
+
+If the people whose comments I was reading weren't accurately reflecting
+the position of the Debian systemd maintainers, then I apologise for
+misunderstanding.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 04 Feb 2014 17:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 04 Feb 2014 17:42:05 GMT) (full text, mbox, link).

+ +

Message #5354 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Processed: block 726763 with 727708
+
Date: Tue, 04 Feb 2014 18:38:21 +0100
+
+
]] Colin Watson 
+
+> On Sun, Feb 02, 2014 at 12:57:39PM +0100, Tollef Fog Heen wrote:
+> > ]] Colin Watson 
+> > > The de facto interface for making an init system the default is to
+> > > install it as /sbin/init.  While I'm coming at this from a starting
+> > > point different from Cameron's above - I haven't yet decided whether I
+> > > think it would be good for packages to be able to depend on specific
+> > > pid 1 implementations - nevertheless, if we select systemd as the
+> > > default I would argue that there should be some arrangement in
+> > > packaging to put it in place as /sbin/init, even if that isn't
+> > > upstream's advertised method.
+> > 
+> > You mean, like installing the systemd-sysv package?
+> 
+> Indeed; but people earlier in this thread have said that this isn't the
+> preferred approach, so I was arguing that this *should* be the preferred
+> approach in Debian if systemd is selected as the default, rather than
+> having helper packages that have to wander around fiddling with the
+> configuration of half a dozen different boot loaders to point them to
+> the right place.
+
+It's the preferred way of testing and using systemd while sysvinit is
+the default, since apt has pathological behaviours once you start
+replacing Essential: yes packages.
+
+Ifwhen the default changes, we'll change the recommended deployment
+strategy as well.
+
+> If the people whose comments I was reading weren't accurately reflecting
+> the position of the Debian systemd maintainers, then I apologise for
+> misunderstanding.
+
+No worries, I think we got the misunderstanding (if we can even call it
+that) cleared up.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 04 Feb 2014 18:45:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 04 Feb 2014 18:45:09 GMT) (full text, mbox, link).

+ +

Message #5359 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Processed: block 726763 with 727708
+
Date: Tue, 04 Feb 2014 20:43:10 +0200
+
+
On Tue, 2014-02-04 at 16:53 +0000, Colin Watson wrote:
+> On Sun, Feb 02, 2014 at 12:57:39PM +0100, Tollef Fog Heen wrote:
+> > You mean, like installing the systemd-sysv package?
+> 
+> Indeed; but people earlier in this thread have said that this isn't the
+> preferred approach, so I was arguing that this *should* be the preferred
+> approach in Debian if systemd is selected as the default, rather than
+> having helper packages that have to wander around fiddling with the
+> configuration of half a dozen different boot loaders to point them to
+> the right place.
+> 
+> If the people whose comments I was reading weren't accurately reflecting
+> the position of the Debian systemd maintainers, then I apologise for
+> misunderstanding.
+
+The main issue is that systemd-sysv conflicts with sysvinit-core, while
+the systemd package doesn't. If you do the first install of systemd with
+systemd-sysv, this doesn't only change the default, but forces the
+removal of the whole sysvinit implementation. This can be compared to a
+kernel package install that forces the removal of all previously
+installed kernels before you can boot to the new one.
+
+So the systemd-sysv route has the clear technical disadvantage that it
+does not support parallel installation of sysvinit and systemd. I think
+the ability to easily switch back to sysvinit for troubleshooting if you
+encounter issues does have some value. Of course, it would be possible
+to switch /sbin/init while both are installed.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 04 Feb 2014 21:03:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 04 Feb 2014 21:03:12 GMT) (full text, mbox, link).

+ +

Message #5364 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Tue, 4 Feb 2014 13:01:35 -0800
+
+
On Sat, 01 Feb 2014, Steve Langasek wrote:
+> Where would this ballot option rank vis-à-vis FD, for those TC members
+> who are opposed to the "loose coupling" option?
+
+I'm planning on ranking everything above FD. However, I would rank this
+particular option at the same level as L.
+ 
+> == dependencies rider version S (split-the-init) ==
+
+[...]
+
+>    Software not part of an init system's implementation may require
+>    interfaces unrelated to service management that are provided as
+>    part of an init system, but the dependency on such interfaces must
+>    be declared in a way that allows the dependency to be satisfied by
+>    compatible implementations on other init systems.
+
+I think requiring maintainers to implement this isn't tenable;
+maintainers should accept technically viable patches which do this, and
+if they do not, the CTTE can be invoked to resolve the problem.
+
+But that said, if this is an option that needs to be on the ballot, we
+should get it there quickly.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+Democracy means simply the bludgeoning of the people by the people for
+the people.
+ -- Oscar Wilde
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 04 Feb 2014 22:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 04 Feb 2014 22:09:04 GMT) (full text, mbox, link).

+ +

Message #5369 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: Michael Gilbert <mgilbert@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Vote sysvinit 4 jessie
+
Date: Tue, 04 Feb 2014 14:07:02 -0800
+
+
Michael Gilbert <mgilbert@debian.org> writes:
+> On Mon, Feb 3, 2014 at 11:44 PM, Nikolaus Rath wrote:
+>> Michael Gilbert writes:
+>>> On Mon, Feb 3, 2014 at 1:42 PM, Steve Langasek wrote:
+>>>> So all deferring for another cycle does is leave Debian with annoying
+>>>> cumbersome init scripts and unsolvable race conditions for another cycle.
+>>>
+>>> Which have already been solved for a long time now.
+>>
+>> No, they haven't. Try eg. various combinations of layering md-raid,
+>> cryptsetup, lvm and btrfs on top of each other. If you feel particularly
+>> adventurous, add some storage devices that take minutes to initialize or
+>> need a working network connection (disclaimer: I haven't personally
+>> tried the latter, but I'm pretty sure it's not going to make things work
+>> better).
+>
+> For use cases like this where sysvinit is insufficient, the user can
+> use init-select or whatever to use a newer init that does handle this
+> better.
+
+You are not making sense to me. You claimed that race conditions and
+bugs in sysvinit have been solved. They have not been solved. So now you
+are claiming that *because better init systems exist*, these bugs do not
+matter and we should stick with sysvinit?
+
+End of discussion for me here.
+
+Best,
+Nikolaus
+
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 02:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Peter Dolding <oiaohm@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 02:42:04 GMT) (full text, mbox, link).

+ +

Message #5374 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Peter Dolding <oiaohm@gmail.com>
+
To: ChaosEsque Team <chaosesqueteam@yahoo.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Re: Re: Bug#727708: multiple init systems: We have to see it for + what it is: Lennart/Linux OS. Yes it is.
+
Date: Wed, 5 Feb 2014 12:39:43 +1000
+
+
On Wed, Jan 29, 2014 at 6:00 PM, ChaosEsque Team
+<chaosesqueteam@yahoo.com> wrote:
+> Ah, you're a systemd acolyte. You smugly proclaim that it is USELESS to resist!
+
+No wrong.    There  are just possible ways to resist.   Then there are
+impossible ways.
+
+>>Forking every package that depends on systemd is pointless.
+>
+> If you read what I wrote you would see that I said fork everything below/or above
+> (whatever "software stack" direction you believe in) the linux kernel,
+> and maintain them in a very stable form, applying security patches and bug fixes.
+
+Dbus userspace has differences in operation to kdbus kernel space.
+The control parts around kdbus have been done by systemd.  Then you
+have cgroups and their design that systemd is matching up to what the
+developers of that want.
+
+Sorry systemd integration with Linux kernel is deep.   Forking
+everything using systemd and thinking that is a way out is simply not
+a possibility the kernel is a dependency in this mix.
+
+You will require a systemd replacement or at least a part replacement
+not to use systemd in future at the moment.  Yes a part replacement to
+manage kdbus and cgroups for example.
+
+So options are common standards between init systems for
+package/application makers to use or forking systemd itself.  Anything
+else is going to run into road blocks.
+
+upstart has a fork of systemd logind.  So are going the fork path..
+
+>>Fork the kernel???  right we all know how successful this turns out
+>>for those making clones of Solaris.  Solaris clones have to go SMC
+>>they don't have a option of using a different init system.
+>
+> Personally I do not care what you or Lennart are sick of (which includes
+> unix philosophy, as-well as any people who are learned in the unix
+> way). I do not want to learn your new little computer religion (getting
+> bigger every day). There are social consequences to your hostile
+> internal fork of the Gnu/Linux system. You and Lennart do not give a
+> damn about those consequences for other people.
+
+There are consequences to people running a crappy designed init system
+as well.   More down time.
+
+
+>>Secure software is a science.  I am sick of those who say Software is
+>>more an art.  Saying software is a art is a nice universal excuse not
+>>todo quality control.
+>
+> Anyway, one way to have secure software is to freeze development
+> at some mature version, and then do an audit and focus on fixing
+> all the little niggling bugs and failings. Not that you windows programmer
+> refugees would know anything about that. You're a flavor of the month
+> or half-decade kind of people. And you are attacking the linux system
+> from the inside. You like building on shifting sands, and you like it
+> even more to force us all to live on the beach with you.
+>
+> If you want secure software, it's called the grsecurity patch and PAX, not systemd.
+
+Systemd does bring some security fixes that grsecuirty and pax cannot
+fix.  If you like it or not systemd fixes some of the issues with
+sysvinit.
+
+Journald and cgroups solve a issue with error logging where
+applications can incorrectly report what they are.  Yes syslog issues.
+ Yes there is a kernel issue in the Linux kernel where you cannot
+track what process started what other process without using cgroups.
+
+These kernel issues are why init systems cannot be OS generic and work
+correctly.  OS kernel issues need to be taken into account when
+starting processes.   Should package mantainers need to worry about
+these OS differences.  Most likely no.   We just need a generic
+standard that the different init systems accept.
+>
+>>Sysvinit came on Linux by being lazy.
+> It came on linux by doing one thing and doing it well: it starts various processes
+> the system administrator wants started, and then it gets out of the way.
+> Very nice and secure design paradigm: does few things, has few lines of code.
+>
+Sorry its sysvinit is horrible from a secure and design paradigms.
+There is a lot of extra code writing in sysvinit with lots of extra
+ways to break things.
+
+Really sysvinit was at the start poorly made clone of BSD init.
+
+http://en.wikipedia.org/wiki/Init
+
+BSD init system that is shell script based was in fact designed todo 1
+thing well.  Starting the system.    What is the big difference
+between BSD init and Sysvinit.  BSD init supports dependencies.    Yes
+the rcorder in BSD init does the same a systemd to start all the
+services in the correct order so they can start.
+
+The problem is it was lazy to take sysvinit instead of using a proper
+solution from the start.  sysvinit throws start up order back on
+administrators and expects them to be skilled enough to start
+everything in the correct order.   This is not a modern init system
+heck its not a quality historic init system.
+
+The simple fact is sysvinit has never done one thing well.  Tidy or
+effectively is not something you link with sysvinit.  You can end up
+with services spinning and eating up resources waiting for other
+services to start because sysvinit does not have a dependency solution
+of any form.
+
+Like BSD users never had to manually order their services so their
+system would start.   Ordering services that is truly a responsibility
+of a init system.   So why do Linux users have to keep on putting up
+with this hell????
+
+You might not like what is being done.   systemd shake up has had to come.
+
+>>The Linux world is horribly fragmented.
+> Good. It is called choice. Guess what: the hobbyists do not exist to promote or
+> expand that religion in your mind called "Linux" or "Desktop Linux" or "The Universal Faith".
+> You think if you could just FORCE the Linux world to standardize on YOUR
+> software and YOUR interfaces then they would work more efficiently towards YOUR
+> goals (of supreme Desktop OS or whatever computer religion/heresy you're into.)
+>
+> As an aside: you know once upon a time there was little fragmentation in the init system area.
+> It was pretty much a non issue and no app cared what init system you ran.
+> Lennart and friends changed all that.
+
+This is a complete lie.   There have always been multi init systems
+and fragmentation.  Even inside sysvinit there were different parties
+ideas where common code between init scripts should be stored.
+
+sysvinit was the first init fragmentation with a rough copy of BSD
+init lacking core features.  Then after that we have had other init
+systems forcing themselves to be sysvinit compatible.   So horrible
+fragmented without true free choice.
+
+I really do want free choice in init systems.   I want some true
+competition.    I don't want garbage of sysvinit being keeping on
+forced on us.   Only way for true competition is something to replace
+shell scripts as a startup declaration formation.   Something that can
+run into a generator and spit out what ever init system I want to use
+files.
+
+>
+> In math and science there are often only a handful of ways to
+> do a particular thing. In art and religion there are infinite possibilities
+> and choices: software is the same. Ofcourse all my software
+> is suspect, as am I. Perhaps I'm a heretic and should be burned.
+>
+There is infinite possibilities in software but only a limited number
+are secure and correctly done.
+
+I would like to see other solutions done correct.
+
+Did you miss me raising openrc.   I am not just for systemd.  I am for
+a solution that can work inside the realities.
+
+Freebsd being dominate launchd and Solaris being dominate SMC and
+Linux being something different is the reality we have to live with.
+
+Attempting to be like you ChaosEsque Team will never get a solution.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 03:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Peter Dolding <oiaohm@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 03:00:05 GMT) (full text, mbox, link).

+ +

Message #5379 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Peter Dolding <oiaohm@gmail.com>
+
To: ChaosEsque Team <chaosesqueteam@yahoo.com>
+
Cc: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: multiple init systems: We have to see it for what it + is: Lennart/Linux OS. Not.
+
Date: Wed, 5 Feb 2014 12:56:16 +1000
+
+
On Wed, Jan 29, 2014 at 6:20 PM, ChaosEsque Team
+<chaosesqueteam@yahoo.com> wrote:
+> Honestly. I, and many many many others, do NOT WANT SYSTEMD.
+> We do not want to be forced or cajoled into using it.
+> NOR do we want to be PUNISHED for not using it.
+> "heheh yea you don't have to use it, but nothing will work on your system lolz hahhahah!"
+>
+> The systemd people seem to hate freedom and choice. They seem to be
+> totalitarians. Why must we be forced to use their "software stack"
+> Why do we have to accept their tendrils needlessly corrupting every
+> free-software project that is at the "core" of Gnu/Linux?
+>
+Lets be clear here.   Many of us don't want sysvinit.  Sysvinit from
+day one was junk.  Sysvinit has always been junk.
+
+If debian was even changing to BSD shell script based init I would be
+happier than staying with sysvinit.
+
+The reality if you don't want to go systemd issues of Linux have to be
+fixed.   Like being able to track what process started what process
+without generating a horrible mess.   upstart ptracing everything is a
+horrible solution to that problem..
+
+There comes a point people need to be forced to act to deal with
+issues they have not been fixing.
+
+You are making the mistake thinking some of us supporting systemd are
+against other options.   I am supporting systemd only because its
+truly designed well.   Would I like to see upstart or openrc or some
+other modern design init system able to battle against systemd yes I
+would.   Would I like to have the option of using bsd init on Linux
+yes I would.
+
+Why the tendrils of systemd are going so far is building quality
+controls over many features of the Linux kernel have been disregarded.
+  Before systemd logind name another program that would wrap a user in
+a cgroup in the login cleanly.   The answer is there is not one.
+
+Systemd is so bad from a competition point of view because no other
+init system before it has been stepping up to implement everything the
+OS can do.
+
+Openrc and upstart are two that have a possibility of stepping up and
+fighting against systemd.
+
+SMC on solaris tells as clearly if you don't have init systems that
+support the kernel you are dead long term.  There were a stack of
+cross platform init systems that use to support solaris a long time
+ago that are no longer usable.
+
+History if you don't learn from it you are doomed to Repeat it
+ChaosEsque Team.  Everything you are saying are basically the same as
+what solaris users said when Sun went SMC.
+
+Step back ChaosEsque see that everything systemd is doing is not bad.
+There are a lot of issues in sysvinit that should not be there.
+
+The issue you are after is not really stopping systemd but putting the
+systems in place that other init systems can still compete.   Some
+like sysvinit just need to die due to being too defective to live.
+Some like upstart need to fix a licensing issue and a method issue and
+some like openrc need more time in development.
+
+Systemd most likely will not remain the only choice for ever.   Short
+time systemd will get some dominance due to lack of standards todo
+particular things and lack of tools todo particular things.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 08:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thomas Goirand <zigo@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 08:06:04 GMT) (full text, mbox, link).

+ +

Message #5384 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thomas Goirand <zigo@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: OpenRC + Hurd status
+
Date: Wed, 05 Feb 2014 16:03:09 +0800
+
+
Hi,
+
+Just a short message to inform everyone that, with the latest sysvinit
+package from Sid (eg: 2.88dsf-47) and the latest OpenRC package from
+Experimental (eg: 0.12.4+20131230-8), then Hurd just boots fine with
+OpenRC! :)
+
+Here's how to do it:
+
+apt-get install initscripts sysv-rc sysvinit \
+    sysvinit-core sysvinit-utils
+update-alternatives --config runsystem
+
+The later command tells hurd to use sysv-rc (otherwise it continues to
+use the Hurd specific boot hack thing...). Then just install OpenRC on
+top of that:
+apt-get install openrc
+
+I'm not sure installing sysv-rc is even needed. Probably installing
+OpenRC first, then the other sysvinit packages would work as well.
+
+There's nothing more to it: it just works (tm)! :)
+
+Hoping that the status update and our porting efforts are appreciated,
+Cheers,
+
+Thomas Goirand (zigo)
+
+P.S: My experience with Hurd was ok-ish, though the "console randomly
+doesn't come up" bug was really frustrating, especially considering that
+Hurd only uses ext2. :(
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 16:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 16:39:04 GMT) (full text, mbox, link).

+ +

Message #5389 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 16:33:57 +0000
+
+
Ian Jackson writes ("Bug#727708: package to change init systems"):
+> I now intend to do the CFV at 16:30 UTC on Wednesday.
+
+I hereby call for votes on my previously proposed resolution and
+amendments.  All the options require a simple majority.
+
+The list of options, and full resolution text, are reproduced below.
+
+Thanks,
+Ian.
+
+
+Options on the ballot:
+
+  DT   systemd default in jessie, requiring specific init is allowed
+  DL   systemd default in jessie, requiring specific init NOT allowed
+
+  UT   upstart default in jessie, requiring specific init is allowed
+  UL   upstart default in jessie, requiring specific init NOT allowed
+
+  OT   openrc default in jessie, requiring specific init is allowed
+  OL   openrc default in jessie, requiring specific init NOT allowed
+
+  VT   sysvinit default in jessie, requiring specific init is allowed
+  VL   sysvinit default in jessie, requiring specific init NOT allowed
+
+  GR   project should decide via GR
+
+  FD   further discussion
+
+== version D (systemD) ==
+
+   The default init system for Linux architectures in jessie should
+   be systemd.
+
+== version U (Upstart) ==
+
+   The default init system for Linux architectures in jessie should
+   be upstart.
+
+== version O (Openrc) ==
+
+   The default init system for Linux architectures in jessie should
+   be openrc.
+
+== version V (sysVinit) ==
+
+   The default init system for Linux architectures in jessie should
+   be sysvinit (no change).
+
+== version GR (General Resolution) ==
+
+   The Technical Committee requests that the project decide the
+   default init system for jessie by means of General Resolution.
+
+== clarification text for all versions except GR ==
+
+   This decision is limited to selecting a default initsystem for
+   jessie.  We expect that Debian will continue to support multiple
+   init systems for the foreseeable future; we continue to welcome
+   contributions of support for all init systems.
+
+   Therefore, for jessie and later releases:
+
+== dependencies rider version T (Tight coupling) ==
+
+   Software may require a specific init system to be pid 1.
+
+   However, where feasible, software should interoperate with
+   all init systems; maintainers are encouraged to accept
+   technically sound patches to enable interoperation, even if it
+   results in degraded operation while running under the init system
+   the patch enables interoperation with.
+
+== dependencies rider version L (Loose coupling) ==
+
+   Software outside of an init system's implementation may not require
+   a specific init system to be pid 1, although degraded operation is
+   tolerable.
+
+   Maintainers are encouraged to accept technically sound patches
+   to enable improved interoperation with various init systems.
+
+== rider for all versions except GR ==
+
+   This decision is automatically vacated by any contrary General
+   Resolution which passes by a simple majority.  In that case the
+   General Resolution takes effect and the whole of this TC resolution
+   is to be taken as withdrawn by the TC, just as if the TC had
+   explicitly withdrawn it by a subsequent TC resolution.
+
+-- 
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 16:39:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 16:39:07 GMT) (full text, mbox, link).

+ +

Message #5394 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 16:36:36 +0000
+
+
Ian Jackson writes ("Bug#727708: Call for votes on init system resolution"):
+> I hereby call for votes on my previously proposed resolution and
+> amendments.  All the options require a simple majority.
+
+I vote:
+
+ 1.  UL   upstart default in jessie, requiring specific init NOT allowed
+ 2.  DL   systemd default in jessie, requiring specific init NOT allowed
+ 3.  OL   openrc default in jessie, requiring specific init NOT allowed
+ 4.  VL   sysvinit default in jessie, requiring specific init NOT allowed
+ 5.  GR   project should decide via GR
+ 6.  FD   further discussion
+ 7.  UT   upstart default in jessie, requiring specific init is allowed
+ 8.  OT   openrc default in jessie, requiring specific init is allowed
+ 9.  VT   sysvinit default in jessie, requiring specific init is allowed
+ 10. DT   systemd default in jessie, requiring specific init is allowed
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 17:21:20 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 17:21:20 GMT) (full text, mbox, link).

+ +

Message #5399 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 09:17:30 -0800
+
+
On Wed, 05 Feb 2014, Ian Jackson wrote:
+> Options on the ballot:
+
+[...]
+
+I Vote:
+
+1. DT   systemd default in jessie, requiring specific init is allowed
+2. DL   systemd default in jessie, requiring specific init NOT allowed
+3. UT   upstart default in jessie, requiring specific init is allowed
+4. UL   upstart default in jessie, requiring specific init NOT allowed
+5. OT   openrc default in jessie, requiring specific init is allowed
+6. OL   openrc default in jessie, requiring specific init NOT allowed
+7. VT   sysvinit default in jessie, requiring specific init is allowed
+8. VL   sysvinit default in jessie, requiring specific init NOT allowed
+9. GR   project should decide via GR
+10. FD  further discussion
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+If a nation values anything more than freedom, it will lose its
+freedom; and the irony of it is that if it is comfort or money it
+values more, it will lose that, too.
+ -- W. Somerset Maugham
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 17:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 17:33:04 GMT) (full text, mbox, link).

+ +

Message #5404 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 09:31:01 -0800
+
+
On Wed, 05 Feb 2014, Ian Jackson wrote:
+> Ian Jackson writes ("Bug#727708: Call for votes on init system resolution"):
+> > I hereby call for votes on my previously proposed resolution and
+> > amendments.  All the options require a simple majority.
+> 
+> I vote:
+
+[...]
+
+>  6.  FD   further discussion
+>  7.  UT   upstart default in jessie, requiring specific init is allowed
+>  8.  OT   openrc default in jessie, requiring specific init is allowed
+>  9.  VT   sysvinit default in jessie, requiring specific init is allowed
+>  10. DT   systemd default in jessie, requiring specific init is allowed
+
+I'm puzzled by this ordering. The wording in the "tight" option was
+specifically chosen to be advisory and reflect the current state of
+affairs. While I can see preferring to avoid dependencies between
+packages and the init system, it's not clear to me why one would rank
+the current state of affairs with regards to init system dependencies
+below FD unless one was trying to engage the dropping mechanism of
+A.6.3.
+
+In fact, if this was your intention all along, it's not clear at all to
+me why we had to couple these votes.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+Given that the odds of a miracle are one in one million, and events
+which could be a miracle happen every second, the odds of not seeing a
+miracle in a month are less than 8 in 100. Clearly miracles are not
+all that miraculous.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 17:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 17:45:04 GMT) (full text, mbox, link).

+ +

Message #5409 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 09:41:31 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian,
+
+On Wed, Feb 05, 2014 at 04:33:57PM +0000, Ian Jackson wrote:
+> Ian Jackson writes ("Bug#727708: package to change init systems"):
+> > I now intend to do the CFV at 16:30 UTC on Wednesday.
+
+> I hereby call for votes on my previously proposed resolution and
+> amendments.  All the options require a simple majority.
+
+I am very unhappy to see this CFV in my inbox this morning.  I made it known
+that I was not satisfied with the set of ballot options, and I was still in
+the process of drafting language to try to identify a consensus position
+that the TC would support as a whole.  While we obviously don't want to drag
+out the discussion indefinitely, I don't think it's reasonable to give a
+48-hour deadline, during a work week, in the body of one message among
+dozens.  With nothing to call attention to itself, that message sat unread
+in my box among a pile of others until just now, when it's too late.
+
+This is substantially the same as Bdale's earlier CFV, which you objected to
+at the time.
+
+I think whichever option wins on this ballot, if the TC leaves the
+discussion here it will be a bad outcome for Debian because it leaves
+maintainers without clear guidance about how to avoid fragmenting the
+archive.
+
+Since this vote will almost certainly result in a resolution passing, I
+think I will need to begin drafting a follow-up resolution to address this,
+under 6.1.1.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 17:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 17:54:04 GMT) (full text, mbox, link).

+ +

Message #5414 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 18:51:37 +0100
+
+
* Ian Jackson (ijackson@chiark.greenend.org.uk) [140205 17:39]:
+> Ian Jackson writes ("Bug#727708: package to change init systems"):
+> > I now intend to do the CFV at 16:30 UTC on Wednesday.
+> 
+> I hereby call for votes on my previously proposed resolution and
+> amendments.  All the options require a simple majority.
+> 
+> The list of options, and full resolution text, are reproduced below.
+
+I vote for
+ 1.  UL   upstart default in jessie, requiring specific init NOT allowed
+ 2.  DL   systemd default in jessie, requiring specific init NOT allowed
+ 3.  OL   openrc default in jessie, requiring specific init NOT allowed
+ 4.  VL   sysvinit default in jessie, requiring specific init NOT allowed
+ 5.  FD   further discussion
+ 6.  GR   project should decide via GR
+ 7.  UT   upstart default in jessie, requiring specific init is allowed
+ 8.  DT   systemd default in jessie, requiring specific init is allowed
+ 9.  OT   openrc default in jessie, requiring specific init is allowed
+10.  VT   sysvinit default in jessie, requiring specific init is allowed
+
+
+Regards,
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 17:57:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 17:57:05 GMT) (full text, mbox, link).

+ +

Message #5419 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 18:53:48 +0100
+
+
* Andreas Barth (aba@ayous.org) [140205 18:51]:
+> * Ian Jackson (ijackson@chiark.greenend.org.uk) [140205 17:39]:
+> > Ian Jackson writes ("Bug#727708: package to change init systems"):
+> > > I now intend to do the CFV at 16:30 UTC on Wednesday.
+> > 
+> > I hereby call for votes on my previously proposed resolution and
+> > amendments.  All the options require a simple majority.
+> > 
+> > The list of options, and full resolution text, are reproduced below.
+> 
+> I vote for
+>  1.  UL   upstart default in jessie, requiring specific init NOT allowed
+>  2.  DL   systemd default in jessie, requiring specific init NOT allowed
+>  3.  OL   openrc default in jessie, requiring specific init NOT allowed
+>  4.  VL   sysvinit default in jessie, requiring specific init NOT allowed
+>  5.  FD   further discussion
+>  6.  GR   project should decide via GR
+>  7.  UT   upstart default in jessie, requiring specific init is allowed
+>  8.  DT   systemd default in jessie, requiring specific init is allowed
+>  9.  OT   openrc default in jessie, requiring specific init is allowed
+> 10.  VT   sysvinit default in jessie, requiring specific init is allowed
+
+
+After reading Steves Mail changing to
+ 1.  FD   further discussion
+ 2.  UL   upstart default in jessie, requiring specific init NOT allowed
+ 3.  DL   systemd default in jessie, requiring specific init NOT allowed
+ 4.  OL   openrc default in jessie, requiring specific init NOT allowed
+ 5.  VL   sysvinit default in jessie, requiring specific init NOT allowed
+ 6.  GR   project should decide via GR
+ 7.  UT   upstart default in jessie, requiring specific init is allowed
+ 8.  DT   systemd default in jessie, requiring specific init is allowed
+ 9.  OT   openrc default in jessie, requiring specific init is allowed
+10.  VT   sysvinit default in jessie, requiring specific init is allowed
+
+for the moment.
+
+
+Regards,
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 18:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 18:00:04 GMT) (full text, mbox, link).

+ +

Message #5424 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 09:56:14 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Feb 05, 2014 at 04:33:57PM +0000, Ian Jackson wrote:
+> Ian Jackson writes ("Bug#727708: package to change init systems"):
+> > I now intend to do the CFV at 16:30 UTC on Wednesday.
+
+> I hereby call for votes on my previously proposed resolution and
+> amendments.  All the options require a simple majority.
+
+> The list of options, and full resolution text, are reproduced below.
+
+I vote:
+
+ 1.  UL   upstart default in jessie, requiring specific init NOT allowed
+ 2.  DL   systemd default in jessie, requiring specific init NOT allowed
+ 3.  FD   further discussion
+ 4.  OL   openrc default in jessie, requiring specific init NOT allowed
+ 5.  VL   sysvinit default in jessie, requiring specific init NOT allowed
+ 6.  UT   upstart default in jessie, requiring specific init is allowed
+ 7.  DT   systemd default in jessie, requiring specific init is allowed
+ 8.  OT   openrc default in jessie, requiring specific init is allowed
+ 8.  VT   sysvinit default in jessie, requiring specific init is allowed
+ 9.  GR   project should decide via GR
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 18:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 18:48:04 GMT) (full text, mbox, link).

+ +

Message #5429 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: OpenRC + Hurd status
+
Date: Wed, 5 Feb 2014 13:45:30 -0500
+
+
On Wed, Feb 5, 2014 at 3:03 AM, Thomas Goirand wrote:
+> Hi,
+>
+> Just a short message to inform everyone that, with the latest sysvinit
+> package from Sid (eg: 2.88dsf-47) and the latest OpenRC package from
+> Experimental (eg: 0.12.4+20131230-8), then Hurd just boots fine with
+> OpenRC! :)
+
+[...]
+
+> There's nothing more to it: it just works (tm)! :)
+>
+> Hoping that the status update and our porting efforts are appreciated,
+> Cheers,
+
+There has already been a lot of stated appreciation for your openrc
+work, and I'm sure there is a lot more unstated.
+
+However, I don't think openrc ever got the respect it deserves.  The
+TC is now voting without ever kicking the tires on openrc.  That, I
+think, is quite unfortunate and unfair.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 19:21:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 19:21:10 GMT) (full text, mbox, link).

+ +

Message #5434 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 20:19:25 +0100
+
+
On Wed, Feb 05, 2014 at 04:33:57PM +0000, Ian Jackson wrote:
+> == rider for all versions except GR ==
+> 
+>    This decision is automatically vacated by any contrary General
+>    Resolution which passes by a simple majority.  In that case the
+>    General Resolution takes effect and the whole of this TC resolution
+>    is to be taken as withdrawn by the TC, just as if the TC had
+>    explicitly withdrawn it by a subsequent TC resolution.
+
+I'm not sure I like the way this is worded, I would have prefered
+that you asked me about this before calling for votes.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 19:27:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 19:27:05 GMT) (full text, mbox, link).

+ +

Message #5439 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 21:25:59 +0200
+
+
On Wed, Feb 05, 2014 at 09:56:14AM -0800, Steve Langasek wrote:
+>...
+>  8.  OT   openrc default in jessie, requiring specific init is allowed
+>  8.  VT   sysvinit default in jessie, requiring specific init is allowed
+>...
+
+Is this a typo or an intentional equal ranking?
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 20:09:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 20:09:13 GMT) (full text, mbox, link).

+ +

Message #5444 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 21:08:56 +0100
+
+
On Wed, Feb 05, 2014 at 04:33:57PM +0000, Ian Jackson wrote:
+> Ian Jackson writes ("Bug#727708: package to change init systems"):
+> > I now intend to do the CFV at 16:30 UTC on Wednesday.
+> 
+> I hereby call for votes on my previously proposed resolution and
+> amendments.  All the options require a simple majority.
+> 
+> The list of options, and full resolution text, are reproduced below.
+
+I would really like it that you indicated under which power the
+CTTE is making decisions, and the majority requirements that go
+with that the options, for all your votes.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 21:03:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 21:03:13 GMT) (full text, mbox, link).

+ +

Message #5449 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 12:59:55 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Feb 05, 2014 at 09:25:59PM +0200, Adrian Bunk wrote:
+> On Wed, Feb 05, 2014 at 09:56:14AM -0800, Steve Langasek wrote:
+> >...
+> >  8.  OT   openrc default in jessie, requiring specific init is allowed
+> >  8.  VT   sysvinit default in jessie, requiring specific init is allowed
+> >...
+
+> Is this a typo or an intentional equal ranking?
+
+Intentional.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 21:15:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 21:15:10 GMT) (full text, mbox, link).

+ +

Message #5454 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 22:13:30 +0100
+
+
* Steve Langasek (vorlon@debian.org) [140205 18:45]:
+> I think whichever option wins on this ballot, if the TC leaves the
+> discussion here it will be a bad outcome for Debian because it leaves
+> maintainers without clear guidance about how to avoid fragmenting the
+> archive.
+
+What would you like to see changed?
+
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 21:18:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 21:18:10 GMT) (full text, mbox, link).

+ +

Message #5459 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: Kurt Roeckx <kurt@roeckx.be>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 22:15:00 +0100
+
+
* Kurt Roeckx (kurt@roeckx.be) [140205 21:09]:
+> On Wed, Feb 05, 2014 at 04:33:57PM +0000, Ian Jackson wrote:
+> > Ian Jackson writes ("Bug#727708: package to change init systems"):
+> > > I now intend to do the CFV at 16:30 UTC on Wednesday.
+> > 
+> > I hereby call for votes on my previously proposed resolution and
+> > amendments.  All the options require a simple majority.
+> > 
+> > The list of options, and full resolution text, are reproduced below.
+> 
+> I would really like it that you indicated under which power the
+> CTTE is making decisions, and the majority requirements that go
+> with that the options, for all your votes.
+
+Hm, the same would be valid for Bdales call for votes recently? Or
+what is the difference here?
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 21:54:18 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 21:54:18 GMT) (full text, mbox, link).

+ +

Message #5464 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Andreas Barth <aba@ayous.org>
+
Cc: 727708@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 22:52:44 +0100
+
+
On Wed, Feb 05, 2014 at 10:15:00PM +0100, Andreas Barth wrote:
+> * Kurt Roeckx (kurt@roeckx.be) [140205 21:09]:
+> > On Wed, Feb 05, 2014 at 04:33:57PM +0000, Ian Jackson wrote:
+> > > Ian Jackson writes ("Bug#727708: package to change init systems"):
+> > > > I now intend to do the CFV at 16:30 UTC on Wednesday.
+> > > 
+> > > I hereby call for votes on my previously proposed resolution and
+> > > amendments.  All the options require a simple majority.
+> > > 
+> > > The list of options, and full resolution text, are reproduced below.
+> > 
+> > I would really like it that you indicated under which power the
+> > CTTE is making decisions, and the majority requirements that go
+> > with that the options, for all your votes.
+> 
+> Hm, the same would be valid for Bdales call for votes recently? Or
+> what is the difference here?
+
+I'm really asking about all votes.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 22:12:22 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 22:12:22 GMT) (full text, mbox, link).

+ +

Message #5469 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Kurt Roeckx <kurt@roeckx.be>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 22:05:45 +0000
+
+
Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
+> I would really like it that you indicated under which power the
+> CTTE is making decisions, and the majority requirements that go
+> with that the options, for all your votes.
+
+Sorry not to give you an explicit heads-up about this resolution.  (It
+has been proposed in this form for some time now though.)
+
+Anyway, I think as regards T vs L we are chiefly exercising our power
+to set technical policy.  As regards the default init system we are
+making a decision which has been requested of us by the people
+normally responsible (which would be the d-i maintainersI think).
+
+Certainly we do not intend to overrule any maintainer with this
+resolution.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 22:12:25 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 22:12:25 GMT) (full text, mbox, link).

+ +

Message #5474 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 17:08:35 -0500
+
+
On Wed, Feb 5, 2014 at 3:08 PM, Kurt Roeckx wrote:
+> On Wed, Feb 05, 2014 at 04:33:57PM +0000, Ian Jackson wrote:
+>> Ian Jackson writes ("Bug#727708: package to change init systems"):
+>> > I now intend to do the CFV at 16:30 UTC on Wednesday.
+>>
+>> I hereby call for votes on my previously proposed resolution and
+>> amendments.  All the options require a simple majority.
+>>
+>> The list of options, and full resolution text, are reproduced below.
+>
+> I would really like it that you indicated under which power the
+> CTTE is making decisions, and the majority requirements that go
+> with that the options, for all your votes.
+
+The big question, I think, is whether section 6.3.6 of the
+constitution has been satisfied.  The project is still clearly working
+on solutions, but at a slower pace than some may desire.  See this for
+a recent example:
+https://lists.debian.org/debian-devel/2014/02/msg00106.html
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 22:12:28 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 22:12:28 GMT) (full text, mbox, link).

+ +

Message #5479 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Don Armstrong <don@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 22:09:29 +0000
+
+
Don Armstrong writes ("Bug#727708: Call for votes on init system resolution"):
+> On Wed, 05 Feb 2014, Ian Jackson wrote:
+> >  6.  FD   further discussion
+> >  7.  UT   upstart default in jessie, requiring specific init is allowed
+> >  8.  OT   openrc default in jessie, requiring specific init is allowed
+> >  9.  VT   sysvinit default in jessie, requiring specific init is allowed
+> >  10. DT   systemd default in jessie, requiring specific init is allowed
+> 
+> I'm puzzled by this ordering.
+
+It's quite simple.  I think the most important consideration is
+whether Debian (or some people within Debian) end up forcing people to
+use a particular init system.
+
+>  it's not clear to me why one would rank the current state of
+> affairs with regards to init system dependencies below FD unless one
+> was trying to engage the dropping mechanism of A.6.3.
+
+That's certainly part of it.
+
+> In fact, if this was your intention all along, it's not clear at all to
+> me why we had to couple these votes.
+
+You'll notice that my ranking of the init systems differs between the
+T options and the L options.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 22:21:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 22:21:07 GMT) (full text, mbox, link).

+ +

Message #5484 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 05 Feb 2014 14:19:31 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> Options on the ballot:
+
+>   DT   systemd default in jessie, requiring specific init is allowed
+>   DL   systemd default in jessie, requiring specific init NOT allowed
+
+>   UT   upstart default in jessie, requiring specific init is allowed
+>   UL   upstart default in jessie, requiring specific init NOT allowed
+
+>   OT   openrc default in jessie, requiring specific init is allowed
+>   OL   openrc default in jessie, requiring specific init NOT allowed
+
+>   VT   sysvinit default in jessie, requiring specific init is allowed
+>   VL   sysvinit default in jessie, requiring specific init NOT allowed
+
+>   GR   project should decide via GR
+
+>   FD   further discussion
+
+I vote:
+
+    DT GR DL UT FD OT VT UL OL VL
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 22:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 22:33:04 GMT) (full text, mbox, link).

+ +

Message #5489 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 17:28:41 -0500
+
+
On Wed, Feb 5, 2014 at 5:05 PM, Ian Jackson wrote:
+> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
+>> I would really like it that you indicated under which power the
+>> CTTE is making decisions, and the majority requirements that go
+>> with that the options, for all your votes.
+>
+> Sorry not to give you an explicit heads-up about this resolution.  (It
+> has been proposed in this form for some time now though.)
+>
+> Anyway, I think as regards T vs L we are chiefly exercising our power
+> to set technical policy.  As regards the default init system we are
+> making a decision which has been requested of us by the people
+> normally responsible (which would be the d-i maintainersI think).
+
+paultag made the request while referencing 6.1.2 as the relevant
+clause.  He isn't involved in d-i.
+
+6.1.2 is supposed to be about resolving "incompatible policies or
+stances".  The particular vote proposed here dictates a specific
+direction for the project, and doesn't actually do anything about init
+system incompatibilities, so its not clear at least to me that 6.1.2
+is appropriate.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 22:33:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 22:33:07 GMT) (full text, mbox, link).

+ +

Message #5494 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Cc: Kurt Roeckx <kurt@roeckx.be>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 22:29:09 +0000
+
+
On Wed, Feb 05, 2014 at 10:05:45PM +0000, Ian Jackson wrote:
+> As regards the default init system we are making a decision which has
+> been requested of us by the people normally responsible (which would
+> be the d-i maintainersI think).
+
+The original request to us was made by Paul Tagliamonte, who I don't
+think is on the d-i team (or if he is I hope he'll forgive me for
+observing he isn't very active).
+
+The only people who might reasonably be described as vaguely current
+maintainers of parts of d-i whom I can immediately find on a quick scan
+of the early parts of this bug are Wouter and myself; Tollef also
+contributed a good deal in the past, and I may have missed one or two.
+But I don't think any of these people have been acting as d-i
+maintainers here.  People like Cyril and Christian, who would be more
+obvious candidates for such a label, have not commented on this bug.
+
+I would have thought that this is more clearly handled under 6.1(2)
+("Decide any technical matter where Developers' jurisdictions overlap").
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 22:33:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 22:33:11 GMT) (full text, mbox, link).

+ +

Message #5499 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 22:32:10 +0000
+
+
On Wed, Feb 05, 2014 at 04:33:57PM +0000, Ian Jackson wrote:
+> I hereby call for votes on my previously proposed resolution and
+> amendments.  All the options require a simple majority.
+
+I vote:
+
+  1. UL   upstart default in jessie, requiring specific init NOT allowed
+  2. DL   systemd default in jessie, requiring specific init NOT allowed
+  3. OL   openrc default in jessie, requiring specific init NOT allowed
+  4. UT   upstart default in jessie, requiring specific init is allowed
+  5. DT   systemd default in jessie, requiring specific init is allowed
+  6. GR   project should decide via GR
+  7. FD   further discussion
+  8. OT   openrc default in jessie, requiring specific init is allowed
+  9. VL   sysvinit default in jessie, requiring specific init NOT allowed
+ 10. VT   sysvinit default in jessie, requiring specific init is allowed
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 22:39:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 22:39:08 GMT) (full text, mbox, link).

+ +

Message #5504 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 23:35:40 +0100
+
+
On Wed, Feb 05, 2014 at 10:05:45PM +0000, Ian Jackson wrote:
+> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
+> > I would really like it that you indicated under which power the
+> > CTTE is making decisions, and the majority requirements that go
+> > with that the options, for all your votes.
+> 
+> Sorry not to give you an explicit heads-up about this resolution.  (It
+> has been proposed in this form for some time now though.)
+
+Please do not assume I have time to read everything.  I don't.  I
+actually think I gave advice about this before which you seem to
+have ignored.
+
+> Anyway, I think as regards T vs L we are chiefly exercising our power
+> to set technical policy.  As regards the default init system we are
+> making a decision which has been requested of us by the people
+> normally responsible (which would be the d-i maintainersI think).
+
+I would like to point out that this was requested by Paul
+Tagliamonte, who as far as I know is not in the d-i team.  I
+didn't see anybody from the d-i team request that you make a
+decision for them, but I might have missed that.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 22:39:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 22:39:11 GMT) (full text, mbox, link).

+ +

Message #5509 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: Michael Gilbert <mgilbert@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 22:38:23 +0000
+
+
On Wed, Feb 05, 2014 at 05:08:35PM -0500, Michael Gilbert wrote:
+> The big question, I think, is whether section 6.3.6 of the
+> constitution has been satisfied.  The project is still clearly working
+> on solutions, but at a slower pace than some may desire.  See this for
+> a recent example:
+> https://lists.debian.org/debian-devel/2014/02/msg00106.html
+
+Various developers certainly continue to work enthusiastically on their
+preferred approaches, but that's not really the same as "efforts to
+resolve [the issue] via consensus".  I would say that a couple of years
+of vehement debate spread across various mailing lists with developers
+settling into increasingly entrenched positions on all sides is rather
+the opposite of movement towards a consensus position.
+
+No doubt this would be for the secretary to adjudicate, though, under
+7.1(3).
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 22:45:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 22:45:08 GMT) (full text, mbox, link).

+ +

Message #5514 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 22:41:13 +0000 (UTC)
+
+
Colin Watson dixit:
+
+>("Decide any technical matter where Developers' jurisdictions overlap").
+
+I think it is not up to the d-i people to decide on the init system
+anyway – especially as not d-i but debootstrap is the canonical way
+to install Debian… and debootstrap goes by whatever ftp-masters put
+into the override files, and whatever package dependencies and meta
+information (such as Essential: yes) there are.
+
+So, “jurisdiction overlaps” seems to fit quite well.
+
+bye,
+//mirabilos (waiting on the decision outcome before proposing a GR)
+-- 
+<Natureshadow> Ach, mach doch was du willst, du hast doch eh immer Recht!
+<mirabilos> jupp ~/.etc/sig………
+<Natureshadow> unfaßbar…
+<Natureshadow> Mit Eszett sogar, unfaßbar!
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 22:45:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 22:45:12 GMT) (full text, mbox, link).

+ +

Message #5519 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 22:43:25 +0000 (UTC)
+
+
Colin Watson dixit:
+
+>> https://lists.debian.org/debian-devel/2014/02/msg00106.html
+>
+>Various developers certainly continue to work enthusiastically on their
+>preferred approaches, but that's not really the same as "efforts to
+>resolve [the issue] via consensus".
+
+But is not diversity some sort of consensus too? Let’s just support
+all of them…
+
+>I would say that a couple of years
+>of vehement debate spread across various mailing lists with developers
+>settling into increasingly entrenched positions on all sides is rather
+>the opposite of movement towards a consensus position.
+
+Eh… if you put it like that… ok…
+
+bye,
+//mirabilos
+-- 
+Support mksh as /bin/sh and RoQA dash NOW!
+‣ src:bash (269 (292) bugs: 0 RC, 188 (204) I&N, 81 (88) M&W, 0 F&P)
+‣ src:dash (89 (106) bugs: 2 RC, 43 (49) I&N, 44 (55) M&W, 0 F&P)
+‣ src:mksh (2 bugs: 0 RC, 0 I&N, 2 M&W, 0 F&P, 1 gift)
+http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 22:57:03 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 22:57:04 GMT) (full text, mbox, link).

+ +

Message #5524 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 17:55:15 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Feb 05, 2014 at 05:28:41PM -0500, Michael Gilbert wrote:
+> paultag made the request while referencing 6.1.2 as the relevant
+> clause.  He isn't involved in d-i.
+
+(Heyya, mgilbert! :) )
+
+I brought it forward under that clause because it made sense at the
+time, but I think the TC is free to consider this a matter of technical
+policy, it' not unreasonable to peg this as a policy issue.
+
+Anyway, I'm not sure where this lies, and I trust the TC to DTRT.
+
+(Just FTR, I really don't want to hold up voting, I think we've all had
+ enough of this and we just need a decision that we can gel around rather
+ then keeping this fight up - we're all pretty bloody after this one.)
+
+Much love,
+  Paul
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
+: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+`. `'`  http://people.debian.org/~paultag
+ `-     http://people.debian.org/~paultag/conduct-statement.txt
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 23:00:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 23:00:09 GMT) (full text, mbox, link).

+ +

Message #5529 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 22:56:56 +0000
+
+
Steve Langasek writes ("Re: Bug#727708: Call for votes on init system resolution"):
+> I am very unhappy to see this CFV in my inbox this morning.
+
+I'm sorry about that.
+
+>  I made it known that I was not satisfied with the set of ballot
+> options, and I was still in the process of drafting language to try
+> to identify a consensus position
+
+You mean your message of "Sat, 1 Feb 2014 15:34:08 -0500", I take it.
+
+That was after the formal proposal had been made.  So it was open to
+you to formally propose an amendment.
+
+In response to that message:
+ * Don and Russ (who didn't like L) said that your proposed S was no
+   better than L.
+ * I (who don't like T) said that your proposed S was like a version
+   of T for me.
+ * I explicitly asked you (at Sun, 2 Feb 2014 09:34:45 +0000)
+   whether you wanted to delay the vote for redrafting, formally
+   propose some version of your S, or something else.
+
+I don't remember seeing a warning in your mail of the 1st of February
+that you would be out of touch and that we should not call for a vote.
+In the absence of such a respose from you, I didn't get the impression
+you were wanting a delay.  Neither I think did anyone else.
+
+The original plan was to call for a vote on Monday.  We delayed this
+for two days because of other amendments following comments.
+
+>  I don't think it's reasonable to give a
+> 48-hour deadline, during a work week, in the body of one message among
+> dozens.  With nothing to call attention to itself, that message sat unread
+> in my box among a pile of others until just now, when it's too late.
+
+The whole of the body text was this:
+
+  Ian Jackson writes ("Bug#727708: package to change init systems"):
+  > I would be happy to do this.  Anyone object to me prefixing
+  >    Therefore, for jessie and later releases:
+  > before the T/L "Software ..." paragraphs ?
+
+  Following another exchange on IRC I have now done this in git, and I
+  hereby propose and accept that amendment (to all versions).  The
+  result is as below.
+
+  I now intend to do the CFV at 16:30 UTC on Wednesday.
+
+  Thanks,
+  Ian.
+
+I'm sorry if that wasn't sufficiently clear.  Perhaps I should have
+changed the Subject too.
+
+> This is substantially the same as Bdale's earlier CFV, which you objected to
+> at the time.
+
+Unlike Bdale's CFV this one:
+ - includes the agreed GR rider;
+ - had a nonzero discussion period; indeed a discusson period of
+   nearly a week, during which any TC member could have ensured that
+   any options of their choice were on the ballot by proposing them;
+   (those two were my procedural objections); and
+ - includes some answer to the coupling question (which was my
+   substantive objection).
+
+> Since this vote will almost certainly result in a resolution passing, I
+> think I will need to begin drafting a follow-up resolution to address this,
+> under 6.1.1.
+
+That's your privilege of course.
+
+Under the circumstances I'm quite prepared to give you a chance to do
+the drafting work you want to do.  Particularly since Kurt has
+objected too.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 23:00:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 23:00:13 GMT) (full text, mbox, link).

+ +

Message #5534 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Kurt Roeckx <kurt@roeckx.be>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 22:58:06 +0000
+
+
Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
+> Please do not assume I have time to read everything.  I don't.  I
+> actually think I gave advice about this before which you seem to
+> have ignored.
+
+I'm sorry if I also missed a mail.
+
+> > Anyway, I think as regards T vs L we are chiefly exercising our power
+> > to set technical policy.  As regards the default init system we are
+> > making a decision which has been requested of us by the people
+> > normally responsible (which would be the d-i maintainersI think).
+> 
+> I would like to point out that this was requested by Paul
+> Tagliamonte, who as far as I know is not in the d-i team.  I
+> didn't see anybody from the d-i team request that you make a
+> decision for them, but I might have missed that.
+
+I assume you would like us to cancel the current vote and address
+these points.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 23:00:23 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 23:00:23 GMT) (full text, mbox, link).

+ +

Message #5539 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve Langasek <vorlon@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 22:59:24 +0000
+
+
Steve Langasek writes ("Bug#727708: Call for votes on init system resolution"):
+> I vote:
+> 
+>  1.  UL   upstart default in jessie, requiring specific init NOT allowed
+>  2.  DL   systemd default in jessie, requiring specific init NOT allowed
+>  3.  FD   further discussion
+
+If you are serious about wanting to discuss the drafting further, you
+should vote FD first....
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 23:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 23:03:04 GMT) (full text, mbox, link).

+ +

Message #5544 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: Colin Watson <cjwatson@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, + Kurt Roeckx <kurt@roeckx.be>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 17:59:53 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Feb 05, 2014 at 10:29:09PM +0000, Colin Watson wrote:
+> The original request to us was made by Paul Tagliamonte, who I don't
+> think is on the d-i team (or if he is I hope he'll forgive me for
+> observing he isn't very active).
+
+FTR - I'm not on the d-i team, and havn't been. No worries :)
+
+> The only people who might reasonably be described as vaguely current
+> maintainers of parts of d-i whom I can immediately find on a quick scan
+> of the early parts of this bug are Wouter and myself; Tollef also
+> contributed a good deal in the past, and I may have missed one or two.
+> But I don't think any of these people have been acting as d-i
+> maintainers here.  People like Cyril and Christian, who would be more
+> obvious candidates for such a label, have not commented on this bug.
+> 
+> I would have thought that this is more clearly handled under 6.1(2)
+> ("Decide any technical matter where Developers' jurisdictions overlap").
+
+I agree here. I think I quoted this in a followup after I figured out my
+initial mail was contentless:
+
+http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=35;att=0;bug=727708
+
+| It is requested that the tech-ctte make a decision as to the init system
+| Debian shall use as the default, and make a judgement call on where the
+| efforts to resolve this situation shall go (patching *around* the lack
+| of systemd, or patching software to use systemd)
+| 
+| I believe this is within the ctte's jurisdiction, given 6.1 section 2.
+
+
+The TC is of course fully within it's rights to tweak under which
+sections it rules.
+
+Cheers,
+  Paul
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
+: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+`. `'`  http://people.debian.org/~paultag
+ `-     http://people.debian.org/~paultag/conduct-statement.txt
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 23:06:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 23:06:05 GMT) (full text, mbox, link).

+ +

Message #5549 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 23:04:19 +0000
+
+
I hereby change my vote:
+
+1.  FD   further discussion
+2.  UL   upstart default in jessie, requiring specific init NOT allowed
+3.  DL   systemd default in jessie, requiring specific init NOT allowed
+4.  OL   openrc default in jessie, requiring specific init NOT allowed
+5.  VL   sysvinit default in jessie, requiring specific init NOT allowed
+6.  GR   project should decide via GR
+7.  UT   upstart default in jessie, requiring specific init is allowed
+8.  OT   openrc default in jessie, requiring specific init is allowed
+9.  VT   sysvinit default in jessie, requiring specific init is allowed
+10. DT   systemd default in jessie, requiring specific init is allowed
+
+The only change is to rank FD first.  I think we should give Steve a
+chance to draft his compromise, and also to satisfy Kurt.
+
+I encourage others to do likewise.  If Steve and one other person
+does this then this vote too will be cancelled.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 23:12:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 23:12:04 GMT) (full text, mbox, link).

+ +

Message #5554 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Kurt Roeckx <kurt@roeckx.be>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 23:09:25 +0000
+
+
Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
+> I'm not sure I like the way this is worded, I would have prefered
+> that you asked me about this before calling for votes.
+
+So assuming that the current vote is cancelled due to 4 people ranking
+FD first: would you care to say what the wording should be ?  I don't
+think any of us care very much about this wording and we all agree
+about the intent, so it shouldn't be controversial.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 23:33:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 23:33:07 GMT) (full text, mbox, link).

+ +

Message #5559 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 00:32:53 +0100
+
+
On Wed, Feb 05, 2014 at 11:09:25PM +0000, Ian Jackson wrote:
+> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
+> > I'm not sure I like the way this is worded, I would have prefered
+> > that you asked me about this before calling for votes.
+> 
+> So assuming that the current vote is cancelled due to 4 people ranking
+> FD first: would you care to say what the wording should be ?  I don't
+> think any of us care very much about this wording and we all agree
+> about the intent, so it shouldn't be controversial.
+
+My biggest concern is that you can only do this if the result of
+the GR is FD.  It should be more explicit that if the option is
+trying to override the ctte but failed to reach the 2:1 majority
+requirement you will re-evaluate the results with the 2:1 majority
+requiremented to override the ctte changed to 1:1 and adopt the
+outcome of that (which might still be FD).
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 23:45:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Philipp Kern <pkern@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 23:45:05 GMT) (full text, mbox, link).

+ +

Message #5564 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Philipp Kern <pkern@debian.org>
+
To: debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 06 Feb 2014 00:40:22 +0100
+
+
On 2014-02-05 17:36, Ian Jackson wrote:
+> Ian Jackson writes ("Bug#727708: Call for votes on init system 
+> resolution"):
+>> I hereby call for votes on my previously proposed resolution and
+>> amendments.  All the options require a simple majority.
+> 
+> I vote:
+> 
+>  1.  UL   upstart default in jessie, requiring specific init NOT 
+> allowed
+>  2.  DL   systemd default in jessie, requiring specific init NOT 
+> allowed
+>  3.  OL   openrc default in jessie, requiring specific init NOT allowed
+>  4.  VL   sysvinit default in jessie, requiring specific init NOT 
+> allowed
+>  5.  GR   project should decide via GR
+>  6.  FD   further discussion
+>  7.  UT   upstart default in jessie, requiring specific init is allowed
+>  8.  OT   openrc default in jessie, requiring specific init is allowed
+>  9.  VT   sysvinit default in jessie, requiring specific init is 
+> allowed
+>  10. DT   systemd default in jessie, requiring specific init is allowed
+
+I'd prefer if CTTE members would actually sign their votes. (But I guess 
+it's up to the secretary.)
+
+Kind regards
+Philipp Kern
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 23:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 23:51:05 GMT) (full text, mbox, link).

+ +

Message #5569 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Philipp Kern <pkern@debian.org>
+
Cc: debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 00:46:32 +0100
+
+
On Thu, Feb 06, 2014 at 12:40:22AM +0100, Philipp Kern wrote:
+> 
+> I'd prefer if CTTE members would actually sign their votes. (But I
+> guess it's up to the secretary.)
+
+I've actually asked that they do that before, but it's not really
+a requirement.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 05 Feb 2014 23:57:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 05 Feb 2014 23:57:10 GMT) (full text, mbox, link).

+ +

Message #5574 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 00:56:18 +0100
+
+
On Thu, Feb 06, 2014 at 12:32:53AM +0100, Kurt Roeckx wrote:
+> On Wed, Feb 05, 2014 at 11:09:25PM +0000, Ian Jackson wrote:
+> > Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
+> > > I'm not sure I like the way this is worded, I would have prefered
+> > > that you asked me about this before calling for votes.
+> > 
+> > So assuming that the current vote is cancelled due to 4 people ranking
+> > FD first: would you care to say what the wording should be ?  I don't
+> > think any of us care very much about this wording and we all agree
+> > about the intent, so it shouldn't be controversial.
+> 
+> My biggest concern is that you can only do this if the result of
+> the GR is FD.
+
+So let me expand on that a little.  Image the following options
+- A: something that doesn't overrule the ctte (1:1)
+- B: something that does overrule the ctte (2:1)
+- FD
+
+If option B would win but is dropped because of the 2:1 majority
+and option A wins instead the project would have made a decision
+and you can't overrule that anymore.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 00:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 00:51:04 GMT) (full text, mbox, link).

+ +

Message #5579 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: Kurt Roeckx <kurt@roeckx.be>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 5 Feb 2014 16:48:54 -0800
+
+
On Thu, 06 Feb 2014, Kurt Roeckx wrote:
+> So let me expand on that a little.  Image the following options
+> - A: something that doesn't overrule the ctte (1:1)
+> - B: something that does overrule the ctte (2:1)
+> - FD
+
+In this case, I don't know A could be anything but 2:1, baring riders
+from the CTTE. If A is technical, it needs the power of the CTTE under
+§4.1.4 which requires 2:1. [I suppose something could be written which
+would fall under the DPL's remit.]
+
+As I understand it, we'd like to make everything be 1:1, and the method
+we're trying is to write a proposal in such a way that it automatically
+enshrouds a non-technical statement by the project in the power of the
+CTTE.
+
+It may be that we can't actually do that, and should instead just have
+an agreement between CTTE members to enact a decision which followed a
+position statement GR under §4.1.5.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+Maybe I did steal your heart
+and I am such a perfect criminal
+that you never noticed
+ -- a softer world #481
+    http://www.asofterworld.com/index.php?id=481
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 01:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 01:21:04 GMT) (full text, mbox, link).

+ +

Message #5584 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 05 Feb 2014 17:20:14 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> The only change is to rank FD first.  I think we should give Steve a
+> chance to draft his compromise, and also to satisfy Kurt.
+
+> I encourage others to do likewise.  If Steve and one other person
+> does this then this vote too will be cancelled.
+
+To say explicitly to avoid making people read my mind: I think Kurt's
+concerns can be dealt with by a separate vote if necessary, so while I
+don't object to cancelling the vote for that, I'm also not sure it's
+necessary.  However, if Steve would like to cancel the vote to have more
+time to draft his compromise, I'm happy to do so.
+
+I therefore intend to change my vote to list FD first iff Steve does the
+same, since I think it's up to him to decide whether he wants to stop,
+rework, and start again, or just continue on since the vote has started
+anyway.
+
+I'm open to being convinced that I have this backwards and should just
+change my vote now.  Also, I'm happy to change my vote if Kurt disagrees
+with the idea that we can fix his concerns in a subsequent vote and feels
+like the vote should not continue.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 01:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 01:33:05 GMT) (full text, mbox, link).

+ +

Message #5589 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 01:28:47 +0000
+
+
Russ Allbery writes ("Bug#727708: Call for votes on init system resolution"):
+> To say explicitly to avoid making people read my mind: I think Kurt's
+> concerns can be dealt with by a separate vote if necessary, so while I
+> don't object to cancelling the vote for that, I'm also not sure it's
+> necessary.
+
+I would prefer to deal with this in the same resolution, as I have
+already said.  I'm sorry that I didn't make sure Kurt was properly
+involved in the drafting.
+
+>  However, if Steve would like to cancel the vote to have more
+> time to draft his compromise, I'm happy to do so.
+
+For me, a desire to cancel the vote would follow directly from being
+upset that the vote had started.  But this whole thread has
+demonstrated to me in many ways that what I think is obvious is far
+from uncontentious.
+
+> I therefore intend to change my vote to list FD first iff Steve does the
+> same, since I think it's up to him to decide whether he wants to stop,
+> rework, and start again, or just continue on since the vote has started
+> anyway.
+> 
+> I'm open to being convinced that I have this backwards and should just
+> change my vote now.
+
+I think Steve's failure to rank FD first is probably a procedural
+error on his part.  I've tried to catch him on IRC but not had a clear
+response yet.
+
+Or perhaps he feels it would be rude to rank FD first to try to vote
+down what he felt was a premature CFV.  But as I have said I think
+that's exactly what FD is for.  FD means precisely "further
+discussion".  So, Steve, if that's what's holding you back please do
+change your vote.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 05:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 05:09:05 GMT) (full text, mbox, link).

+ +

Message #5594 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Colin Watson <cjwatson@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Thu, 6 Feb 2014 15:04:44 +1000
+
+
Hey Colin,
+
+On 29 January 2014 21:13, Colin Watson <cjwatson@debian.org> wrote:
+> On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
+>> >   Q2: Is it OK for packages to depend on a specific init system as
+>> >   pid 1 ?
+>>   Q2a: Is it OK for packages providing init systems to provide other
+>> APIs beyond just the minimum needed for starting/stopping services?
+> We might disagree on the extent, perhaps, but I doubt anyone on the
+> committee would vote against this in its general form;
+
+So looking at the votes today, I would have said that both Ian and
+Andi's original votes are against this (ranking the options which
+allow specifying a dependency on a specific init below further
+discussion), and probably Steve's does too, although I assume that's
+more an objection against the wording.
+
+At least, the impact seems like it is:
+
+ - init systems can provide whatever extra APIs they like
+ - other packages can only use extra APIs if they have a dependency on
+the providing package
+ - packages may not depend on specific init systems
+
+ * therefore packages cannot use the extra APIs
+
+Cheers,
+aj
+
+-- 
+Anthony Towns <aj@erisian.com.au>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 06:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 06:15:05 GMT) (full text, mbox, link).

+ +

Message #5599 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Sébastien Villemot <sebastien@debian.org>, + 727708@bugs.debian.org
+
Cc: Neil McGovern <neilm@debian.org>
+
Subject: Re: Bug#727708: TC resolution revised draft
+
Date: Thu, 6 Feb 2014 08:13:02 +0200
+
+
On Fri, Jan 31, 2014 at 06:06:35PM +0200, Adrian Bunk wrote:
+>...
+> So if for example 4 members of the TC would say "only systemd is an 
+> acceptable choice", and the other 4 members of the TC would say "only 
+> upstart is an acceptable choice", then any result other than "further 
+> discussion" would be caused by a voting error.
+> 
+> And this is not a problem of the Condorcet voting system, this is due to 
+> the explicit statement "There is a quorum of two." in the Constitution.
+
+For the record:
+
+The last paragraph I wrote here is nonsense (and unfortunately noone 
+noticed and corrected my mistake).
+
+The reason why FD would win in this scenario is not the quorum, the 
+reason is that every option that should be taken into consideration
+has to beat FD.
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 06:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 06:30:04 GMT) (full text, mbox, link).

+ +

Message #5604 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 16:27:15 +1000
+
+
On 6 February 2014 11:20, Russ Allbery <rra@debian.org> wrote:
+> I therefore intend to change my vote to list FD first iff Steve does the
+> same, since I think it's up to him to decide whether he wants to stop,
+> rework, and start again, or just continue on since the vote has started
+> anyway.
+
+The votes so far are:
+
+ ian: UL DL OL VL GR *FD* UT OT VT DT
+ andi: UL DL OL VL *FD* GR UT DT OT VT
+
+ steve: UL DL *FD* OL VL UT DT OT=VT GR
+ russ: DT GR DL UT *FD* OT VT UL OL VL
+ colin: UL DL OL UT DT GR *FD* OT VL VT
+ don: DT DL UT UL OT OL VT VL GR *FD*
+
+ ian2: FD UL DL OL VL GR UT OT VT DT
+ andi2: FD UL DL OL VL GR UT DT OT VT
+
+With the initial vote, the following options are eliminated:
+
+ OT, VT  (ian, andi, steve, russ vote these below FD)
+
+With Ian and Andi's changed votes, the following options are eliminated:
+
+ OL, VL (ian2, andi2, steve, russ vote these below FD)
+
+That leaves UL, UT, DL, DT and GR still in the race against FD.
+
+If Steve changes his vote to FD > *, and Russ does likewise as he's
+stated, the vote will be decided as FD again.
+
+If no one changes their vote, then, at present, the comparisons are:
+
+  UL = FD 3:3 (steve, colin, don in favour; russ, ian2, andi2 against)
+  UT = FD 3:3 (russ, colin, don in favour; steve, ian/ian2, andi/andi2 against)
+  DT = FD 3:3 (russ, colin, don in favour; steve, ian/ian2, andi/andi2 against)
+  GR = FD 3:3 (russ, colin, don in favour; steve, ian2, andi/andi2 against)
+
+So those options will be eliminated if Bdale and Keith don't vote, or
+if either Bdale or Keith vote them below FD.
+
+  DL > FD 4:2 (ian2, andi2 against)
+
+That can only be eliminated at this point if both Bdale and Keith vote
+it below FD. It's the only option that had all six original votes
+ranking it above FD.
+
+(As it stands, DL would thus win the vote since all other options are
+eliminated)
+
+As it stands, that also means that Bdale and Keith could collude to
+determine the outcome of the vote amonst {D,U}{L,T} by only voting the
+option they prefer above FD.
+
+GR comparisons are:
+
+  UL > GR 5:1 (russ against)
+  UT = GR 3:3 (steve, colin, don in favour; ian, andi, russ against)
+  DL > GR 6:0
+  DT > GR 4:2 (ian, andi against)
+
+Rankings between remaning actual outcomes is:
+
+  4x  UL > DL > UT > DT  (steve, colin, ian, andi)
+  2x  DT > DL > UT > UL  (russ, don)
+
+So that's
+
+   UL > DL > DT  4:2
+   UL > UT > DT  4:2
+   DL > UT  6:0
+
+It seems to me that if this ballot fails to FD, any future ballots
+should skip options:
+
+  OT, VT  (insufficient support over FD)
+  OL, VL  (at least 6 of 8 committee members prefer UL and DL over
+these options)
+
+It seems unlikely that there's any actual support for UT, either.
+
+
+Cheers,
+aj
+
+-- 
+Anthony Towns <aj@erisian.com.au>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 06:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 06:33:04 GMT) (full text, mbox, link).

+ +

Message #5609 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Don Armstrong <don@debian.org>
+
Cc: 727708@bugs.debian.org, Kurt Roeckx <kurt@roeckx.be>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 05 Feb 2014 22:31:24 -0800
+
+
Don Armstrong <don@debian.org> writes:
+> On Thu, 06 Feb 2014, Kurt Roeckx wrote:
+
+>> So let me expand on that a little.  Image the following options
+>> - A: something that doesn't overrule the ctte (1:1)
+>> - B: something that does overrule the ctte (2:1)
+>> - FD
+
+> In this case, I don't know A could be anything but 2:1, baring riders
+> from the CTTE. If A is technical, it needs the power of the CTTE under
+> §4.1.4 which requires 2:1. [I suppose something could be written which
+> would fall under the DPL's remit.]
+
+> As I understand it, we'd like to make everything be 1:1, and the method
+> we're trying is to write a proposal in such a way that it automatically
+> enshrouds a non-technical statement by the project in the power of the
+> CTTE.
+
+> It may be that we can't actually do that, and should instead just have
+> an agreement between CTTE members to enact a decision which followed a
+> position statement GR under §4.1.5.
+
+I think what we're trying to say looks something like this:
+
+    If the project holds a GR vote on the topic of the default init
+    system, the winning option of that vote replaces this text in its
+    entirety and becomes the decision of the Technical Committee.  The
+    winning option of the GR vote for this purpose will be decided
+    following the normal rules for deciding the outcome of a General
+    Resolution, with the exception that the 2:1 majority normally required
+    to overule the Technical Committee will not be taken into account.
+
+I think this works, although it does create the possibility of a rather
+odd situation, and I'm not quite sure how it would work procedurally.
+Suppose that the project votes on a GR with the following imaginary
+options:
+
+    A. The default init system for jessie will be [whatever the TC picked]
+    B. The default init system for jessie will be a single /etc/rc script
+
+and suppose that B beats A beats FD, but B does not beat FD by a 2:1
+majority.
+
+The result of that GR is A.  However, the choice picked by the above
+algorithm is B.  So B becomes the TC decision, despite the fact that A is
+the result of the GR, and A, despite winning, now constitutes a TC
+override and fails to go into effect.  Unless you think of A happening
+"before" the TC decision changes, at which point the TC can no longer
+override it?
+
+It's weird.
+
+One thing that would make it less weird is if the GR phrased whatever
+option concurs with the TC as saying that the project upholds the TC
+decision, rather than stating what that decision is.  Then, in the
+scenario given above, A and B become the same as soon as the TC decision
+is changed by the vote, and everything stays consistent.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 06:39:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 06:39:10 GMT) (full text, mbox, link).

+ +

Message #5614 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Anthony Towns <aj@erisian.com.au>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Wed, 05 Feb 2014 22:34:47 -0800
+
+
Anthony Towns <aj@erisian.com.au> writes:
+
+> GR comparisons are:
+
+>   UL > GR 5:1 (russ against)
+>   UT = GR 3:3 (steve, colin, don in favour; ian, andi, russ against)
+>   DL > GR 6:0
+
+For whatever it's worth, I think this line is wrong.  I voted GR above DL.
+
+>   DT > GR 4:2 (ian, andi against)
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 06:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Lucas Nussbaum <leader@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 06:45:04 GMT) (full text, mbox, link).

+ +

Message #5619 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Lucas Nussbaum <leader@debian.org>
+
To: Thorsten Glaser <tg@mirbsd.de>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 07:42:41 +0100
+
+
[Message part 1 (text/plain, inline)]
+
On 05/02/14 at 22:41 +0000, Thorsten Glaser wrote:
+> Colin Watson dixit:
+> 
+> >("Decide any technical matter where Developers' jurisdictions overlap").
+> 
+> I think it is not up to the d-i people to decide on the init system
+> anyway – especially as not d-i but debootstrap is the canonical way
+> to install Debian… and debootstrap goes by whatever ftp-masters put
+> into the override files, and whatever package dependencies and meta
+> information (such as Essential: yes) there are.
+> 
+> So, “jurisdiction overlaps” seems to fit quite well.
+
+As far as I remember, I don't think that any of the d-i maintainers,
+debootstrap maintainers, ftpmasters, or sysvinit maintainers have
+claimed that it was their sole jurisdiction to decide on the default
+init system. So I agree that there's jurisdiction overlap.
+
+Also, given that:
+
+  The Project Leader may:
+    4. Make any decision for whom noone else has responsibility.
+
+and:
+
+  The Project Leader may:
+    1. Appoint Delegates or delegate decisions to the Technical
+    Committee.
+
+      The Leader may define an area of ongoing responsibility or a
+      specific decision and hand it over to another Developer or to the
+      Technical Committee.
+
+      Once a particular decision has been delegated and made the Project
+      Leader may not withdraw that delegation; however, they may
+      withdraw an ongoing delegation of particular area of
+      responsibility.
+
+I would be very happy, if felt necessary by the Secretary, to delegate
+that decision to the Technical Committee.
+
+Lucas
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 07:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 07:03:04 GMT) (full text, mbox, link).

+ +

Message #5624 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Wed, 5 Feb 2014 23:02:19 -0800
+
+
Anthony Towns wrote:
+> On 29 January 2014 21:13, Colin Watson <cjwatson@debian.org> wrote:
+> > On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
+> >> >   Q2: Is it OK for packages to depend on a specific init system as
+> >> >   pid 1 ?
+> >>   Q2a: Is it OK for packages providing init systems to provide other
+> >> APIs beyond just the minimum needed for starting/stopping services?
+> > We might disagree on the extent, perhaps, but I doubt anyone on the
+> > committee would vote against this in its general form;
+> 
+> So looking at the votes today, I would have said that both Ian and
+> Andi's original votes are against this (ranking the options which
+> allow specifying a dependency on a specific init below further
+> discussion), and probably Steve's does too, although I assume that's
+> more an objection against the wording.
+> 
+> At least, the impact seems like it is:
+> 
+>  - init systems can provide whatever extra APIs they like
+>  - other packages can only use extra APIs if they have a dependency on
+> the providing package
+>  - packages may not depend on specific init systems
+> 
+>  * therefore packages cannot use the extra APIs
+
+I agree with your conclusion on the practical effect here.
+
+I'm also amused that exactly the same logic readily applies at the next
+level down, to an init system making use of APIs and functionality that
+Linux has and other systems do not.  In both cases, the question is the
+same: least common denominator, or actually using available
+functionality?
+
+(To forestall the obvious objection: "optional" is the same as "least
+common denominator", in that it effectively prevents *relying* on that
+functionality, and thus forces the creation of a
+least-common-denominator fallback, which everything higher in the stack
+must then cope with.)
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 07:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 07:15:05 GMT) (full text, mbox, link).

+ +

Message #5629 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 17:12:27 +1000
+
+
On 6 February 2014 16:27, Anthony Towns <aj@erisian.com.au> wrote:
+> Rankings between remaning actual outcomes is:
+>   4x  UL > DL > UT > DT  (steve, colin, ian, andi)
+>   2x  DT > DL > UT > UL  (russ, don)
+
+Ah! I thought there was something to add here
+
+The above votes divide neatly into upstart v systemd camps. Given
+Bdale and Keith have expressed a preference for systemd previously,
+presumably they fall onto the systemd side; so will vote presumably
+vote either DT or DL above the other options, and will vote DL > UL,
+and DT > UT.
+
+In that case,
+
+  DL > UT    6:2, 7:1 or 8:0
+
+  DL >= DT  6:2, 5:3 or 4:4
+  UL >= UT  6:2, 5:3 or 4:4
+  UL >= DT  6:2, 5:3 or 4:4
+
+  DT = UT  4:4
+  DL = UL  4:4
+
+UT would thus have no chance of being in the Schwartz set (it doesn't
+beat anything, and is beaten by DL).
+
+Possible outcomes are then:
+
+  DL >= DT  6:2, 5:3 or 4:4
+  UL >= DT  6:2, 5:3 or 4:4
+  DL = UL    4:4
+
+ie:
+ - if either Bdale or Keith vote DT below UL or DL, DT loses, and the
+result is determined by Bdale's casting vote between UL and DL
+ - otherwise, the result is determined by Bdale's casting vote amongst
+UL, DL and DT
+
+Also, Russ correctly points out:
+> >   DL > GR 6:0
+> For whatever it's worth, I think this line is wrong.  I voted GR above DL.
+
+Hopefully there wasn't much else wrong with the analysis. (Having 10
+options on a vote that's supposed to have its results tallied by hand
+seems nuts to me...)
+
+Cheers,
+aj
+
+-- 
+Anthony Towns <aj@erisian.com.au>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 09:21:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Didier 'OdyX' Raboud" <odyx@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 09:21:10 GMT) (full text, mbox, link).

+ +

Message #5634 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Didier 'OdyX' Raboud" <odyx@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
+
Date: Thu, 06 Feb 2014 10:20:02 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Sorry for yet-another-mail on that (long-lasting) bug, but I feel it's 
+important; so feel free to dismiss it if it isn't bringing to the 
+conversation.
+
+Le jeudi, 6 février 2014, 16.27:15 Anthony Towns a écrit :
+> Rankings between remaning actual outcomes is:
+> 
+>   4x  UL > DL > UT > DT  (steve, colin, ian, andi)
+>   2x  DT > DL > UT > UL  (russ, don)
+> 
+> So that's
+> 
+>    UL > DL > DT  4:2
+>    UL > UT > DT  4:2
+>    DL > UT  6:0
+
+I'm quite puzzled by this (partial) result, generally ranking the L 
+variants over the T's. I think letting any L variant win would create 
+quite a precedent on what software is "allowed in Debian". "Software" 
+doesn't imply "package" and is loosely defined, the same goes for 
+"degraded operation". Is "KDE" a software, or are all of its independent 
+parts "softwares"? Would "failure to suspend under OpenRC" be an 
+acceptable degraded operation of the whole "KDE" or only of its 
+upower/Solid/whatever component?
+
+L really reads to me like a way to enforce support for all init systems 
+alike (thereby ensuring that the default init gets the same [bad] 
+support) on maintainers and I feel it's too coercitive.
+
+On the other hand, T apparently brings in the fear of archive 
+fragmentation by allowing the various init islands to develop on their 
+own.
+
+Now, I think there is currently a shared agreement in Debian that
+
+    "all Debian packages (unless there's a good reason) should run on
+     sysvinit + Linux + amd64 , support outside that is best-effort"
+
+Now, I think this "default init" decision's purpose is to change the 
+above agreement by replacing the "syslinux" in the above sentence by one 
+of the contenders. Both the T and L riders purposedly don't say anything 
+about the default init, and I think that's wrong:
+
+* T would permit islands outside of the default init (while I think that
+  some prefer it because it allows the "default init island" to be
+  technically sane)
+* L would enforce that any software can run on all inits (failure to
+  work on one is equivalent to requiring any of the other ones, henc
+  failing the requirement of L)
+
+The "common agreement" above stood until packages started to depend on 
+systemd, which in the end, lead to the opening of this bug. I think the 
+technical committee resolution on this issue should focus on outlining 
+what the "new deal" should be, without stepping into defining what set 
+of init systems the software shipped by Debian should or must support: 
+the resolution should be limited to deciding what the new "default init" 
+will be. Now, if there are concerns of eventual bad faith from the 
+maintainers, the resolution could include something outlining the 
+boundaries of the common agreement such as (which I think is the current 
+consensus):
+
+    "All but specific packages are expected to work with the default
+     init system. However, where feasible, packages should interoperate
+     with all init systems; maintainers are encouraged to accept
+     technically sound patches to enable interoperation, even if it
+     results in degraded operation while running under the init system
+     the patch enables interoperation with."
+
+That (or any consensual phrasing along these lines) would completely 
+replace both the T and L riders and be part of the resolution deciding 
+which init system will be the default. I think that would vastly help 
+making the decision largely understandable and consensual, where I'm 
+afraid that any T or L variant would significantly unplease large sets 
+of maintainers.
+
+Thanks for considering, cheers,
+
+Didier
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 10:27:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Rick Yorgason <rick@firefang.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 10:27:08 GMT) (full text, mbox, link).

+ +

Message #5639 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Rick Yorgason <rick@firefang.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Call for votes on init system resolution
+
Date: Thu, 06 Feb 2014 05:16:57 -0500
+
+
This is silly. It's pretty clear that everybody made up their minds a 
+long time ago, and no matter how the resolution is worded, it will come 
+down systemd > upstart 5:4. The only question is on how to guide 
+maintainers once the init system is changed.
+
+-Rick-
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 10:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 10:51:04 GMT) (full text, mbox, link).

+ +

Message #5644 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler + (was: Re: Call for votes on init system resolution)
+
Date: Thu, 6 Feb 2014 10:50:05 +0000
+
+
On Thu, Feb 06, 2014 at 10:20:02AM +0100, Didier 'OdyX' Raboud wrote:
+> L really reads to me like a way to enforce support for all init systems 
+> alike (thereby ensuring that the default init gets the same [bad] 
+> support) on maintainers and I feel it's too coercitive.
+
+I don't interpret L as meaning that everything must support "all" init
+systems, certainly not "alike" (indeed the text of that option is
+explicit that it isn't necessarily alike).  Rather, I interpret it as
+saying that software-outside-init must be flexible enough to cope with
+that possibility, and degrade sensibly to a lowest common subset of init
+system features (IOW in practice, needs to keep working if sysvinit is
+pid 1).  Actual support for things beyond that minimum will require
+people who care about various init systems to step up and implement it.
+
+> * L would enforce that any software can run on all inits (failure to
+>   work on one is equivalent to requiring any of the other ones, henc
+>   failing the requirement of L)
+
+That's not how I interpret it.  "A specific init system" is in the
+singular.  I'm not worried that we'll end up with cases where
+software-outside-init somehow manages to work with two init systems but
+not the others; working with more than one indicates the basic
+flexibility that I want to see, and the rest is up to developers who
+care about init systems.
+
+>     "All but specific packages are expected to work with the default
+>      init system. However, where feasible, packages should interoperate
+>      with all init systems; maintainers are encouraged to accept
+>      technically sound patches to enable interoperation, even if it
+>      results in degraded operation while running under the init system
+>      the patch enables interoperation with."
+
+Doesn't that just move the question to what the "specific packages" are,
+the scope of which is the core of the difference between T and L anyway?
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 10:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 10:54:04 GMT) (full text, mbox, link).

+ +

Message #5649 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Anthony Towns <aj@erisian.com.au>, + 727708@bugs.debian.org
+
Cc: Colin Watson <cjwatson@debian.org>
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Thu, 6 Feb 2014 10:51:04 +0000
+
+
Anthony Towns writes ("Bug#727708: call for votes on default Linux init system for jessie"):
+> On 29 January 2014 21:13, Colin Watson <cjwatson@debian.org> wrote:
+> > On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
+> >> >   Q2: Is it OK for packages to depend on a specific init system as
+> >> >   pid 1 ?
+> >>   Q2a: Is it OK for packages providing init systems to provide other
+> >> APIs beyond just the minimum needed for starting/stopping services?
+> > We might disagree on the extent, perhaps, but I doubt anyone on the
+> > committee would vote against this in its general form;
+
+This just goes to show how the exact form of words used can be
+confusing or misleading.
+
+> So looking at the votes today, I would have said that both Ian and
+> Andi's original votes are against this (ranking the options which
+> allow specifying a dependency on a specific init below further
+> discussion), and probably Steve's does too, although I assume that's
+> more an objection against the wording.
+> 
+> At least, the impact seems like it is:
+> 
+>  - init systems can provide whatever extra APIs they like
+>  - other packages can only use extra APIs if they have a dependency on
+> the providing package
+>  - packages may not depend on specific init systems
+> 
+>  * therefore packages cannot use the extra APIs
+
+(In the L options:) Yes, packages which aren't part of the init system
+aren't allowed to depend on those extra APIs.
+
+But packages which _are_ part of the init system are so allowed.
+(Think, for example, management guis or addons for a particular init
+system.)  Answering "no" to the question Q2a above would have
+forbidden that.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 10:57:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 10:57:10 GMT) (full text, mbox, link).

+ +

Message #5654 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 10:53:47 +0000
+
+
On Wed, Feb 05, 2014 at 10:43:25PM +0000, Thorsten Glaser wrote:
+> Colin Watson dixit:
+> >Various developers certainly continue to work enthusiastically on their
+> >preferred approaches, but that's not really the same as "efforts to
+> >resolve [the issue] via consensus".
+> 
+> But is not diversity some sort of consensus too? Let’s just support
+> all of them…
+
+It is not clear to me that there is even consensus for diversity!
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 10:57:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 10:57:13 GMT) (full text, mbox, link).

+ +

Message #5659 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Ansgar Burchardt <ansgar@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Additional CTTE Drafting Meeting useful?
+
Date: Thu, 6 Feb 2014 10:54:56 +0000
+
+
Ansgar Burchardt writes ("Re: Additional CTTE Drafting Meeting useful?"):
+> In this case I suggest to decide just the question of the default init
+> system on Linux architectures first and address further details later if
+> no consensus can be found elsewhere. Finding the correct wording then
+> should be easier.
+
+I strongly object to this approach for the reasons I have given
+already.
+
+If I am given the opportunity to do so, if such a resolution is
+proposed I will always propose amendments to settle the T vs L
+question.
+
+If I am not given the opportunity to do so, that would be because
+someone proposes a set of options which do not answer the tying
+question, and immediately calls for a vote.
+
+Under the circumstances that would be IMO a clear breach of process.
+I hope that now that I have made this perfectly clear, that this will
+not happen.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 10:57:16 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 10:57:16 GMT) (full text, mbox, link).

+ +

Message #5664 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
+
Date: Thu, 6 Feb 2014 10:55:56 +0000
+
+
Colin Watson writes ("Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)"):
+> On Thu, Feb 06, 2014 at 10:20:02AM +0100, Didier 'OdyX' Raboud wrote:
+> > L really reads to me like a way to enforce support for all init systems 
+> > alike (thereby ensuring that the default init gets the same [bad] 
+> > support) on maintainers and I feel it's too coercitive.
+> 
+> I don't interpret L as meaning that everything must support "all" init
+> systems, certainly not "alike" (indeed the text of that option is
+> explicit that it isn't necessarily alike).  Rather, I interpret it as
+> saying that software-outside-init must be flexible enough to cope with
+> that possibility, and degrade sensibly to a lowest common subset of init
+> system features (IOW in practice, needs to keep working if sysvinit is
+> pid 1).  Actual support for things beyond that minimum will require
+> people who care about various init systems to step up and implement it.
+
+Precisely.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 11:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 11:12:05 GMT) (full text, mbox, link).

+ +

Message #5669 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 11:09:44 +0000
+
+
On Thu, Feb 06, 2014 at 07:42:41AM +0100, Lucas Nussbaum wrote:
+> On 05/02/14 at 22:41 +0000, Thorsten Glaser wrote:
+> > I think it is not up to the d-i people to decide on the init system
+> > anyway – especially as not d-i but debootstrap is the canonical way
+> > to install Debian… and debootstrap goes by whatever ftp-masters put
+> > into the override files, and whatever package dependencies and meta
+> > information (such as Essential: yes) there are.
+
+The latter's true, yes, but this is a distinction without a difference.
+debootstrap has been maintained by the d-i team since 1.0.0 in 2007.
+
+> > So, “jurisdiction overlaps” seems to fit quite well.
+> 
+> As far as I remember, I don't think that any of the d-i maintainers,
+> debootstrap maintainers, ftpmasters, or sysvinit maintainers have
+> claimed that it was their sole jurisdiction to decide on the default
+> init system. So I agree that there's jurisdiction overlap.
+
+Right.  A simple thought experiment to get a first approximation of
+jurisdiction in Debian is to look at who might be able to put a given
+change into effect as part of their ordinary work, changing only the
+things they're generally agreed to "own".  Using that we get at least
+this result:
+
+ * ftpmaster could change Priority fields to cause a different init
+   system to be the default
+
+ * the debootstrap maintainers / d-i team could decide to act at
+   variance with the Priority fields and install a different init
+   system; there's plenty of precedent for not going just by Priority,
+   and we might reasonably want it to have options to do so in this case
+   anyway
+
+ * the sysvinit maintainers could decide to throw in the towel and make
+   sysvinit a transitional package for some other init system
+   [hey, I didn't say all these options were realistic]
+
+ * any boot loader maintainer could decide to tweak their default
+   configuration to pass init=something (indeed for a while I thought
+   that that might well end up being the implementation mechanism for
+   the result of this vote, although I've since been cluebatted
+   otherwise)
+
+ * the maintainers of a sufficiently widely-used package could cause it
+   to depend on a given init system
+
+So, yes.  I would be interested in whether the Secretary agrees whether
+this is jurisdictional overlap.  If the answer is no, then it would be
+very helpful to have examples of what would be so that we can act
+accordingly in the future.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 11:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 11:21:04 GMT) (full text, mbox, link).

+ +

Message #5674 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Thu, 6 Feb 2014 11:18:46 +0000
+
+
On Thu, Feb 06, 2014 at 12:05:05PM +0100, Ansgar Burchardt wrote:
+> On 02/06/2014 11:50, Colin Watson wrote:
+> > I don't interpret L as meaning that everything must support "all" init
+> > systems, certainly not "alike" (indeed the text of that option is
+> > explicit that it isn't necessarily alike).  Rather, I interpret it as
+> > saying that software-outside-init must be flexible enough to cope with
+> > that possibility, and degrade sensibly to a lowest common subset of init
+> > system features (IOW in practice, needs to keep working if sysvinit is
+> > pid 1).  Actual support for things beyond that minimum will require
+> > people who care about various init systems to step up and implement it.
+> 
+> What does this mean in the concrete example that lead to the ctte bug?
+> That is:
+> 
+> Provided logind is only provided by systemd (the current situation). May
+> GNOME depend on logind?
+
+This is not quite the current situation.  Neither systemd nor
+systemd-shim Provides: logind in the sense of the package relationship
+field right now, but both could do so.  (In practice it looks as though
+it ought to be a virtual package name with an API version embedded in
+it; this is not a new or controversial technique elsewhere.)
+
+My interpretation of L is that GNOME may depend on logind (or logind-208
+or whatever) as long as that dependency is declared such that another
+init system can provide it.  I appreciate that there is the abstract
+question of what happens if no init system other than systemd actually
+steps up to do so; in practice I don't think this is a plausible outcome
+and so I don't plan to spend mental energy on it.
+
+My interpretation of T is that GNOME may depend directly on systemd or
+on related real packages, although it is encouraged to take some
+approach more like the above instead.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 11:27:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 11:27:09 GMT) (full text, mbox, link).

+ +

Message #5679 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Thu, 6 Feb 2014 11:23:38 +0000
+
+
(resend with the correct BTS email address)
+
+Ansgar Burchardt writes ("Re: Bug#727708: Both T and L are wrong, plea for something simpler"):
+> What does this mean in the concrete example that lead to the ctte bug?
+> That is:
+> 
+> Provided logind is only provided by systemd (the current situation). May
+> GNOME depend on logind?
+
+I think the conclusion is that it may not.  (This is, after all, the
+heart of the problem.)
+
+> If not, do you plan to override the GNOME maintainers with this decision?
+
+That would be a matter for a further TC resolution.  At this stage we
+are setting policy.
+
+Ian.
+
+PS: Please make sure you direct your messages to the bug, not directly
+to the TC list.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 12:00:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 12:00:10 GMT) (full text, mbox, link).

+ +

Message #5684 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Cc: Don Armstrong <don@debian.org>, + Kurt Roeckx <kurt@roeckx.be>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 11:56:35 +0000
+
+
Russ Allbery writes ("Bug#727708: Call for votes on init system resolution"):
+> I think what we're trying to say looks something like this:
+...
+> The result of that GR is A.  However, the choice picked by the above
+> algorithm is B.  So B becomes the TC decision, despite the fact that A is
+> the result of the GR, and A, despite winning, now constitutes a TC
+> override and fails to go into effect.  Unless you think of A happening
+> "before" the TC decision changes, at which point the TC can no longer
+> override it?
+
+This is the wrong way to look at it.
+
+The right way to look at it is this: exercising this "override" this
+must be achieved by using options which constitutionally require only
+a 1:1 majority.
+
+Helpfully, 4.1.5 permits this.
+
+How about this:
+
+  If the project passes by a General Resolution, a "position statement
+  about issues of the day", on the subject of init systems, the views
+  expressed in that position statement entirely replace the substance
+  of this TC resolution; the TC hereby adopts any such position
+  statement as its own decision.
+
+  Such a position statement could, for example, use these words:
+
+     The Project requests that the TC reconsider, and requests that
+     the TC would instead decide as follows:
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 12:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 12:09:04 GMT) (full text, mbox, link).

+ +

Message #5689 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 12:06:01 +0000
+
+
Ian Jackson writes ("Bug#727708: Call for votes on init system resolution"):
+> Steve Langasek writes ("Bug#727708: Call for votes on init system resolution"):
+> > I vote:
+> > 
+> >  1.  UL   upstart default in jessie, requiring specific init NOT allowed
+> >  2.  DL   systemd default in jessie, requiring specific init NOT allowed
+> >  3.  FD   further discussion
+> 
+> If you are serious about wanting to discuss the drafting further, you
+> should vote FD first....
+
+Also, if you are serious about wanting to do additional drafting work,
+I think you need to manage a lower latency and greater bandwidth of
+interaction with the process.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 12:18:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 12:18:09 GMT) (full text, mbox, link).

+ +

Message #5694 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Thu, 6 Feb 2014 04:15:16 -0800
+
+
Ian Jackson wrote:
+> Anthony Towns writes ("Bug#727708: call for votes on default Linux init system for jessie"):
+> > So looking at the votes today, I would have said that both Ian and
+> > Andi's original votes are against this (ranking the options which
+> > allow specifying a dependency on a specific init below further
+> > discussion), and probably Steve's does too, although I assume that's
+> > more an objection against the wording.
+> > 
+> > At least, the impact seems like it is:
+> > 
+> >  - init systems can provide whatever extra APIs they like
+> >  - other packages can only use extra APIs if they have a dependency on
+> > the providing package
+> >  - packages may not depend on specific init systems
+> > 
+> >  * therefore packages cannot use the extra APIs
+> 
+> (In the L options:) Yes, packages which aren't part of the init system
+> aren't allowed to depend on those extra APIs.
+> 
+> But packages which _are_ part of the init system are so allowed.
+> (Think, for example, management guis or addons for a particular init
+> system.)  Answering "no" to the question Q2a above would have
+> forbidden that.
+
+That is a very interesting clarification, and not one that seems at all
+obvious from the text of 'L'.  'L' talks about "Software outside of an init
+system's implementation", which does not seem like it would extend to
+"management guis or addons".
+
+So, for instance, GNOME Logs, a new upstream project specifically
+designed to browse the systemd journal, could by the clarification above
+be considered part of the init system, and thus can depend on it?
+
+If so, I would be very interested in further clarifications regarding
+what it takes to be considered part of an init system.
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 12:24:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 12:24:05 GMT) (full text, mbox, link).

+ +

Message #5699 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Thu, 06 Feb 2014 13:20:11 +0100
+
+
Le jeudi 06 février 2014 à 11:18 +0000, Colin Watson a écrit : 
+> My interpretation of L is that GNOME may depend on logind (or logind-208
+> or whatever) as long as that dependency is declared such that another
+> init system can provide it.  I appreciate that there is the abstract
+> question of what happens if no init system other than systemd actually
+> steps up to do so; in practice I don't think this is a plausible outcome
+> and so I don't plan to spend mental energy on it.
+
+This is a very plausible outcome, because the Ubuntu version of the
+logind solution is just a fork of systemd 204, and it sounds complicated
+to maintain both versions of systemd in Debian.
+
+Cheers,
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 12:33:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 12:33:13 GMT) (full text, mbox, link).

+ +

Message #5704 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Josh Triplett <josh@joshtriplett.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Thu, 6 Feb 2014 12:28:36 +0000
+
+
Josh Triplett writes ("Bug#727708: call for votes on default Linux init system for jessie"):
+> That is a very interesting clarification, and not one that seems at all
+> obvious from the text of 'L'.  'L' talks about "Software outside of an init
+> system's implementation", which does not seem like it would extend to
+> "management guis or addons".
+
+I think it depends what you think of as an init system's
+"implementation".  I would include the utilities you use to manage it.
+
+> So, for instance, GNOME Logs, a new upstream project specifically
+> designed to browse the systemd journal, could by the clarification above
+> be considered part of the init system, and thus can depend on it?
+
+I haven't looked at that in detail.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 12:33:16 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Didier 'OdyX' Raboud" <odyx@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 12:33:16 GMT) (full text, mbox, link).

+ +

Message #5709 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Didier 'OdyX' Raboud" <odyx@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
+
Date: Thu, 06 Feb 2014 13:30:25 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Le jeudi, 6 février 2014, 10.50:05 Colin Watson a écrit :
+> On Thu, Feb 06, 2014 at 10:20:02AM +0100, Didier 'OdyX' Raboud wrote:
+> > L really reads to me like a way to enforce support for all init
+> > systems alike (thereby ensuring that the default init gets the same
+> > [bad] support) on maintainers and I feel it's too coercitive.
+> 
+> I don't interpret L as meaning that everything must support "all" init
+> systems, certainly not "alike" (indeed the text of that option is
+> explicit that it isn't necessarily alike).  Rather, I interpret it as
+> saying that software-outside-init must be flexible enough to cope
+> with that possibility, and degrade sensibly to a lowest common subset
+> of init system features (IOW in practice, needs to keep working if
+> sysvinit is pid 1).
+
+L doesn't say anything about lowest common subset, it says "may not 
+require a specific init system", which is different.
+
+> > * L would enforce that any software can run on all inits (failure to
+> >   work on one is equivalent to requiring any of the other ones, henc
+> >   failing the requirement of L)
+> 
+> That's not how I interpret it.  "A specific init system" is in the
+> singular.
+
+In the case of interpreting L with "specific init" being singular, then 
+a package requiring any of OpenRC and systemd would fit L as it doesn't 
+require a specific init, but any within a set. If upstart would be taken 
+as default, that's certainly not the intent of L, right?
+
+> I'm not worried that we'll end up with cases where software-outside-
+> init somehow manages to work with two init systems but not the others;
+> working with more than one indicates the basic flexibility that I want
+> to see, and the rest is up to developers who care about init systems.
+
+That's not what the L option says, again. Let's take logind as example 
+(instead of inventing pseudo-test-cases). There are two views:
+
+* logind is considered part of "systemd to be pid 1". L says you can't 
+depend on any init being pid 1; L therefore imposes the maintainers of 
+all software using logind to maintain interfaces to be working on non-
+systemd-inits (runtime-detection of [deprecated] ConsoleKit !?)
+* logind is not considered part of "systemd to be pid 1" (the existence 
+of a second implementation seems to suggest that), then software can 
+depend on having logind available. How the "logind interface" is defined 
+is mostly a matter of having maintainers of the various providers agree 
+on virtual package names. That said, this view would make "systemd-
+logind" fall under L, imposing on its maintainers to make it work on 
+non-systemd inits.
+
+I think L is putting the burden of maintenance wrongly in these two 
+cases (on all consumers of logind or on the systemd-logind maintainers).
+
+> >     "All but specific packages are expected to work with the default
+> >      init system. However, where feasible, packages should
+> >      interoperate
+> >      with all init systems; maintainers are encouraged to accept
+> >      technically sound patches to enable interoperation, even if it
+> >      results in degraded operation while running under the init
+> >      system
+> >      the patch enables interoperation with."
+> 
+> Doesn't that just move the question to what the "specific packages"
+> are, the scope of which is the core of the difference between T and L
+> anyway?
+
+Not in my view. It lets the individual maintainers decide whether their 
+package is a sufficiently specific case. It also reinforces the role of 
+the "default" init with regards to other non-defaults, explicitly ruling 
+the "init islands" out. Any disagreement on the "specificity" can 
+subsequently be referred to the TC, of course.
+
+What I tried to express in my earlier mail is that I think both T and L 
+are simultaneously too vague and too specific: they both try to tell the 
+Gnome maintainers (and others, of course) what they should or must do 
+with regards to logind-being-tied-to-systemd, without explicitely 
+writing it (too specific), while failing at making explicit that the 
+default init should be supported (too vague).
+
+I also think they are both spelled in a way that assumes that 
+maintainers would act in bad faith with regards to either upstart or 
+systemd support in the cases where each wouldn't be taken as default.
+
+Finally, I have hard time seeing under which powers could L be decided 
+by the tech-ctte: the policy team hasn't worked on that (§6.1.1), there 
+is no juridiction overlap that I could see (nor a disagreement about the 
+matter, §6.1.2), and it's not formulated as an overrule (§6.1.4) or an 
+advice (§6.1.5). The only relevant bit would be §6.1.3 as Paul 
+specifically asked for in <20131025184344.GB4599@helios.pault.ag>:
+
+> (…) and make a judgement call on where the efforts to resolve this
+> situation shall go (patching *around* the lack of systemd, or patching
+> software to use systemd)
+
+Paul's request is about a "judgement call on where the efforts (…) shall 
+go", not about setting technical policy. L, in its current state is too 
+far-reaching in forbidding package relationships while the policy team 
+hasn't worked on the matter yet.
+
+Therefore, I stand by my objection: both T and L should be dropped from 
+the tech-ctte resolution. A text reminding that support for the default 
+init is expected wouldn't hurt though…
+
+Cheers.
+OdyX
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 14:18:10 GMT) (full text, mbox, link).

+ +

Message #5712 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: sin <sin@2f30.org>
+
To: dev@suckless.org
+
Subject: [dev] Announcing sinit - the suckless init
+
Date: Thu, 6 Feb 2014 12:32:59 +0000
+
+
Hi all,
+
+As part of experimenting with a toy distro I wanted to get rid of
+busybox's init, so I hacked together sinit[1].  sinit is based on Strake's
+init[2].
+
+It is currently controlled via a FIFO.  It supports only two commands (reboot
+and poweroff).
+
+It follows the classic style of config.def.h and it should work with any
+init scripts.  I've been testing it with my init scripts[3].
+
+Let me know what you guys think, I am looking forward to use this with sta.li.
+
+Thanks,
+sin
+
+[1] http://git.2f30.org/sinit
+[2] https://github.com/strake/init
+[3] http://git.2f30.org/fs/
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 14:30:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 14:30:15 GMT) (full text, mbox, link).

+ +

Message #5717 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler + (was: Re: Call for votes on init system resolution)
+
Date: Thu, 6 Feb 2014 14:19:49 +0000 (UTC)
+
+
Didier 'OdyX' Raboud dixit:
+
+>Now, I think there is currently a shared agreement in Debian that
+>
+>    "all Debian packages (unless there's a good reason) should run on
+>     sysvinit + Linux + amd64 , support outside that is best-effort"
+
+Eh, no! Debian is the universal OS, and it has quite a number
+of release architectures. And even then, including support for
+everything else is still strongly encouraged.
+
+bye,
+//mirabilos
+-- 
+13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good
+guy. But he's always right! In every fsckin' situation, he's right. Even
+with his deeply perverted taste in software and borked ambition towards
+broken OSes - in the end, he's damn right about it :(! […] works in mksh
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 15:57:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 15:57:08 GMT) (full text, mbox, link).

+ +

Message #5722 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 07:55:10 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Feb 05, 2014 at 09:56:14AM -0800, Steve Langasek wrote:
+> On Wed, Feb 05, 2014 at 04:33:57PM +0000, Ian Jackson wrote:
+> > Ian Jackson writes ("Bug#727708: package to change init systems"):
+> > > I now intend to do the CFV at 16:30 UTC on Wednesday.
+
+> > I hereby call for votes on my previously proposed resolution and
+> > amendments.  All the options require a simple majority.
+
+> > The list of options, and full resolution text, are reproduced below.
+
+Changing my vote to:
+
+  1.  FD   further discussion
+  2.  UL   upstart default in jessie, requiring specific init NOT allowed
+  3.  DL   systemd default in jessie, requiring specific init NOT allowed
+  4.  OL   openrc default in jessie, requiring specific init NOT allowed
+  5.  VL   sysvinit default in jessie, requiring specific init NOT allowed
+  6.  UT   upstart default in jessie, requiring specific init is allowed
+  7.  DT   systemd default in jessie, requiring specific init is allowed
+  8.  OT   openrc default in jessie, requiring specific init is allowed
+  8.  VT   sysvinit default in jessie, requiring specific init is allowed
+  9.  GR   project should decide via GR
+
+To rank FD first and allow a bit more time for drafting something we can all
+agree on.  Thanks to Ian for being agreeable to this.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 15:57:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 15:57:12 GMT) (full text, mbox, link).

+ +

Message #5727 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 15:56:04 +0000
+
+
On Wed, Feb 05, 2014 at 10:32:10PM +0000, Colin Watson wrote:
+> On Wed, Feb 05, 2014 at 04:33:57PM +0000, Ian Jackson wrote:
+> > I hereby call for votes on my previously proposed resolution and
+> > amendments.  All the options require a simple majority.
+> 
+> I vote:
+
+In response to the uncertainty about the constitutional validity of this
+vote, and since Steve still has redrafting he wants to see on the
+ballot, I'm changing my vote as follows:
+
+  1. FD   further discussion
+  2. UL   upstart default in jessie, requiring specific init NOT allowed
+  3. DL   systemd default in jessie, requiring specific init NOT allowed
+  4. OL   openrc default in jessie, requiring specific init NOT allowed
+  5. UT   upstart default in jessie, requiring specific init is allowed
+  6. DT   systemd default in jessie, requiring specific init is allowed
+  7. GR   project should decide via GR
+  8. OT   openrc default in jessie, requiring specific init is allowed
+  9. VL   sysvinit default in jessie, requiring specific init NOT allowed
+ 10. VT   sysvinit default in jessie, requiring specific init is allowed
+
+I hope we only have to go round this business once more!
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 16:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 16:00:04 GMT) (full text, mbox, link).

+ +

Message #5732 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 15:58:06 +0000
+
+
Colin Watson writes ("Bug#727708: Call for votes on init system resolution"):
+> I hope we only have to go round this business once more!
+
+Quite!
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 16:09:20 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 16:09:20 GMT) (full text, mbox, link).

+ +

Message #5737 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 16:05:35 +0000
+
+
Steve Langasek writes ("Bug#727708: Call for votes on init system resolution"):
+> Changing my vote to:
+> 
+>   1.  FD   further discussion
+
+With this and Colin's change of vote, 4 TC members have ranked FD
+first.  The outcome is no longer in doubt: FD wins.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 17:57:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Emilio Pozuelo Monfort <pochu@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 17:57:08 GMT) (full text, mbox, link).

+ +

Message #5742 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Emilio Pozuelo Monfort <pochu@debian.org>
+
To: Steve Langasek <vorlon@debian.org>, + pkg-gnome-maintainers@lists.alioth.debian.org, 726763@bugs.debian.org, + 727708@bugs.debian.org, Russ Allbery <rra@debian.org>, + Josh Triplett <josh@joshtriplett.org>
+
Subject: Re: Bug#727708: Processed: block 726763 with 727708
+
Date: Thu, 06 Feb 2014 18:53:06 +0100
+
+
Sorry to add more noise to #727708, but I feel the need to clarify some
+accusations that have been made before.
+
+First of all, there's been no malice from our side as you have accused us of in
+this thread. As an example, if you look at the last gdm3 and gnome-shell 3.8.x
+uploads and their bug reports, you'll see that I tried hard to fix GNOME not
+starting on sysvinit and other cases (e.g. custom kernels with different options
+to Debian's).
+
+I believe that I got things working for most users (I tested with both systemd
+and sysvinit, with and without libpam-systemd...), though it still looks like
+some people are having issues. Unfortunately, the bad atmosphere and the various
+accusations here and on debian-devel didn't really motivate me to keep working
+on that (or other Debian stuff tbh). Thus I've been holding on until the init
+system decision is resolved, however that goes.
+
+Now as for your direct question:
+
+On 02/02/14 00:24, Steve Langasek wrote:
+> Would the GNOME maintainers be willing to upload such a change?  Or would
+> they be ok with me NMUing gnome-settings-daemon for it?
+
+(These are my own thoughts.) I want to see how the TC decides on the init system
+question first. Then I'll think about how to move forward on this and other
+(related) issues. In any case I'll try to support the default init system, as
+well as other inits, provided the TC decides that that is desired and the work
+needed and the patches involved are not too invasive (and I may require changes
+to be sent upstream first, but that is not different to what I already do in
+many cases when I consider it appropriate). This may depend on whether fallback
+paths are provided and maintained, on whether alternative implementations of the
+required dbus interfaces are provided, and on other technicalities that we will
+have to think through...
+
+Looking forward to a final decision on the subject at hand,
+Emilio
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 18:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 18:03:04 GMT) (full text, mbox, link).

+ +

Message #5747 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: Don Armstrong <don@debian.org>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 18:59:02 +0100
+
+
On Wed, Feb 05, 2014 at 10:31:24PM -0800, Russ Allbery wrote:
+> Don Armstrong <don@debian.org> writes:
+> > On Thu, 06 Feb 2014, Kurt Roeckx wrote:
+> 
+> >> So let me expand on that a little.  Image the following options
+> >> - A: something that doesn't overrule the ctte (1:1)
+> >> - B: something that does overrule the ctte (2:1)
+> >> - FD
+> 
+> > In this case, I don't know A could be anything but 2:1, baring riders
+> > from the CTTE. If A is technical, it needs the power of the CTTE under
+> > §4.1.4 which requires 2:1. [I suppose something could be written which
+> > would fall under the DPL's remit.]
+> 
+> > As I understand it, we'd like to make everything be 1:1, and the method
+> > we're trying is to write a proposal in such a way that it automatically
+> > enshrouds a non-technical statement by the project in the power of the
+> > CTTE.
+> 
+> > It may be that we can't actually do that, and should instead just have
+> > an agreement between CTTE members to enact a decision which followed a
+> > position statement GR under §4.1.5.
+> 
+> I think what we're trying to say looks something like this:
+> 
+>     If the project holds a GR vote on the topic of the default init
+>     system, the winning option of that vote replaces this text in its
+>     entirety and becomes the decision of the Technical Committee.  The
+>     winning option of the GR vote for this purpose will be decided
+>     following the normal rules for deciding the outcome of a General
+>     Resolution, with the exception that the 2:1 majority normally required
+>     to overule the Technical Committee will not be taken into account.
+
+I think there are basicly 2 ways to go about this:
+- You revoke your decision during the GR process so that when
+  the GR is being voted on your decision no longer applies and
+  the GR isn't trying to override the ctte.  You could for
+  instance do this at the call for votes point.
+- The GR will be with 2:1 majority and if it comes to a decision
+  other than FD, that will be the result.  If the decision of the
+  GR is FD you could go and re-intreprete it with the 2:1 majority
+  dropped.
+
+I suggest you go for the first option.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 18:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 18:06:04 GMT) (full text, mbox, link).

+ +

Message #5752 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 19:04:53 +0100
+
+
On Wed, Feb 05, 2014 at 10:58:06PM +0000, Ian Jackson wrote:
+> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
+> > Please do not assume I have time to read everything.  I don't.  I
+> > actually think I gave advice about this before which you seem to
+> > have ignored.
+> 
+> I'm sorry if I also missed a mail.
+> 
+> > > Anyway, I think as regards T vs L we are chiefly exercising our power
+> > > to set technical policy.  As regards the default init system we are
+> > > making a decision which has been requested of us by the people
+> > > normally responsible (which would be the d-i maintainersI think).
+> > 
+> > I would like to point out that this was requested by Paul
+> > Tagliamonte, who as far as I know is not in the d-i team.  I
+> > didn't see anybody from the d-i team request that you make a
+> > decision for them, but I might have missed that.
+> 
+> I assume you would like us to cancel the current vote and address
+> these points.
+
+I have no problem with the vote being held.  However I might feel
+the need partially revoke the decision at some point.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 18:24:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 18:24:08 GMT) (full text, mbox, link).

+ +

Message #5757 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: Kurt Roeckx <kurt@roeckx.be>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 10:22:15 -0800
+
+
On Thu, 06 Feb 2014, Kurt Roeckx wrote:
+> I think there are basicly 2 ways to go about this:
+> - You revoke your decision during the GR process so that when
+>   the GR is being voted on your decision no longer applies and
+>   the GR isn't trying to override the ctte.  You could for
+>   instance do this at the call for votes point.
+> - The GR will be with 2:1 majority and if it comes to a decision
+>   other than FD, that will be the result.  If the decision of the
+>   GR is FD you could go and re-intreprete it with the 2:1 majority
+>   dropped.
+
+Either of these options will require 2:1, though.
+
+Let me quote §4.1.4:
+
+   Together, the Developers may: [...] Make or override any decision
+   authorised by the powers of the Technical Committee, provided they
+   agree with a 2:1 majority.
+
+As you can see, there's no difference between making a decision which
+requires the CTTE powers (first proposed method), or overriding a
+decision which requires the CTTE powers (second proposed method).
+
+We want to draft language which avoids this, which is what the paragraph
+in question (and Ian's paragraph in [1]) attempt to do.
+
+1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#5684
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+A kiss was mysterious and powerful, fragile and invincible. Like any
+spark, a kiss might fizzle into nothing or consume an entire forest.
+[...] A kiss could change the entire world.
+  -- Scott Westerfeld _The Killing of Worlds_ p336
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 18:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 18:27:04 GMT) (full text, mbox, link).

+ +

Message #5762 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Kurt Roeckx <kurt@roeckx.be>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 18:26:09 +0000
+
+
Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
+> I think there are basicly 2 ways to go about this:
+> - You revoke your decision during the GR process so that when
+>   the GR is being voted on your decision no longer applies and
+>   the GR isn't trying to override the ctte.  You could for
+>   instance do this at the call for votes point.
+> - The GR will be with 2:1 majority and if it comes to a decision
+>   other than FD, that will be the result.  If the decision of the
+>   GR is FD you could go and re-intreprete it with the 2:1 majority
+>   dropped.
+> 
+> I suggest you go for the first option.
+
+The Developers have, by way of GR, the ability to express opinions as
+a non-binding "position statement on a matter of the day".  This
+requires a 1:1 majority.
+
+Do you think the Developers lose that ability if their non-binding
+position statement expresses views which are contrary to a decision of
+the TC ?  Or do they lose that ability if their non-binding position
+statement express views which are contrary to the decisions of an
+individual Developer ?  Or if their non-binding position statement
+expresses views which are contrary to the decisions of a body outside
+Debian over which the Developers obviously have no authority ?  Surely
+not, to all three of these.
+
+Do you think the TC can take into account, in its decisionmaking, the
+non-binding views expressed by bodies such as the Developers in
+General Resolution ?  I think, yes.
+
+Do you think the TC can make its decisions conditional on future
+events ?  I think, yes.  Is that in any way limited to the kinds of
+future events ?  I think not.
+
+So, then I think that the TC has the power to make its decisions
+dependent on the expression (or lack of expression) of views in a
+non-binding position statement General Resolution.
+
+If you agree with this reasoning then I'd be grateful if you'd advise
+what form of words should be used to achieve the desired effect.  The
+desired effect is that:
+
+ * A GR option containing a non-binding position statement, requiring
+   a 1:1 majority, can trigger:
+
+ * Provisions in a TC resolution which is conditional on such a GR,
+
+ * such that the TC declares in advance that the GR's views are to be
+   substituted for the TC's.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 18:39:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 18:39:10 GMT) (full text, mbox, link).

+ +

Message #5767 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Don Armstrong <don@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 19:37:01 +0100
+
+
On Thu, Feb 06, 2014 at 10:22:15AM -0800, Don Armstrong wrote:
+> On Thu, 06 Feb 2014, Kurt Roeckx wrote:
+> > I think there are basicly 2 ways to go about this:
+> > - You revoke your decision during the GR process so that when
+> >   the GR is being voted on your decision no longer applies and
+> >   the GR isn't trying to override the ctte.  You could for
+> >   instance do this at the call for votes point.
+> > - The GR will be with 2:1 majority and if it comes to a decision
+> >   other than FD, that will be the result.  If the decision of the
+> >   GR is FD you could go and re-intreprete it with the 2:1 majority
+> >   dropped.
+> 
+> Either of these options will require 2:1, though.
+> 
+> Let me quote §4.1.4:
+> 
+>    Together, the Developers may: [...] Make or override any decision
+>    authorised by the powers of the Technical Committee, provided they
+>    agree with a 2:1 majority.
+> 
+> As you can see, there's no difference between making a decision which
+> requires the CTTE powers (first proposed method), or overriding a
+> decision which requires the CTTE powers (second proposed method).
+
+It's not clear to me which powers of the the ctte they would be
+overriding.  I can't say anything about that until someone
+actually makes a draft text for that GR.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 18:51:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 18:51:10 GMT) (full text, mbox, link).

+ +

Message #5772 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 19:49:54 +0100
+
+
On Thu, Feb 06, 2014 at 06:26:09PM +0000, Ian Jackson wrote:
+> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
+> > I think there are basicly 2 ways to go about this:
+> > - You revoke your decision during the GR process so that when
+> >   the GR is being voted on your decision no longer applies and
+> >   the GR isn't trying to override the ctte.  You could for
+> >   instance do this at the call for votes point.
+> > - The GR will be with 2:1 majority and if it comes to a decision
+> >   other than FD, that will be the result.  If the decision of the
+> >   GR is FD you could go and re-intreprete it with the 2:1 majority
+> >   dropped.
+> > 
+> > I suggest you go for the first option.
+> 
+> The Developers have, by way of GR, the ability to express opinions as
+> a non-binding "position statement on a matter of the day".  This
+> requires a 1:1 majority.
+
+That assumes that the text is actually a position statement.  I'm
+not sure that I can interprete all texts as position statements.
+As always, I have to see the text first.
+
+> Do you think the Developers lose that ability if their non-binding
+> position statement expresses views which are contrary to a decision of
+> the TC ?
+
+I don't see how Developers by way of GR can lose any power by a
+body inside or outside Debian.
+
+> Do you think the TC can take into account, in its decisionmaking, the
+> non-binding views expressed by bodies such as the Developers in
+> General Resolution ?  I think, yes.
+
+Yes.
+
+> Do you think the TC can make its decisions conditional on future
+> events ?  I think, yes.  Is that in any way limited to the kinds of
+> future events ?  I think not.
+
+I already said they can.  But I also said it will depend on the
+wording.
+
+> If you agree with this reasoning then I'd be grateful if you'd advise
+> what form of words should be used to achieve the desired effect.  The
+> desired effect is that:
+> 
+>  * A GR option containing a non-binding position statement, requiring
+>    a 1:1 majority, can trigger:
+> 
+>  * Provisions in a TC resolution which is conditional on such a GR,
+> 
+>  * such that the TC declares in advance that the GR's views are to be
+>    substituted for the TC's.
+
+I guess it should mention that the option in the GR should be a
+position statement (and should not try to override the CTTE).
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 18:54:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 18:54:19 GMT) (full text, mbox, link).

+ +

Message #5777 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Kurt Roeckx <kurt@roeckx.be>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 18:53:56 +0000
+
+
Kurt Roeckx writes ("Re: Bug#727708: Call for votes on init system resolution"):
+> On Thu, Feb 06, 2014 at 06:26:09PM +0000, Ian Jackson wrote:
+> > If you agree with this reasoning then I'd be grateful if you'd advise
+> > what form of words should be used to achieve the desired effect.  The
+> > desired effect is that:
+> > 
+> >  * A GR option containing a non-binding position statement, requiring
+> >    a 1:1 majority, can trigger:
+> > 
+> >  * Provisions in a TC resolution which is conditional on such a GR,
+> > 
+> >  * such that the TC declares in advance that the GR's views are to be
+> >    substituted for the TC's.
+> 
+> I guess it should mention that the option in the GR should be a
+> position statement (and should not try to override the CTTE).
+
+Yes.  What did you think of my proposal earlier ?  If you don't think
+that has the right effect, please suggest something else.
+
+> That assumes that the text is actually a position statement.  I'm
+> not sure that I can interprete all texts as position statements.
+> As always, I have to see the text first.
+
+If the text explicitly says that it is a non-binding position
+statement issued under s4.1.5 of the Constitution, would that suffice ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 19:00:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 19:00:09 GMT) (full text, mbox, link).

+ +

Message #5782 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 19:57:50 +0100
+
+
On Thu, Feb 06, 2014 at 06:53:56PM +0000, Ian Jackson wrote:
+> Kurt Roeckx writes ("Re: Bug#727708: Call for votes on init system resolution"):
+> > On Thu, Feb 06, 2014 at 06:26:09PM +0000, Ian Jackson wrote:
+> > > If you agree with this reasoning then I'd be grateful if you'd advise
+> > > what form of words should be used to achieve the desired effect.  The
+> > > desired effect is that:
+> > > 
+> > >  * A GR option containing a non-binding position statement, requiring
+> > >    a 1:1 majority, can trigger:
+> > > 
+> > >  * Provisions in a TC resolution which is conditional on such a GR,
+> > > 
+> > >  * such that the TC declares in advance that the GR's views are to be
+> > >    substituted for the TC's.
+> > 
+> > I guess it should mention that the option in the GR should be a
+> > position statement (and should not try to override the CTTE).
+> 
+> Yes.  What did you think of my proposal earlier ?  If you don't think
+> that has the right effect, please suggest something else.
+
+Yes, I think that should be fine.
+
+> > That assumes that the text is actually a position statement.  I'm
+> > not sure that I can interprete all texts as position statements.
+> > As always, I have to see the text first.
+> 
+> If the text explicitly says that it is a non-binding position
+> statement issued under s4.1.5 of the Constitution, would that suffice ?
+
+Yes.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 19:09:20 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 19:09:20 GMT) (full text, mbox, link).

+ +

Message #5787 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Kurt Roeckx <kurt@roeckx.be>
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 19:06:23 +0000
+
+
Kurt Roeckx writes ("Re: Bug#727708: Call for votes on init system resolution"):
+> On Thu, Feb 06, 2014 at 06:53:56PM +0000, Ian Jackson wrote:
+> > Yes.  What did you think of my proposal earlier ?  If you don't think
+> > that has the right effect, please suggest something else.
+> 
+> Yes, I think that should be fine.
+
+Oh good.
+
+> If the text explicitly says that it is a non-binding position
+> statement issued under s4.1.5 of the Constitution, would that suffice ?
+
+For belt and braces, let's do this too.
+
+So for the avoidance of doubt, we would put this into the TC
+resolution:
+
+  If the project passes by a General Resolution, a "position statement
+  about issues of the day", on the subject of init systems, the views
+  expressed in that position statement entirely replace the substance
+  of this TC resolution; the TC hereby adopts any such position
+  statement as its own decision.
+
+  Such a position statement could, for example, use these words:
+
+     The Project requests (as a position statement under s4.1.5 of the
+     Constitution) that the TC reconsider, and requests that the TC
+     would instead decide as follows:
+
+This would replace the "GR rider" part in all the substantive TC
+ballot options.
+
+So let us suppose that the TC voted for VT (in my existing scheme)
+with that rider, a GR to pseudo-override it to exactly the
+previously-seen UL proposal would look like this:
+
+   The Project requests (as a position statement under s4.1.5 of the
+   Constitution) that the TC reconsider, and requests that the TC
+   would instead decide as follows:
+
+   The default init system for Linux architectures in jessie should
+   be upstart.
+
+   This decision is limited to selecting a default initsystem for
+   jessie.  We expect that Debian will continue to support multiple
+   init systems for the foreseeable future; we continue to welcome
+   contributions of support for all init systems.
+
+   Therefore, for jessie and later releases:
+
+   Software outside of an init system's implementation may not require
+   a specific init system to be pid 1, although degraded operation is
+   tolerable.
+
+   Maintainers are encouraged to accept technically sound patches
+   to enable improved interoperation with various init systems.
+
+As I understand you, you are saying that such a GR text would require
+a 1:1 majority, and would be automatically effective by virtue of the
+previous TC decision.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 19:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 19:12:05 GMT) (full text, mbox, link).

+ +

Message #5792 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: Kurt Roeckx <kurt@roeckx.be>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 11:08:49 -0800
+
+
On Thu, 06 Feb 2014, Kurt Roeckx wrote:
+> On Thu, Feb 06, 2014 at 10:22:15AM -0800, Don Armstrong wrote:
+> > Either of these options will require 2:1, though.
+> > 
+> > Let me quote §4.1.4:
+> > 
+> >    Together, the Developers may: [...] Make or override any decision
+> >    authorised by the powers of the Technical Committee, provided they
+> >    agree with a 2:1 majority.
+> > 
+> > As you can see, there's no difference between making a decision which
+> > requires the CTTE powers (first proposed method), or overriding a
+> > decision which requires the CTTE powers (second proposed method).
+> 
+> It's not clear to me which powers of the the ctte they would be
+> overriding.
+
+They would either be using the powers of the CTTE in 6.1.2, 6.1.1, or
+6.1.3. 
+
+My point is that there's no difference in the constitution between
+developers /making/ a decision that requires CTTE powers and
+/overriding/ a decision which requires CTTE powers. [If that was clear
+previously, I apologize in advance for becoming more emphatic.]
+
+I suppose there could be some draft texts which did not actually require
+the CTTE powers (as a position statement, say), but without language to
+the contrary in the CTTE's decision, the majority needed is irrelevant
+to whether the CTTE has vacated its decision or not.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+N: Why should I believe that?"
+B: Because it's a fact."
+N: Fact?"
+B: F, A, C, T... fact"
+N: So you're saying that I should believe it because it's true. 
+   That's your argument?
+B: It IS true.
+-- "Ploy" http://www.mediacampaign.org/multimedia/Ploy.MPG
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 19:42:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 19:42:05 GMT) (full text, mbox, link).

+ +

Message #5797 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Didier 'OdyX' Raboud <odyx@debian.org>, 727708@bugs.debian.org
+
Cc: secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler + (was: Re: Call for votes on init system resolution)
+
Date: Thu, 6 Feb 2014 20:38:25 +0100
+
+
On Thu, Feb 06, 2014 at 01:30:25PM +0100, Didier 'OdyX' Raboud wrote:
+> 
+> Finally, I have hard time seeing under which powers could L be decided 
+> by the tech-ctte: the policy team hasn't worked on that (§6.1.1), there 
+> is no juridiction overlap that I could see (nor a disagreement about the 
+> matter, §6.1.2), and it's not formulated as an overrule (§6.1.4) or an 
+> advice (§6.1.5). The only relevant bit would be §6.1.3 as Paul 
+> specifically asked for in <20131025184344.GB4599@helios.pault.ag>:
+
+So Didier recently forwarded this to the secretary, saying:
+> I've mailed Message-ID <1997214.E2693zAoXp@gyllingar> to the init system
+> bug, but forgot to CC you for a more binding advice on the
+> constitutionality of L. I'm therefore hereby writing to you explicitely;
+> my original message is attached.
+> 
+> Don't hesitate to prove me wrong publically, I'm only interested in
+> having a constitutionally sane decision out, rather sooner than later.
+
+I have also asked them under which power they decide things.  This
+makes things so much clearer for everybody.
+
+The text from the last vote said:
+> == dependencies rider version L (Loose coupling) ==
+> 
+>   Software outside of an init system's implementation may not require
+>   a specific init system to be pid 1, although degraded operation is
+>   tolerable.
+>
+>   Maintainers are encouraged to accept technically sound patches
+>   to enable improved interoperation with various init systems.
+
+I'm guessing that under you're asking for the interpretation of
+this in 6.1.1:
+| In each case the usual maintainer of the relevant software or
+| documentation makes decisions initially
+
+And think that because the policy maintainers didn't try to make
+any decision yet, the ctte can't make that decisions?
+
+I can certainly understand that that is one way of looking at it.
+
+I'm not yet sure about this and would like to receive some input.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 19:54:22 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 19:54:23 GMT) (full text, mbox, link).

+ +

Message #5802 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 11:53:52 -0800
+
+
On Wed, 05 Feb 2014, Ian Jackson wrote:
+> Don Armstrong writes ("Bug#727708: Call for votes on init system resolution"):
+> > In fact, if this was your intention all along, it's not clear at all
+> > to me why we had to couple these votes.
+> 
+> You'll notice that my ranking of the init systems differs between the
+> T options and the L options.
+
+Sure, but only in regards to whether you vote openrc or sysvinit over
+systemd.
+
+Given the already stated preferences of the CTTE, and the previous votes
+we've already had, openrc and sysvinit are clearly not going to defeat
+any option, so their position in your vote is largely irrelevant.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+Let us chat together a moment, my friend. There are still several
+hours until dawn, and I have the whole day to sleep.
+ -- Count Orlock in _Nosferatu (1922)_
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 20:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 20:21:04 GMT) (full text, mbox, link).

+ +

Message #5807 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Didier 'OdyX' Raboud <odyx@debian.org>, 727708@bugs.debian.org
+
Cc: secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler + (was: Re: Call for votes on init system resolution)
+
Date: Thu, 6 Feb 2014 21:19:36 +0100
+
+
On Thu, Feb 06, 2014 at 08:38:25PM +0100, Kurt Roeckx wrote:
+> 
+> I'm guessing that under you're asking for the interpretation of
+> this in 6.1.1:
+> | In each case the usual maintainer of the relevant software or
+> | documentation makes decisions initially
+> 
+> And think that because the policy maintainers didn't try to make
+> any decision yet, the ctte can't make that decisions?
+> 
+> I can certainly understand that that is one way of looking at it.
+> 
+> I'm not yet sure about this and would like to receive some input.
+
+I'm currently of the opinion that gnome made an initial decisions
+and as reaction to that they are setting policy and that this will
+be allowed under 6.1.1.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 20:21:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 20:21:07 GMT) (full text, mbox, link).

+ +

Message #5812 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 6 Feb 2014 20:20:07 +0000
+
+
Don Armstrong writes ("Bug#727708: Call for votes on init system resolution"):
+> Given the already stated preferences of the CTTE, and the previous votes
+> we've already had, openrc and sysvinit are clearly not going to defeat
+> any option, so their position in your vote is largely irrelevant.
+
+If we held the votes separately in the other order, T-vs-L first, and
+T won, I would put GR ahead of systemd-T.  So if we vote on U-D-O-V
+first, l don't know whether to rank systemd above GR.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 20:27:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 20:27:05 GMT) (full text, mbox, link).

+ +

Message #5817 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
+
Date: Thu, 6 Feb 2014 20:25:58 +0000
+
+
Kurt Roeckx writes ("Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)"):
+> I'm currently of the opinion that gnome made an initial decisions
+> and as reaction to that they are setting policy and that this will
+> be allowed under 6.1.1.
+
+Yes, the T-vs-L thing is setting policy.  (Although we're leaving the
+exact text of policy up to the policy editors.)
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 20:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 20:33:05 GMT) (full text, mbox, link).

+ +

Message #5822 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Didier 'OdyX' Raboud <odyx@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler + (was: Re: Call for votes on init system resolution)
+
Date: Thu, 6 Feb 2014 22:30:47 +0200
+
+
On Thu, Feb 06, 2014 at 10:20:02AM +0100, Didier 'OdyX' Raboud wrote:
+>...
+> Now, I think there is currently a shared agreement in Debian that
+> 
+>     "all Debian packages (unless there's a good reason) should run on
+>      sysvinit + Linux + amd64 , support outside that is best-effort"
+
+sysvinit support was mandated indirectly due to it being the one and 
+only init system used by Debian.
+
+But contrary to what you are saying, there is not one main Debian port 
+that matters and all the others are just best effort.
+
+> Now, I think this "default init" decision's purpose is to change the 
+> above agreement by replacing the "syslinux" in the above sentence by one 
+> of the contenders. Both the T and L riders purposedly don't say anything
+> about the default init, and I think that's wrong:
+>...
+
+You might think that is wrong, but (like basically all possibilities) 
+this has already been discussed here and none of the members of the TC 
+seems to favor a "must not require any init other than the default init" 
+so it didn't even make it to the TC ballot.
+
+In practice, L means that the old status quo that all packages have to 
+work under sysvinit stays.
+
+And that also has benefits, e.g. it reduces the hassle for downstream 
+distributions who use an init system other than the one Debian uses as 
+default.
+
+There is not any "right" solution everyone could agree on, and after 
+months of discussions it is extremely unlikely that someone expressing
+his opinion now could change the vote of any member of the TC.
+
+> Thanks for considering, cheers,
+> 
+> Didier
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 21:27:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 21:27:10 GMT) (full text, mbox, link).

+ +

Message #5827 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 07:22:10 +1000
+
+
On 7 February 2014 06:20, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
+> Don Armstrong writes ("Bug#727708: Call for votes on init system resolution"):
+>> Given the already stated preferences of the CTTE, and the previous votes
+>> we've already had, openrc and sysvinit are clearly not going to defeat
+>> any option, so their position in your vote is largely irrelevant.
+> If we held the votes separately in the other order, T-vs-L first, and
+> T won, I would put GR ahead of systemd-T.  So if we vote on U-D-O-V
+> first, l don't know whether to rank systemd above GR.
+
+Based on your initial vote on your own ballot and the above, your
+votes would be:
+
+  1.  LFT
+  2a. (L wins): UDF
+  2b. (T wins): FUD (*cough*)
+
+or:
+
+  1. UD  ("where do I put F?")
+  2. LFT
+
+Presuming everyone votes, where you put F only has an impact in either
+case only if at least three other ctte members will also vote FD above
+T or DT (given UT is irrelevant); which based on the already expressed
+preferences and votes, isn't actually going to happen.
+
+Cheers,
+aj
+
+-- 
+Anthony Towns <aj@erisian.com.au>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 22:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 22:09:05 GMT) (full text, mbox, link).

+ +

Message #5832 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Anthony Towns <aj@erisian.com.au>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 00:04:20 +0200
+
+
On Fri, Feb 07, 2014 at 07:22:10AM +1000, Anthony Towns wrote:
+> On 7 February 2014 06:20, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
+> > Don Armstrong writes ("Bug#727708: Call for votes on init system resolution"):
+> >> Given the already stated preferences of the CTTE, and the previous votes
+> >> we've already had, openrc and sysvinit are clearly not going to defeat
+> >> any option, so their position in your vote is largely irrelevant.
+> > If we held the votes separately in the other order, T-vs-L first, and
+> > T won, I would put GR ahead of systemd-T.  So if we vote on U-D-O-V
+> > first, l don't know whether to rank systemd above GR.
+> 
+> Based on your initial vote on your own ballot and the above, your
+> votes would be:
+> 
+>   1.  LFT
+>   2a. (L wins): UDF
+>   2b. (T wins): FUD (*cough*)
+> 
+> or:
+> 
+>   1. UD  ("where do I put F?")
+>   2. LFT
+> 
+> Presuming everyone votes, where you put F only has an impact in either
+> case only if at least three other ctte members will also vote FD above
+> T or DT (given UT is irrelevant); which based on the already expressed
+> preferences and votes, isn't actually going to happen.
+
+Why not?
+
+I am not sure whether Colin is aware that it currently depends on him 
+whether or not DT can win - and whether that might make him consider 
+changing his vote.
+
+If Ian convinces Colin to change his vote to move DT from 5. to 7. on 
+his ballot, then DT cannot pass FD and is dead.
+
+> Cheers,
+> aj
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 22:24:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 22:24:05 GMT) (full text, mbox, link).

+ +

Message #5837 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: 727708@bugs.debian.org, Anthony Towns <aj@erisian.com.au>, Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 06 Feb 2014 14:20:51 -0800
+
+
Adrian Bunk <bunk@stusta.de> writes:
+> On Fri, Feb 07, 2014 at 07:22:10AM +1000, Anthony Towns wrote:
+
+>> Presuming everyone votes, where you put F only has an impact in either
+>> case only if at least three other ctte members will also vote FD above
+>> T or DT (given UT is irrelevant); which based on the already expressed
+>> preferences and votes, isn't actually going to happen.
+
+> Why not?
+
+> I am not sure whether Colin is aware that it currently depends on him 
+> whether or not DT can win - and whether that might make him consider 
+> changing his vote.
+
+> If Ian convinces Colin to change his vote to move DT from 5. to 7. on 
+> his ballot, then DT cannot pass FD and is dead.
+
+Which is just a concrete way of pointing out that Debian's standard
+resolution method fails later-no-harm.
+
+    https://en.wikipedia.org/wiki/Later-no-harm_criterion
+
+This is a known weakness in Condorcet, which I suspect we have made worse
+with the way that Debian treats FD.
+
+This is one of the major reasons why I'm voting GR second.  I see Bdale's
+point that we shouldn't abdicate our responsibility to make the best
+decision that we can, and I followed that maxim by voting my preference
+first.  But the reality is that, regardless of whether Condorcet is
+capable of spitting out some technical compromise, we are deadlocked, and
+sufficiently so that we're running into edge case failure modes of the
+standard resolution method.
+
+In that situation, the TC recusing itself is not the worst thing that
+could happen.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 22:48:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 22:48:10 GMT) (full text, mbox, link).

+ +

Message #5842 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org, Anthony Towns <aj@erisian.com.au>, + Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 00:44:20 +0200
+
+
On Thu, Feb 06, 2014 at 02:20:51PM -0800, Russ Allbery wrote:
+>...
+> This is one of the major reasons why I'm voting GR second.  I see Bdale's
+> point that we shouldn't abdicate our responsibility to make the best
+> decision that we can, and I followed that maxim by voting my preference
+> first.  But the reality is that, regardless of whether Condorcet is
+> capable of spitting out some technical compromise, we are deadlocked, and
+> sufficiently so that we're running into edge case failure modes of the
+> standard resolution method.
+>...
+
+No, looking at the votes so far you are absolutely not deadlocked since 
+you might have a winner that is considered acceptable by all 8 members 
+of the TC:
+
+The most problematic option for many TC members is not D or S,
+the most problematic option is T.
+
+If Colin joins Ian, Andreas and Steve in voting DT and UT below FD,
+then T is dead.
+
+But DL might beat FD 8:0, and will likely be the overall winner since it 
+is expected to beat UL through the casting vote of the chairman.
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 06 Feb 2014 23:03:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 06 Feb 2014 23:03:10 GMT) (full text, mbox, link).

+ +

Message #5847 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Adrian Bunk <bunk@stusta.de>
+
Cc: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org, + Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 08:59:59 +1000
+
+
On 7 February 2014 08:44, Adrian Bunk <bunk@stusta.de> wrote:
+> If Colin joins Ian, Andreas and Steve in voting DT and UT below FD,
+> then T is dead.
+
+It's really pretty terrible to actively use FD to try to block options
+that aren't your favourite. Honestly, I would have expected the tech
+ctte to be able to come to a consensus on a set of proposals
+considered reasonable by all the members, and accept whatever a
+majority decided. I'd certainly hope that tech ctte members won't
+tactically change their vote to try to hack the process.
+
+(The obvious counter is for the four members who prefer T to L to vote
+all the L options below FD in the same way as Andi, Ian and Steve have
+voted all the T options below FD)
+
+(Longer term, it seems to me the vote system would be improved by only
+allowing voters to cast a vote that ranks the proposed options between
+themselves, or to vote for Further Discussion (with no ability to
+express preferences amongst the proposals). Quorum would then be
+satisfied by having Q votes ranking the options, and a vote would only
+be blocked if there was 50% or more of voters voting for FD. A similar
+idea to supermajority requirements could be achieved by allowing
+proposals to be blocked by 1/N voters voting for FD where N > 2)
+
+Cheers,
+aj
+
+-- 
+Anthony Towns <aj@erisian.com.au>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 01:09:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 01:09:05 GMT) (full text, mbox, link).

+ +

Message #5852 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Anthony Towns <aj@erisian.com.au>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 06 Feb 2014 17:04:15 -0800
+
+
Anthony Towns <aj@erisian.com.au> writes:
+
+> It's really pretty terrible to actively use FD to try to block options
+> that aren't your favourite. Honestly, I would have expected the tech
+> ctte to be able to come to a consensus on a set of proposals considered
+> reasonable by all the members, and accept whatever a majority
+> decided. I'd certainly hope that tech ctte members won't tactically
+> change their vote to try to hack the process.
+
+> (The obvious counter is for the four members who prefer T to L to vote
+> all the L options below FD in the same way as Andi, Ian and Steve have
+> voted all the T options below FD)
+
+Exactly.
+
+I've been trying to refrain from tactical voting of that sort.  I don't
+think that's a slippery slope we should start diving down.
+
+I also flatly disagree with Adrian over whether we're deadlocked.  I don't
+see any point in discussing it, though.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 02:24:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 02:24:07 GMT) (full text, mbox, link).

+ +

Message #5857 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 06 Feb 2014 18:20:30 -0800
+
+
Russ Allbery <rra@debian.org> writes:
+> Don Armstrong <don@debian.org> writes:
+>> On Thu, 06 Feb 2014, Kurt Roeckx wrote:
+>
+>>> So let me expand on that a little.  Image the following options
+>>> - A: something that doesn't overrule the ctte (1:1)
+>>> - B: something that does overrule the ctte (2:1)
+>>> - FD
+>
+>> In this case, I don't know A could be anything but 2:1, baring riders
+>> from the CTTE. If A is technical, it needs the power of the CTTE under
+>> §4.1.4 which requires 2:1. [I suppose something could be written which
+>> would fall under the DPL's remit.]
+>
+>> As I understand it, we'd like to make everything be 1:1, and the method
+>> we're trying is to write a proposal in such a way that it automatically
+>> enshrouds a non-technical statement by the project in the power of the
+>> CTTE.
+>
+>> It may be that we can't actually do that, and should instead just have
+>> an agreement between CTTE members to enact a decision which followed a
+>> position statement GR under §4.1.5.
+>
+> I think what we're trying to say looks something like this:
+>
+>     If the project holds a GR vote on the topic of the default init
+>     system, the winning option of that vote replaces this text in its
+>     entirety and becomes the decision of the Technical Committee.  The
+>     winning option of the GR vote for this purpose will be decided
+>     following the normal rules for deciding the outcome of a General
+>     Resolution, with the exception that the 2:1 majority normally required
+>     to overule the Technical Committee will not be taken into account.
+>
+> I think this works, although it does create the possibility of a rather
+> odd situation, and I'm not quite sure how it would work procedurally.
+[more complicated stuff snipped]
+
+It is not at all clear to me why the CTTE so desperately wants to
+automatically defer to a GR in their resolution. If there is consensus
+to defer to a GR with simple majority among the CTTE, surely it would be
+easy enough to revoke or change the resolution if/when a GR has actually
+happened?
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 03:42:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Schlacta, Christ" <aarcane@aarcane.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 03:42:13 GMT) (full text, mbox, link).

+ +

Message #5862 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Schlacta, Christ" <aarcane@aarcane.org>
+
To: 727708@bugs.debian.org
+
Subject: I'd like to voice my opinion
+
Date: Thu, 6 Feb 2014 19:41:30 -0800
+
+
[Message part 1 (text/plain, inline)]
+
I'd like to request that upstart be chosen over systemd mainly because
+there's already a large availability of deb packages that support init
+mainly due to ubuntu.  Ubuntu acts as a gateway distro to the debian
+universe, and is a basis upon which numerous other distros are based as
+well.
+
+As such, a lot of packages are developed for ubuntu instead of debian.
+ Making upstart the default init package allows for compatibility with the
+majority of these ubuntu specific packages.
+
+Furthermore, I know upstart is capable of maintaining backward
+compatibility with systemvinit scripts as debian implements them currently.
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 04:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 04:24:04 GMT) (full text, mbox, link).

+ +

Message #5867 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: "Schlacta, Christ" <aarcane@aarcane.org>, 727708@bugs.debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: I'd like to voice my opinion
+
Date: Fri, 07 Feb 2014 04:11:46 -0008
+
+
[Message part 1 (text/plain, inline)]
+
El Thu, 6 de Feb 2014 a las 7:41 PM, Schlacta, Christ 
+<aarcane@aarcane.org> escribió:
+> I'd like to request that upstart be chosen over systemd mainly 
+> because there's already a large availability of deb packages that 
+> support init mainly due to ubuntu.  Ubuntu acts as a gateway distro 
+> to the debian universe, and is a basis upon which numerous other 
+> distros are based as well.
+> 
+> As such, a lot of packages are developed for ubuntu instead of 
+> debian.  Making upstart the default init package allows for 
+> compatibility with the majority of these ubuntu specific packages.
+> 
+> Furthermore, I know upstart is capable of maintaining backward 
+> compatibility with systemvinit scripts as debian implements them 
+> currently.
+> 
+Hello Christ.
+
+systemd proponents have been hard at work in getting systemd units 
+packaged up and installed. Just load up Sid to see how many there are. 
+Furthermore, systemd supports sysv scripts just like Upstart (actually, 
+they are integrated into systemd's dependency chain, so the 
+implementation is better in that way).
+
+I understand that you had the best of faith in writing this, but I 
+assure you that the availability of init configurations will not be a 
+problem for systemd, Upstart, or OpenRC (OpenRC supports sysv scripts).
+
+That said, Upstart could be a good choice because of the number of 
+desktop environments that have their main focus as Ubuntu (Pantheon, 
+Cinnamon, MATE) and could be encouraged to adopt Upstart as a session 
+init if Debian goes with it. The same could be said of systemd, though 
+(with GNOME and KDE instead of Pantheon and Cinnamon), though.
+
+Have a great day,
+Cameron
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 06:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 06:33:04 GMT) (full text, mbox, link).

+ +

Message #5872 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Anthony Towns <aj@erisian.com.au>
+
Cc: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org, + Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 08:29:27 +0200
+
+
On Fri, Feb 07, 2014 at 08:59:59AM +1000, Anthony Towns wrote:
+> On 7 February 2014 08:44, Adrian Bunk <bunk@stusta.de> wrote:
+> > If Colin joins Ian, Andreas and Steve in voting DT and UT below FD,
+> > then T is dead.
+> 
+> It's really pretty terrible to actively use FD to try to block options
+> that aren't your favourite. Honestly, I would have expected the tech
+> ctte to be able to come to a consensus on a set of proposals
+> considered reasonable by all the members, and accept whatever a
+> majority decided. I'd certainly hope that tech ctte members won't
+> tactically change their vote to try to hack the process.
+>...
+
+When you are saying "a set of proposals considered reasonable by all the 
+members", that basically implies "don't offer the T rider options" since 
+these are options that are not considered reasonable by at large part 
+(at least 3 members) of the TC.
+
+Leaving tactical aspects aside, IMHO the important point is that 
+there is a compromise line that seems reasonable for all members
+of the TC:
+
+For the upstart side of the TC, the most important question is T/L.
+For the systemd side of the TC, the most important question is D/U.
+
+What we see in the combined vote is actually that DL is an option
+that makes both sides win in what they consider their most important
+question - and that seems considered reasonable by all TC members.
+
+This is much more possible consensus than what I'd have expected before 
+the voting started.
+
+
+> Cheers,
+> aj
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 07:42:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 07:42:05 GMT) (full text, mbox, link).

+ +

Message #5877 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Thu, 06 Feb 2014 23:25:02 -0800
+
+
Adrian Bunk <bunk@stusta.de> writes:
+
+> Leaving tactical aspects aside, IMHO the important point is that there
+> is a compromise line that seems reasonable for all members of the TC:
+
+> For the upstart side of the TC, the most important question is T/L.
+> For the systemd side of the TC, the most important question is D/U.
+
+I don't agree with this analysis.
+
+I consider the L option as currently written to be a commitment to a
+course of action that is technically broken and unsustainable.  I also
+think the effect of L is contrary to its intended goal and will make it
+less likely, not more likely, that Debian will provide working support for
+any init system other than the default in the long run.  (More on that
+below.)
+
+L is only "less important" to me because I believe it is unworkable and
+unimplementable in the long run, so it doesn't matter *that* much if it
+wins, since it will naturally get dropped over time.  Eventually, package
+maintainers will realize that the sysvinit scripts everyone has been
+keeping around to give lip service to L don't actually work and aren't
+actually maintained, and it will end up like other similar Debian features
+that are "required" but uninteresting to nearly everyone and therefore
+bitrot and are effectively non-functional.
+
+L will cause less short-term damage with systemd as the default init than
+with upstart or OpenRC as the default init, so I'm grudgingly willing to
+vote DL above FD because the results wouldn't be quite as absurd as the
+results of UL would be, but I'm quite far from happy with it.  In
+practice, I expect any of the L options to require another round of this
+discussion post-jessie to get rid of L again so that we can move forward
+without keeping sysvinit scripts.  I certainly hope they will, since the
+alternative is to have a decision on the books that maintainers are
+supposed to comply with but, in practice, won't, which is an embarassing
+and annoying situation to be in.
+
+L makes it less likely that Debian will support anything other than the
+default init system in the long run because it undermines the process of
+adding native configuration for non-default init systems.  If we said that
+packages are required to support the default init system and strongly
+encouraged to merge support for those with active communities, I think we
+still wouldn't get 100% archive coverage for the non-default, but I do
+think we'd get coverage for most or all of the packages that people using
+the non-default init system care the most about.  That would probably be
+in the form of native configurations for the init systems that people care
+about, since all the native configurations are simpler and easier to
+maintain than sysvinit scripts.  Packages would then depend on the set of
+init systems that they support.  I think that's about the best solution we
+can hope for in the long run: strong support for the default init system,
+and workable but incomplete support for the other init systems, with clear
+indication in the package dependency structure of what init systems are
+supported.
+
+L instead requires everyone maintain sysvinit scripts forever, even if
+they never use them.  That (a) significantly reduces the incentive to add
+the superior native configuration for whatever of systemd, upstart, or
+OpenRC are not the default, since it's "handled" by the sysvinit script,
+and (b) makes it much less likely that those configurations will actually
+be maintained since they're complicated and annoying to try to debug and
+harder to write "blind" without running them.  So I believe L is directly
+destructive to the stated motives of the people who are in favor of L,
+which is one of the reasons why it boggles me that it has so much support.
+
+My preference would be to vote on Bdale's ballot, and I'm unhappy that we
+didn't just continue with that vote.  However, I'm almost entirely out of
+spoons to keep arguing wording and procedural issues, and I think we're at
+the point where this process is starting to cause active damage by
+continuing to drag on.  But apparently I'm failing to keep my mouth shut,
+so, well, here you go.
+
+Neither T nor L actually imply what I think will happen in practice.  The
+T option gives explicit blessing to adding dependencies on non-default
+init systems, which I think is something that's only appropriate on a
+case-by-case basis for edge packages and cooperating package groups and
+isn't appropriate general advice.  It also doesn't distinguish between
+right now and after the jessie release, which I think is inappropriate.  I
+think there's a huge difference between depending on an init system right
+now for the jessie release, which is something I think we should only do
+if there's really no technical alternative available at all, and depending
+on an init system or set of init systems after jessie, which I think is a
+reasonable way of handling the long-term migration path away from
+supporting sysvinit scripts.
+
+I tried to raise these issues multiple times and was roundly ignored, so I
+gave up and just voted the best order I could come up with that I think
+will result in sensible things happening in the long run, even if some of
+the options are not particularly sensible.  But I take extreme exception
+to your acts of mind-reading, and I ask you to please stop putting
+opinions in my mouth.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 08:36:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Matthias Urlichs <matthias@urlichs.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 08:36:05 GMT) (full text, mbox, link).

+ +

Message #5882 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Matthias Urlichs <matthias@urlichs.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
+
Date: Fri, 7 Feb 2014 09:34:07 +0100
+
+
Hi,
+
+Bdale Garbee:
+> I'm not comfortable with a mandate that packages may not require a
+> specific init system as pid 1.  
+> 
+Could we (or rather, the CTTE) compromise on "packages may mandate
+the default init system"?
+
+-- 
+-- Matthias Urlichs
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 09:12:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 09:12:08 GMT) (full text, mbox, link).

+ +

Message #5887 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 07 Feb 2014 01:08:46 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Russ Allbery <rra@debian.org> writes:
+
+> I consider the L option as currently written to be a commitment to a
+> course of action that is technically broken and unsustainable.  I also
+> think the effect of L is contrary to its intended goal and will make it
+> less likely, not more likely, that Debian will provide working support for
+> any init system other than the default in the long run.  (More on that
+> below.)
+
+I agree with this, with a slightly greater emphasis on ensuring that
+Debian developers continue to have great latitude in choosing how to
+package software. I would also have preferred to continue Bdale's ballot
+which didn't mention this issue at all.
+
+I think a fair number of us seem to feel that the T/L notion is at
+least as important, if not more important, than the D/U/O/V decision as
+it sets a broader and longer-term precedent for the project than
+choosing which init system should be the default for jessie.
+
+Would it make sense to actually build a ballot that voted this issue
+separately, and do that *before* the default init system for jessie
+vote? We would list all four of the proposed versions (<nil>, L, T and
+S).
+
+I don't think guiding the project in this particular area should depend
+on which init system was chosen as the default for jessie. I do think
+that either you believe that packages should work with any init system,
+so that you can separately choose any combination of them, or you
+believe that package maintainers should be able to choose a subset of
+the available init systems to support, ruling out some combinations.
+
+I readily admit to not really understanding all of the subtleties of our
+polling process, but when looking at the votes cast for Ian's proposed
+ballot, it looks like we've got a clear set of votes for L vs T already;
+each vote places the xL and xT options in the same order for each 'x'.
+
+It seems to me that this issue is clearly a matter of technical policy
+and falls under the ctte purview under section 6.1.1, although I believe
+it has some ambiguity as to whether it is valid because of 6.3.5. These
+options have certainly been proposed and reasonably thoroughly
+discussed, although one might not consider the init system bug thread as
+separate from the ctte. Of course, it's really a dependency of an issue
+which was brought to the ctte, so in a sense, it's a recursive function
+call.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 09:12:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 09:12:17 GMT) (full text, mbox, link).

+ +

Message #5892 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: Anthony Towns <aj@erisian.com.au>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 10:11:40 +0100
+
+
* Russ Allbery (rra@debian.org) [140207 02:09]:
+> Anthony Towns <aj@erisian.com.au> writes:
+> 
+> > It's really pretty terrible to actively use FD to try to block options
+> > that aren't your favourite. Honestly, I would have expected the tech
+> > ctte to be able to come to a consensus on a set of proposals considered
+> > reasonable by all the members, and accept whatever a majority
+> > decided. I'd certainly hope that tech ctte members won't tactically
+> > change their vote to try to hack the process.
+> 
+> > (The obvious counter is for the four members who prefer T to L to vote
+> > all the L options below FD in the same way as Andi, Ian and Steve have
+> > voted all the T options below FD)
+> 
+> Exactly.
+> 
+> I've been trying to refrain from tactical voting of that sort.  I don't
+> think that's a slippery slope we should start diving down.
+> 
+> I also flatly disagree with Adrian over whether we're deadlocked.  I don't
+> see any point in discussing it, though.
+
+I agree with you, I don't see any reason why we are deadlocked. If we
+want to do yet another round on improving texts this is fine for me,
+but should be finished soon. And the following vote should really be
+finished, and I expect an outcome from the votes and statements I have
+seeing so far. (I don't plan to vote FD again - I even didn't plan it
+for this vote, but wanted to give Steve a chance to update the texts,
+that is why I changed it for the moment.)
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 09:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bill Myers <bill_myers@outlook.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 09:42:04 GMT) (full text, mbox, link).

+ +

Message #5897 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bill Myers <bill_myers@outlook.com>
+
To: "727708@bugs.debian.org" <727708@bugs.debian.org>
+
Subject: Vote on Bdale's ballot plus GR
+
Date: Fri, 7 Feb 2014 09:38:45 +0000
+
+
Why not just vote on Bdale's ballot plus the GR override provision?
+
+There are 4 members who apparently are going to rank systemd first with the
+GR provision, and Bdale casts the deciding vote, so systemd wins.
+
+Once systemd's victory and upstart's defeat is established, then discussion
+on everything else will be much faster, because those who oppose systemd will
+no longer have any conscious or unconscious tendency to attempt to stall the
+process or attempt to manipulate the outcome through extra options.
+
+Alternatively, if "further discussion" is preferred to action, then an 
+interesting topic for that discussion could be whether someone who appears in
+https://launchpad.net/upstart/+topcontributors is likely to be capable or
+interested in providing an unbiased opinion on what the best init system is. 		 	   		  
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 10:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Didier 'OdyX' Raboud" <odyx@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 10:09:04 GMT) (full text, mbox, link).

+ +

Message #5902 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Didier 'OdyX' Raboud" <odyx@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 07 Feb 2014 11:04:46 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Le vendredi, 7 février 2014, 01.08:46 Keith Packard a écrit :
+> I think a fair number of us seem to feel that the T/L notion is at
+> least as important, if not more important, than the D/U/O/V decision
+> as it sets a broader and longer-term precedent for the project than
+> choosing which init system should be the default for jessie.
+
+What the technical committee members feel is important to rule upon is 
+one thing; what the technical committee can rule upon is defined by our 
+constitution. Sometimes there's a mismatch.
+
+> Would it make sense to actually build a ballot that voted this issue
+> separately, and do that *before* the default init system for jessie
+> vote? We would list all four of the proposed versions (<nil>, L, T and
+> S).
+> 
+> (…)
+> 
+> It seems to me that this issue is clearly a matter of technical policy
+> and falls under the ctte purview under section 6.1.1, although I
+> believe it has some ambiguity as to whether it is valid because of
+> 6.3.5.
+
+Sorry to insist on this point, but I think both L and S fall under 
+§6.3.5, specifically under "does not engage in design of new (…) 
+policies": for instance, L says "Software outside of an init system's 
+implementation may not require a specific init system to be pid 1"; that 
+would quite clearly set a new policy.
+
+The latter part of §6.3.5 also applies I think: "The Technical Committee 
+restricts itself to choosing from (…) decisions which have been proposed 
+and reasonably thoroughly discussed elsewhere", which resonates with 
+§6.1.1's parenthesis "the usual maintainer of the relevant (…) 
+documentation makes decisions initially" (who would probably be the 
+Policy maintainers).
+
+The Tight/Loose/Split-the-init discussion has mostly (if not only) been 
+discussed in this bug, by the technical committee members, failing the 
+above "elsewhere". Also, the maintainers of the various concerned 
+packages (consumers or providers of logind for instance) have also 
+clearly stated that their work was stalled by the choice of a default 
+init; this policy work hasn't had a chance to happen.
+
+I think it also fails §6.3.6 "Technical Committee makes decisions only 
+as last resort", as that specific issue hasn't been brought by the 
+Policy maintainers.
+
+Finally, if the matter is of sufficient importance, I'm quite certain 
+that it will be brought up to the Technical Committee.
+
+Cheers, OdyX
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 11:30:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 11:30:12 GMT) (full text, mbox, link).

+ +

Message #5907 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Anthony Towns <aj@erisian.com.au>
+
Cc: Adrian Bunk <bunk@stusta.de>, + Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 11:25:58 +0000
+
+
Anthony Towns writes ("Re: Bug#727708: Call for votes on init system resolution"):
+> It's really pretty terrible to actively use FD to try to block options
+> that aren't your favourite. Honestly, I would have expected the tech
+> ctte to be able to come to a consensus on a set of proposals
+> considered reasonable by all the members, and accept whatever a
+> majority decided. I'd certainly hope that tech ctte members won't
+> tactically change their vote to try to hack the process.
+
+I intend to vote GR above FD for this reason.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 12:54:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Friedrich Gunter <friedrich.gunter@aim.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 12:54:09 GMT) (full text, mbox, link).

+ +

Message #5912 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Friedrich Gunter <friedrich.gunter@aim.com>
+
To: 727708@bugs.debian.org
+
Subject: Steve Langasek Must Not Vote
+
Date: Fri, 7 Feb 2014 07:52:50 -0500 (EST)
+
+
Hello Ctte,
+
+I formerly request that Steve Langasek abstain from voting on this 
+issue due to a clear conflict of interest: he is a top contributor to 
+Upstart <https://launchpad.net/upstart/+topcontributors>, and thus 
+cannot make a clear-minded technical decision. This is compounded, of 
+course, with his other clear conflicts of interest surrounding 
+Canonical Ltd, which make him unfit for participating in this vote. His 
+interests are not solely concerned with the betterment of Debian.
+
+If Steve Langasek chooses to go forward with the vote, I formerly ask 
+the ctte to consider his immediate removal from the ctte, abiding by 
+the Debian constitutional processes for such a removal.
+
+Thank you,
+Friedrich Gunter
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 13:30:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sam Hartman <hartmans@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 13:30:10 GMT) (full text, mbox, link).

+ +

Message #5917 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sam Hartman <hartmans@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Please clarify L options with regard to interfaces
+
Date: Fri, 07 Feb 2014 08:24:51 -0500
+
+
+
+Hi.
+
+There seems to be a significant conflict within the TC about what the L
+options mean.  Speaking as a maintainer who could be affected by this
+and as someone who would sponsor a GR to override one interpretation
+butnot another, I'd request that the TC clarify what it means with the
+next ballot options.
+
+* Colin said that it would be OK to depend on a stable interface such as
+  logind-208 provided that multiple implementations could exist.
+
+* Ian said that this dependency would not be OK.
+
+I'd like the ballot options to clarify:
+
+1) Whether these interface dependencies are acceptable
+
+2) Whether they are acceptable in cases where there is only one
+implementation.
+
+I'd request the TC consider the following question although I'm not sure
+going into this level of detail on the ballot is appropriate:
+
+3) If we are using virtual packages to define interfaces, what should
+the dependency look like?  Would you want a raw virtual dependency such
+as gnome-shell depends on logind-208?  If so, isn't that kind of not how
+we currently recommend things?  Or a concrete dependency like
+systemd|logind-208?  If so, please make sure that if such interface
+dependencies are permitted your policy text actually permits the
+dependency.
+
+Thanks for your consideration,
+
+--Sam
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 13:48:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 13:48:10 GMT) (full text, mbox, link).

+ +

Message #5922 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Sam Hartman <hartmans@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Please clarify L options with regard to interfaces
+
Date: Fri, 7 Feb 2014 13:44:42 +0000
+
+
Sam Hartman writes ("Bug#727708: Please clarify L options with regard to interfaces"):
+> * Colin said that it would be OK to depend on a stable interface such as
+>   logind-208 provided that multiple implementations could exist.
+
+Colin, I think you need to clarify this.  I think it matters very much
+whether multiple implementations _do_ exist.
+
+> * Ian said that this dependency would not be OK.
+> 
+> I'd like the ballot options to clarify:
+> 
+> 1) Whether these interface dependencies are acceptable
+
+I don't have an opinion on the technical implementation details such
+as dependencies.
+
+> 2) Whether they are acceptable in cases where there is only one
+> implementation.
+
+My view on that is "no".  The key question for me is whether it is
+actually possible to use a different init system.
+
+> I'd request the TC consider the following question although I'm not sure
+> going into this level of detail on the ballot is appropriate:
+
+The TC ballot texts at the moment talk about "require", not about
+dependencies.  So it doesn't matter whether a requirement is declared
+as a dependency, and if so exactly what the form of that dependency
+is.  Likewise it doesn't matter whether the dependency (if there is
+one) is direct or indirect.
+
+> 3) If we are using virtual packages to define interfaces, what should
+> the dependency look like?  Would you want a raw virtual dependency such
+> as gnome-shell depends on logind-208?  If so, isn't that kind of not how
+> we currently recommend things?  Or a concrete dependency like
+> systemd|logind-208?  If so, please make sure that if such interface
+> dependencies are permitted your policy text actually permits the
+> dependency.
+
+I don't think the exact form of the dependency matters very much.  I'm
+not sure I understand why you think the difference here is important.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 13:48:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 13:48:13 GMT) (full text, mbox, link).

+ +

Message #5927 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 13:45:03 +0000
+
+
On Fri, Feb 07, 2014 at 12:04:20AM +0200, Adrian Bunk wrote:
+> I am not sure whether Colin is aware that it currently depends on him 
+> whether or not DT can win - and whether that might make him consider 
+> changing his vote.
+> 
+> If Ian convinces Colin to change his vote to move DT from 5. to 7. on 
+> his ballot, then DT cannot pass FD and is dead.
+
+I have been intentionally trying not to do the Condorcet analysis,
+because I consider tactical voting of that kind to be borderline
+dishonest.  As it is, I'm far from a voting systems expert and I have to
+go to considerable effort to work this sort of thing out, making me
+safer against any impulses I might develop to manipulate things.  So I
+would actually appreciate it if people did not try to make me aware of
+these things.  (I will now try to burn the brain cells involved in
+writing this paragraph. :-) )
+
+When deciding my vote, I was trying to bear in mind that decision
+paralysis has its own costs to the project: further discussion is not
+automatically the safe status quo that it might be in other situations.
+Thus, I mainly ranked those options below FD which I considered not to
+make enough useful progress, so that we would be very likely to simply
+end up back here in a short period of time.  For me, I consider DT (and
+for that matter UT) to be a significantly less than ideal compromise;
+among other things I don't think it provides enough safeguards against
+various kinds of fracturing of the distribution.  But it also doesn't
+exclude (what I think of as) better outcomes, and it gets us past this
+divisive and exhausting debate and lets us move to a default init which
+is better than we have now even if it isn't my preferred one.  So,
+taking this into consideration, I placed it barely above FD, and I think
+I'd do the same in future votes on similar sets of options.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 13:48:16 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sam Hartman <hartmans@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 13:48:16 GMT) (full text, mbox, link).

+ +

Message #5932 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sam Hartman <hartmans@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Anthony Towns <aj@erisian.com.au>, Adrian Bunk <bunk@stusta.de>, Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 07 Feb 2014 08:46:25 -0500
+
+
>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+    Ian> Anthony Towns writes ("Re: Bug#727708: Call for votes on init
+    Ian> system resolution"):
+    >> It's really pretty terrible to actively use FD to try to block
+    >> options that aren't your favourite. Honestly, I would have
+    >> expected the tech ctte to be able to come to a consensus on a set
+    >> of proposals considered reasonable by all the members, and accept
+    >> whatever a majority decided. I'd certainly hope that tech ctte
+    >> members won't tactically change their vote to try to hack the
+    >> process.
+
+I'm a bit confused by this.  i've always thought ranking options you
+consider bad enough that you'd rather have another option to work with
+people and discuss the options than see that option pass.  I think by
+ranking FD above something you dislike, you should commit to actively
+participate in a discussion if FD wins.
+However, "I think this option is unacceptable, and so I'd rather discuss
+more than decide it," seems like an entirely reasonable use of FD, not
+something terrible at all.
+
+I find the votes expressed by TC members entirely consistent with their
+stated verbal positions, and if anything people seem to be using FD
+conservatively, probably indicating a strong desire to be done with this
+process.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 13:51:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 13:51:10 GMT) (full text, mbox, link).

+ +

Message #5937 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 13:48:38 +0000
+
+
Nikolaus Rath writes ("Bug#727708: Call for votes on init system resolution"):
+> It is not at all clear to me why the CTTE so desperately wants to
+> automatically defer to a GR in their resolution. If there is consensus
+> to defer to a GR with simple majority among the CTTE, surely it would be
+> easy enough to revoke or change the resolution if/when a GR has actually
+> happened?
+
+Firstly, it is much easier to get consensus on this in the TC now
+while the question of in which direction such a GR might want to
+override the TC is far from clear.  Doing it now avoids the danger of
+backsliding.
+
+Secondly, I think it's undesirable to have any period of time during
+which a GR's decision would not have de jure authority.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 13:51:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 13:51:13 GMT) (full text, mbox, link).

+ +

Message #5942 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: [OFFLIST] - Possible trap to be avoided
+
Date: Fri, 7 Feb 2014 13:50:17 +0000
+
+
Mike Bird writes ("[OFFLIST] - Possible trap to be avoided"):
+> > So for the avoidance of doubt, we would put this into the TC
+> > resolution:
+> >
+> >   If the project passes by a General Resolution, a "position statement
+> >   about issues of the day", on the subject of init systems, the views
+> >   expressed in that position statement entirely replace the substance
+> >   of this TC resolution; the TC hereby adopts any such position
+> >   statement as its own decision.
+> 
+> To avoid leaving an unexploded bomb for future generations when the issues
+> revolving around init systems may be entirely different I suggest you apply
+> a (generous) time limit to this - maybe six months.
+
+Mike, I hope you won't mind me replying in public.
+
+You are entirely right.  I intend to add a sentence saying "before the
+release of jessie", which I think ought to be about the right time
+limit.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 13:57:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 13:57:14 GMT) (full text, mbox, link).

+ +

Message #5947 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Sam Hartman <hartmans@debian.org>, + 727708@bugs.debian.org
+
Cc: Anthony Towns <aj@erisian.com.au>, + Adrian Bunk <bunk@stusta.de>, + Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 13:55:01 +0000
+
+
Sam Hartman writes ("Bug#727708: Call for votes on init system resolution"):
+> [some quoted stuff]
+>
+> I'm a bit confused by this.
+
+To be clear, none of the quoted text is from me.
+
+> I find the votes expressed by TC members entirely consistent with their
+> stated verbal positions, and if anything people seem to be using FD
+> conservatively, probably indicating a strong desire to be done with this
+> process.
+
+Indeed so.  There are options that I consider unacceptable.
+
+Normally I would rank such options below FD and be done with it,
+because I felt that failing to make a decision would be worse than
+that decision.
+
+But in this case we really desperately need to move on.  Hence the
+presence of GR.  If the TC really is deadlocked, then GR ought to win.
+
+So I intend to vote
+  [acceptable options], GR, FD, [unacceptable options]
+I don't expect many TC members to vote FD above GR.  So when we do the
+vote (and don't try to cancel it) I expect a result, even if it's only GR.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 14:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 14:00:05 GMT) (full text, mbox, link).

+ +

Message #5952 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: [OFFLIST] - Possible trap to be avoided
+
Date: Fri, 7 Feb 2014 13:58:05 +0000
+
+
Ian Jackson writes ("Bug#727708: [OFFLIST] - Possible trap to be avoided"):
+> Mike, I hope you won't mind me replying in public.
+> 
+> You are entirely right.  I intend to add a sentence saying "before the
+> release of jessie", which I think ought to be about the right time
+> limit.
+
+I have now done this in git.
+
+I should say that I have come round to the view that the constitution
+ought to be amended to remove the 2:1 majority requirement for
+overruling the TC.  But that's a separate matter.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 14:09:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 14:09:10 GMT) (full text, mbox, link).

+ +

Message #5957 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Kurt Roeckx <kurt@roeckx.be>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 14:04:42 +0000
+
+
Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
+> I would really like it that you indicated under which power the
+> CTTE is making decisions, and the majority requirements that go
+> with that the options, for all your votes.
+
+I have added the following texts to the drafts in git:
+
++  == introduction (all versions except GR) ==
++
++     We exercise our powers to set technical policy (Constitution 6.1.1)
++     and decide in cases of overlapping jurisdiction (6.1.2):
+
+and
+
+   == version GR (General Resolution) ==
+
+      The Technical Committee requests that the project decide the
+      default init system for jessie by means of General Resolution.
+
++     (This is advice, pursuant to Constitution 6.1.5.)
+
+Does that seem satisfactory to you ?  If you think it's OK I don't
+expect any of the TC will object.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 14:27:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 14:27:14 GMT) (full text, mbox, link).

+ +

Message #5962 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 14:25:32 +0000
+
+
On Thu, Feb 06, 2014 at 11:25:02PM -0800, Russ Allbery wrote:
+> L makes it less likely that Debian will support anything other than the
+> default init system in the long run because it undermines the process of
+> adding native configuration for non-default init systems.  If we said that
+> packages are required to support the default init system and strongly
+> encouraged to merge support for those with active communities, I think we
+> still wouldn't get 100% archive coverage for the non-default, but I do
+> think we'd get coverage for most or all of the packages that people using
+> the non-default init system care the most about.  That would probably be
+> in the form of native configurations for the init systems that people care
+> about, since all the native configurations are simpler and easier to
+> maintain than sysvinit scripts.  Packages would then depend on the set of
+> init systems that they support.  I think that's about the best solution we
+> can hope for in the long run: strong support for the default init system,
+> and workable but incomplete support for the other init systems, with clear
+> indication in the package dependency structure of what init systems are
+> supported.
+
+I do think it's bizarre that we seem to have ended up with coupling
+options that don't treat the default init system differently.  This
+makes no sense to me, for *either* T or L.  Unfortunately I was severely
+backlogged at the point when this was being thrashed out, and I'm not
+confident that I follow the reasoning that led to them being drafted in
+a way that's entirely agnostic of the default, which is why I haven't
+proposed anything else.
+
+My reasoning about the probable effects of L is much more based on
+jessie than the long run.  Given that, I don't agree with your reasoning
+because I think the injunction to avoid tying higher-level packages to a
+specific init system carries more force than the effects of sysvinit
+inertia possibly outweighing the activity levels of the various init
+system communities; there's still plenty of motivation for those
+communities to flesh out native support.  For jessie, I'm not sure I see
+any practical difference between L as currently drafted and your
+suggestion of "required to support default init system, strongly
+encouraged to merge support for other active ones"; these seem likely to
+be identical in practice for jessie with sysvinit support still around.
+In the long run, I can see your point; but (a) I don't think we should
+be attempting to rule on the long run now anyway (see below) and (b)
+it's not as if we can't develop new policies to suit changed
+circumstances.
+
+Part of my concern with T is that it's so mealy-mouthed.  "Where
+feasible", "should", "encouraged", etc.  By contrast, L is a bit
+heavy-handed.  It sounds like we may share some common goals between
+these, and maybe if we want those to stick properly we need to state
+those more explicitly rather than using proxies.  Do we agree, for
+instance, that we want it to be possible to run Debian's major desktop
+environments with any of the init systems with communities active in
+developing support for them?
+
+Your comments about the package dependency structure make sense to me in
+the long term.  Where I'm going with my support for L is something like
+the zero-one-infinity rule: if a non-init-system package only supports
+one system (natively or otherwise, and excluding obvious hacks like
+packaging a -dev version of the same system), that may well indicate a
+degree of inflexibility, whereas a package that supports more than one
+is probably not hard to extend to others.
+
+> Neither T nor L actually imply what I think will happen in practice.  The
+> T option gives explicit blessing to adding dependencies on non-default
+> init systems, which I think is something that's only appropriate on a
+> case-by-case basis for edge packages and cooperating package groups and
+> isn't appropriate general advice.  It also doesn't distinguish between
+> right now and after the jessie release, which I think is inappropriate.
+
+Agreed on both counts.  I understand why Ian (was it?) wanted to have
+the "multiple init systems for the foreseeable future" text, as a
+statement of general intent, and I don't disagree with that.  But I
+would prefer if the specifics ("Therefore, for jessie and later
+releases:") were marked simply as "Therefore, for jessie:".  That seems
+to dispose of part of your objection to L.
+
+I get that people want to dispose of this so we never have to consider
+it again, and that we want to provide more certainty of direction; but I
+honestly don't think we should be trying to do that.  As people have
+been saying in other contexts, the probability space collapses quite a
+bit following this decision; with a year of subsequent development the
+proper long-term approach will be much clearer.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 14:33:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 14:33:09 GMT) (full text, mbox, link).

+ +

Message #5967 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: init system decision timetable
+
Date: Fri, 7 Feb 2014 14:29:41 +0000
+
+
I think we need to set a timetable and a process that we can adhere
+to, so that the process doesn't drag on indefinitely but so that
+no-one is caught by surprise.  We have aborted this twice and I don't
+want to do it a third time.  The solution to procedural cockup is
+additional formality.
+
+So, I think the right process is this:
+
+ * We set a date which is the earliest point at which a vote may be
+   called.
+
+ * Some TC member formally proposes some set of L options.  This
+   should be the staunchest proponent of L, which I think is probably
+   me.  That starts the constitutional discussion period.
+
+   (The U-D-V-O options are simple enough that we can just put them
+   all on and we don't have to argue about the wording.)
+
+ * Some TC member in favour of T formally proposes a set of T options.
+   (It is necessary for this to be a proponent of T, so that suggested
+   amendments which allegedly improve T are judged, and accepted or
+   not, by a proponent of T, not by me.)
+
+   As Russ is probably the staunchest proponent of T I suggest that he
+   should take on this role.
+
+ * TC member(s) who think the resolution can be improved, or does not
+   represent their views, work to try to find better wording.  That
+   might include talking to people on IRC to sound them out, or a
+   formal meeting such as Don proposes.
+
+ * TC member(s) who think that they have wording that needs to be on
+   the ballot formally propose it by 24h before the earliest CFV date.
+
+ * 24h before the earliest CFV date, someone (I'm volunteering) will
+   prepare a draft ballot representing all of the proposals,
+   amendments etc. and make a Last Call.  During the following 24h
+   objections will be limited to the question of whether the draft
+   ballot accurate represents the proposals which have been formally
+   made and no-one will make additional formal proposals.
+
+ * After the time of the earliest CFV date, anyone is entitled to
+   start a vote on the wording(s) that remain proposed and not
+   withdrawn.  We may delay the CFV to try to persuade other TC
+   members to withdraw or accept amendments.
+
+I propose the following schedule:
+
+ * Initial formal proposals made: ASAP.
+
+ * Ballot draft Last Call: 1800 UTC Monday the 17th of February.
+
+ * Call for Votes: Any time after 1800 UTC Tuesday the 18th.
+
+I don't think anyone can seriously object that this schedule is too
+aggressive, in the context of what we've had before.  Conversely any
+earlier schedule would involve less than a week's formal discussion
+period, or the Last Call period taking place over the weekend.
+
+I am now going to press ahead with the first steps in this schedule.
+
+
+If anyone jumps the gun on this schedule by calling for votes early
+and without gettign consensus the list, I think TC members who agree
+with my proposed schedule should rank FD first.
+
+If you think this schedule is wrong you will need to convince your
+fellow TC members to (a) vote FD on the 3rd CFV, to postpone again; or
+(b) refrain from voting FD on an earlier CFV.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 14:42:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cyril Brulebois <kibi@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 14:42:09 GMT) (full text, mbox, link).

+ +

Message #5972 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cyril Brulebois <kibi@debian.org>
+
To: Colin Watson <cjwatson@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, + Kurt Roeckx <kurt@roeckx.be>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 17:39:34 +0300
+
+
[Message part 1 (text/plain, inline)]
+
Colin Watson <cjwatson@debian.org> (2014-02-05):
+> The only people who might reasonably be described as vaguely current
+> maintainers of parts of d-i whom I can immediately find on a quick
+> scan of the early parts of this bug are Wouter and myself; Tollef also
+> contributed a good deal in the past, and I may have missed one or two.
+> But I don't think any of these people have been acting as d-i
+> maintainers here.  People like Cyril and Christian, who would be more
+> obvious candidates for such a label, have not commented on this bug.
+
+I'd like to mention a few things:
+ - TC's opinion (not d-i people's) was queried by Paul.
+ - d-i maintainers were neither asked anything, or put in the loop at
+   any point.
+ - Given the incredible amount of mails on that bug, I think it's quite
+   reasonable not to expect us to jump into that train out of the blue,
+   especially uninvited. (I've been pointed at this subthread, I could
+   have entirely missed it otherwise.)
+
+If you have any question for -boot@, please send a mail there. If you
+want some input from either Christian or me, please cc us to ensure we
+don't miss that mail.
+
+Mraw,
+KiBi.
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 14:42:20 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zack Weinberg <zackw@panix.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 14:42:20 GMT) (full text, mbox, link).

+ +

Message #5977 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zack Weinberg <zackw@panix.com>
+
To: 727708@bugs.debian.org
+
Subject: Resolve impasse by focusing on requirements for smooth upgrade
+
Date: Fri, 07 Feb 2014 09:41:18 -0500
+
+
At the risk of being yet another unhelpful member of the peanut gallery, 
+I believe I see a way to resolve the impasse regarding the "T" and "L" 
+options on the previous draft resolution.  I'm not a DD but I have used 
+unstable as my principal desktop OS since 1998, I've administered a 
+handful of server machines running Debian, and for a couple years circa 
+2008 I was the sponsored maintainer of a package that contained an init 
+script, so I feel I have a pretty solid handle on relevant bits of how 
+Debian is put together.
+
+It is my impression, from reading this discussion to date, that no one 
+is arguing about which init system should be the default anymore; the 
+current impasse is, as far as I can tell, entirely about the extent to 
+which other packages should be allowed to depend (either at runtime, or 
+as a package relationship) on a specific init system.  And I think this 
+particular argument is as unresolvable as it is because, fundamentally, 
+it's an argument about software that has yet to be written!
+
+Consider GNOME, for example: as best I can tell, upstream has made the 
+reasonable-from-their-perspective decision to rely on D-Bus APIs which 
+*could* be provided by anyone, but at present, are only provided by 
+systemd (the project).  People have made various assertions about how 
+difficult it would be to port the necessary systemd components to run 
+with some other init system, or to create independent compatible 
+implementations, but *no one has actually done that yet*, and we don't 
+know for sure that anyone will.  Contrariwise, people have also made 
+assertions about how hard it would be to port upstart to the Hurd, add 
+features to OpenRC until it's a serious contender for the default, etc., 
+but again, it hasn't been done yet and we don't know if it will be. The 
+"right" policy for what non-init packages and ports should do is going 
+to look very different if some of that work gets done versus if it never 
+happens.
+
+What we *can* know right now, though, is what we're going to have to do 
+to ensure a smooth upgrade from wheezy.  We can know this because it 
+doesn't change very much depending on that extra work that gets done; 
+the huge installed base of systems booted by sysvinit puts a limit on 
+the scope of the change.  We have lots and lots of collective experience 
+with thorny upgrades involving replacing or reorganizing major 
+components of the system, so we know how to write policies in support of 
+such upgrades.  Moreover, a smooth upgrade experience is (I do most 
+earnestly hope) something everyone involved agrees we must have, so 
+requirements clearly grounded in that goal should have no trouble 
+achieving consensus.
+
+Based on my own experience, I would like to put forward a suggested 
+outline for a resolution that focuses on this goal:
+
+----
+
+Having been asked to decide the issue, the TC hereby resolves that:
+
+1a. The default init for new installations of jessie architectures based 
+on the Linux kernel should be [ systemd / upstart / decided by GR ].
+
+1b. The default init for new installations of jessie architectures based 
+on other kernels should be decided by the porters for those kernels.
+
+In order to ensure smooth upgrades from wheezy to jessie, and in order 
+to facilitate testing and experimentation with init systems which are 
+new to Debian in the jessie cycle, the TC also makes the following 
+recommendations for Policy:
+
+2a. All init systems shipped in a specific architecture must be 
+simultaneously installable.  Naturally, only one of them will be active 
+at a time on any given installation.
+
+2b. No package may, merely by being installed or upgraded, cause the 
+active init to change.
+
+2c. All init systems in Debian must support a common mechanism (similar 
+in spirit to /etc/alternatives) whereby the administrator of a 
+particular installation can change the active init.  This change may, if 
+necessary, require a reboot.
+
+3. Packages that require functionality provided by only some of the init 
+systems in Debian may declare a package dependency on those init systems 
+in the normal manner.  However, as this package dependency will not (per 
+2b) cause the requested init to become *active*, all such packages must 
+cope at runtime with the active init not being the one they want. 
+Failure to do so shall be considered a bug, but the severity of this bug 
+shall be determined on a case-by-case basis: in particular, such bugs 
+are not necessarily release-critical, and may even be 'wishlist'.
+
+4. In jessie, all packages which configure some init system to start 
+daemons (however this may be accomplished) MUST also include a sysvinit 
+script to the same effect.  Maintainers of packages providing daemons 
+are strongly encouraged to include appropriate configuration for all 
+supported init systems.
+
+The TC anticipates that this decision is likely to need to be 
+substantially revised post-jessie, and hereby delegates authority to do 
+so for (1) to the d-i maintainers, and (2-4) to the Policy maintainers.
+
+----
+
+Thank you for your consideration.
+zw
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 14:42:22 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 14:42:23 GMT) (full text, mbox, link).

+ +

Message #5982 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 14:41:39 +0000
+
+
Colin Watson writes ("Bug#727708: Call for votes on init system resolution"):
+> Agreed on both counts.  I understand why Ian (was it?) wanted to have
+> the "multiple init systems for the foreseeable future" text, as a
+> statement of general intent, and I don't disagree with that.  But I
+> would prefer if the specifics ("Therefore, for jessie and later
+> releases:") were marked simply as "Therefore, for jessie:".  That seems
+> to dispose of part of your objection to L.
+
+I'm afraid that I would be categorically opposed to that change.  That
+would relegate L to a mere transitional provision.  
+
+I think making the commitment to diversity a long-term intention is
+critically important.
+
+> I get that people want to dispose of this so we never have to consider
+> it again, and that we want to provide more certainty of direction; but I
+> honestly don't think we should be trying to do that.  As people have
+> been saying in other contexts, the probability space collapses quite a
+> bit following this decision; with a year of subsequent development the
+> proper long-term approach will be much clearer.
+
+My fear is that without the clear statement in favour of diversity,
+long-term, those who do not think diversity is important will continue
+to create additional technical obstacles.
+
+As a result our freedom of action will be constrained even more then
+than it has been now.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 14:48:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 14:48:19 GMT) (full text, mbox, link).

+ +

Message #5987 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: init system formal proposal (round 3)
+
Date: Fri, 7 Feb 2014 14:46:22 +0000
+
+
Ian Jackson writes ("Bug#727708: init system decision timetable"):
+>  * Some TC member formally proposes some set of L options.  This
+>    should be the staunchest proponent of L, which I think is probably
+>    me.  That starts the constitutional discussion period.
+
+I therefore hereby propose the options UL,DL,OL,VL and GR
+from the resolution text below.
+
+As the proponent of *L I am acting as a committed advocate of
+diversity and loose coupling.  I'm open to clarifications and
+improvements but will resist dilution.
+
+As the proponent of GR I will act as a neutral steward to try to
+achieve the best wording.
+
+Ian.
+
+(Text below is from the git repo with the T dependencies rider
+deleted.  I'm expecting Russ to propose some set of T option(s) with a
+text of his choosing.  If the T text Russ writes isn't what is in git,
+I will transfer it there.)
+
+== introduction (all versions except GR) ==
+
+   We exercise our powers to set technical policy (Constitution 6.1.1)
+   and decide in cases of overlapping jurisdiction (6.1.2):
+
+== version D (systemD) ==
+
+   The default init system for Linux architectures in jessie should
+   be systemd.
+
+== version U (Upstart) ==
+
+   The default init system for Linux architectures in jessie should
+   be upstart.
+
+== version O (Openrc) ==
+
+   The default init system for Linux architectures in jessie should
+   be openrc.
+
+== version V (sysVinit) ==
+
+   The default init system for Linux architectures in jessie should
+   be sysvinit (no change).
+
+== version GR (General Resolution) ==
+
+   The Technical Committee requests that the project decide the
+   default init system for jessie by means of General Resolution.
+
+   (This is advice, pursuant to Constitution 6.1.5.)
+
+== clarification text for all versions except GR ==
+
+   This decision is limited to selecting a default initsystem for
+   jessie.  We expect that Debian will continue to support multiple
+   init systems for the foreseeable future; we continue to welcome
+   contributions of support for all init systems.
+
+   Therefore, for jessie and later releases:
+
+== dependencies rider version L (Loose coupling) ==
+
+   Software outside of an init system's implementation may not require
+   a specific init system to be pid 1, although degraded operation is
+   tolerable.
+
+   Maintainers are encouraged to accept technically sound patches
+   to enable improved interoperation with various init systems.
+
+== rider for all versions except GR ==
+
+   If the project passes (before the release of jessie) by a General
+   Resolution, a "position statement about issues of the day", on the
+   subject of init systems, the views expressed in that position
+   statement entirely replace the substance of this TC resolution; the
+   TC hereby adopts any such position statement as its own decision.
+
+   Such a position statement could, for example, use these words:
+
+      The Project requests (as a position statement under s4.1.5 of the
+      Constitution) that the TC reconsider, and requests that the TC
+      would instead decide as follows:
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 14:51:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 14:51:10 GMT) (full text, mbox, link).

+ +

Message #5992 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Please clarify L options with regard to interfaces
+
Date: Fri, 7 Feb 2014 14:49:45 +0000
+
+
On Fri, Feb 07, 2014 at 01:44:42PM +0000, Ian Jackson wrote:
+> Sam Hartman writes ("Bug#727708: Please clarify L options with regard to interfaces"):
+> > * Colin said that it would be OK to depend on a stable interface such as
+> >   logind-208 provided that multiple implementations could exist.
+> 
+> Colin, I think you need to clarify this.  I think it matters very much
+> whether multiple implementations _do_ exist.
+
+There are three cases here:
+
+ 1) direct dependency on init system, no attempt to make allowances
+ 2) dependency on reasonably-understood/specified interface that happens
+    to have only one implementation right now
+ 3) dependency on interface with multiple implementations
+
+I think Ian and I are agreed that L excludes 1), and permits 3).  On
+reflection I think I agree that L has to exclude 2) as well.
+
+However, the specific question Ansgar asked me was about logind
+(presumably >> 204).  Serge Hallyn's cgmanager work appears to me to be
+far enough along that this is likely to progress to 3) soon enough, and
+well before jessie.
+
+In the event that nobody gets logind working with cgmanager in the next
+few months, I appreciate that I may have to eat my words.  As a
+practical matter, I certainly don't think it's appropriate to hold back
+logind integration forever.  I just don't think that's a likely outcome
+given the work in progress.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 14:54:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to 727708@bugs.debian.org:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 14:54:14 GMT) (full text, mbox, link).

+ +

Message #5997 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Steve Langasek Must Not Vote
+
Date: Fri, 07 Feb 2014 11:44:02 -0300
+
+
[Message part 1 (text/plain, inline)]
+
With all the due respect to Steve, considering the fact that he is a very 
+involved contributor of Upstart and judging from his position on this subject, 
+I also think he should step down from participating as a TC member in this 
+specific issue.
+
+-- 
+
+Lisandro Damián Nicanor Pérez Meyer
+http://perezmeyer.com.ar/
+http://perezmeyer.blogspot.com/
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 14:54:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 14:54:17 GMT) (full text, mbox, link).

+ +

Message #6002 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: Cyril Brulebois <kibi@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 14:52:24 +0000
+
+
On Fri, Feb 07, 2014 at 05:39:34PM +0300, Cyril Brulebois wrote:
+> Colin Watson <cjwatson@debian.org> (2014-02-05):
+> > The only people who might reasonably be described as vaguely current
+> > maintainers of parts of d-i whom I can immediately find on a quick
+> > scan of the early parts of this bug are Wouter and myself; Tollef also
+> > contributed a good deal in the past, and I may have missed one or two.
+> > But I don't think any of these people have been acting as d-i
+> > maintainers here.  People like Cyril and Christian, who would be more
+> > obvious candidates for such a label, have not commented on this bug.
+> 
+> I'd like to mention a few things:
+>  - TC's opinion (not d-i people's) was queried by Paul.
+>  - d-i maintainers were neither asked anything, or put in the loop at
+>    any point.
+
+Just to clarify things, I wasn't criticising you or anyone else in d-i
+for not contributing to this bug, either directly or by implication;
+just stating a fact in response to the earlier confusion.
+
+>  - Given the incredible amount of mails on that bug, I think it's quite
+>    reasonable not to expect us to jump into that train out of the blue,
+>    especially uninvited.
+
+I think this is indeed entirely appropriate.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 15:03:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 15:03:14 GMT) (full text, mbox, link).

+ +

Message #6007 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Steve Langasek Must Not Vote
+
Date: Fri, 7 Feb 2014 09:59:20 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Feb 07, 2014 at 11:44:02AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
+> With all the due respect to Steve, considering the fact that he is a very 
+> involved contributor of Upstart and judging from his position on this subject, 
+> I also think he should step down from participating as a TC member in this 
+> specific issue.
+
+While Steve not voiting means I get the init system I want, I don't
+think that's entirely fair to do.
+
+I trust the TC and Steve to know when is right to recuse themselves, and
+I have no reason to believe that Steve is acting in a way that puts
+anything but the technical well-being of Debian first.
+
+Much love,
+  Paul
+
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
+: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+`. `'`  http://people.debian.org/~paultag
+ `-     http://people.debian.org/~paultag/conduct-statement.txt
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 15:06:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 15:06:05 GMT) (full text, mbox, link).

+ +

Message #6012 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Steve Langasek Must Not Vote
+
Date: Fri, 7 Feb 2014 15:03:56 +0000
+
+
Lisandro Damián Nicanor Pérez Meyer writes ("Bug#727708: Steve Langasek Must Not Vote"):
+> With all the due respect to Steve, considering the fact that he is a very 
+> involved contributor of Upstart and judging from his position on this subject, 
+> I also think he should step down from participating as a TC member in this 
+> specific issue.
+
+This issue has been discussed at length already.  After discussion and
+with agreement from the rest of the project Steve is not going to
+recuse himself from this issue.
+
+Please would no-one send any more messages along these lines.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 15:09:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Stephen Frost <sfrost@snowman.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 15:09:14 GMT) (full text, mbox, link).

+ +

Message #6017 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Stephen Frost <sfrost@snowman.net>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Steve Langasek Must Vote
+
Date: Fri, 7 Feb 2014 09:58:02 -0500
+
+
[Message part 1 (text/plain, inline)]
+
* Lisandro Damián Nicanor Pérez Meyer (lisandro@debian.org) wrote:
+> With all the due respect to Steve, considering the fact that he is a very 
+> involved contributor of Upstart and judging from his position on this subject, 
+> I also think he should step down from participating as a TC member in this 
+> specific issue.
+
+I don't agree with this.  I have no reason to doubt Steve's ability to
+do the right thing for Debian.  Being a contributor to one means that
+he's in a position to actually understand the issues better than most.
+Additionally, I think this approach to voting ("if you've ever been
+involed with X then you can't vote on it") would quickly run us out of
+competent people available to cast votes.
+
+	Thanks,
+
+		Stephen
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 15:15:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 15:15:09 GMT) (full text, mbox, link).

+ +

Message #6022 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 15:11:45 +0000
+
+
On Fri, Feb 07, 2014 at 02:41:39PM +0000, Ian Jackson wrote:
+> Colin Watson writes ("Bug#727708: Call for votes on init system resolution"):
+> > Agreed on both counts.  I understand why Ian (was it?) wanted to have
+> > the "multiple init systems for the foreseeable future" text, as a
+> > statement of general intent, and I don't disagree with that.  But I
+> > would prefer if the specifics ("Therefore, for jessie and later
+> > releases:") were marked simply as "Therefore, for jessie:".  That seems
+> > to dispose of part of your objection to L.
+> 
+> I'm afraid that I would be categorically opposed to that change.  That
+> would relegate L to a mere transitional provision.  
+> 
+> I think making the commitment to diversity a long-term intention is
+> critically important.
+
+OK.  So I agree that long-term commitment to diversity is important.  I
+just don't necessarily agree that the way in which we do so will stay
+the same.  For jessie, this amounts to keeping sysvinit support around,
+having sufficient non-systemd support available for recent logind and
+other new features required by major desktop environments, and not
+having a dependency structure such that people end up having to install
+a specific init system just in order to keep their systems working.
+
+For later releases, it's not clear to me that we will have the same
+constraints.  We might reasonably expect sysvinit support to be less
+important, and there are various ways in which diversity criteria could
+be met.  It is for example possible that some new feature of systemd
+might have a compatible implementation directly in upstart's pid 1
+rather than externally.  It's not clear where that sort of thing would
+sit relative to L: it wouldn't require *a* specific init system, but it
+might exclude some; on the other hand, the presence of two compatible
+implementations of an interface should make us substantially more
+confident that more are possible, and so I don't think this
+automatically implies a lack of diversity.
+
+I think L needs to exclude that sort of thing for jessie as a practical
+matter of upgrade handling, but not necessarily for later releases.  But
+I don't feel comfortable with us drafting the details of the later parts
+of that now, when there are so many unknowns, and reasonable
+possibilities of compatible implementations being developed for the
+specific details that are currently sticking points.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 15:15:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 15:15:12 GMT) (full text, mbox, link).

+ +

Message #6027 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Steve Langasek Must Vote
+
Date: Fri, 7 Feb 2014 15:12:58 +0000
+
+
Stephen Frost writes ("Bug#727708: Steve Langasek Must Vote"):
+> I don't agree with this.  I have no reason to doubt Steve's ability to
+
+Please, also, no messages defending Steve's involvement.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 15:30:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sam Hartman <hartmans@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 15:30:19 GMT) (full text, mbox, link).

+ +

Message #6032 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sam Hartman <hartmans@debian.org>
+
To: Colin Watson <cjwatson@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Please clarify L options with regard to interfaces
+
Date: Fri, 07 Feb 2014 10:28:02 -0500
+
+
>>>>> "Colin" == Colin Watson <cjwatson@debian.org> writes:
+
+    Colin> I think Ian and I are agreed that L excludes 1), and permits
+    Colin> 3).  On reflection I think I agree that L has to exclude 2)
+    Colin> as well.
+
+Hmm, I am reading Ian as  against 3.
+
+I request that TC members work with Ian on the wording of L he has just
+proposed to make his stance clear.  For my part if the TC were to adopt
+DL or UL as Ian just proposed I would not actually understand what
+policy we had adopted.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 15:39:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sam Hartman <hartmans@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 15:39:09 GMT) (full text, mbox, link).

+ +

Message #6037 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sam Hartman <hartmans@debian.org>
+
To: 727708@bugs.debian.org
+
Cc: Colin Watson <cjwatson@debian.org>
+
Subject: Re: Bug#727708: Please clarify L options with regard to interfaces
+
Date: Fri, 07 Feb 2014 10:38:09 -0500
+
+
>>>>> "Sam" == Sam Hartman <hartmans@debian.org> writes:
+
+>>>>> "Colin" == Colin Watson <cjwatson@debian.org> writes:
+    Colin> I think Ian and I are agreed that L excludes 1), and permits
+    Colin> 3).  On reflection I think I agree that L has to exclude 2)
+    Colin> as well.
+
+    Sam> Hmm, I am reading Ian as against 3.
+
+I'm sorry, I missed the message that was a direct reply to me.
+
+I now understand Ian's position to mean that we must not require users
+to select a certain  init system for things to work.
+
+Sorry for the extra message and for reading out-of-order
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 15:48:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Didier 'OdyX' Raboud" <odyx@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 15:48:10 GMT) (full text, mbox, link).

+ +

Message #6042 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Didier 'OdyX' Raboud" <odyx@debian.org>
+
To: 727708@bugs.debian.org
+
Cc: secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
+
Date: Fri, 07 Feb 2014 16:43:33 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Hi Kurt,
+
+Le jeudi, 6 février 2014, 21.19:36 Kurt Roeckx a écrit :
+> On Thu, Feb 06, 2014 at 08:38:25PM +0100, Kurt Roeckx wrote:
+> > I'm guessing that under you're asking for the interpretation of
+> > 
+> > this in 6.1.1:
+> > | In each case the usual maintainer of the relevant software or
+> > | documentation makes decisions initially
+> > 
+> > And think that because the policy maintainers didn't try to make
+> > any decision yet, the ctte can't make that decisions?
+
+Yes. I stand to this interpretation, see below.
+
+> I'm currently of the opinion that gnome made an initial decisions
+> and as reaction to that they are setting policy and that this will
+> be allowed under 6.1.1.
+
+Back then, the gnome maintainers added a dependency on another package, 
+which happened to be providing an /sbin/init. This was allowed by the 
+Debian Policy of the time as well as by the Debian archive. The 
+maintainers of the Policy maintainers haven't tried to rule on this at 
+all since then. How is this matter now magically taken off the Policy 
+maintainers' hands (while it _is_ a matter of Policy) and become a 
+matter for the technical committee?
+
+I feel compelled to write that I'm quite concerned to see technical 
+committee members propose to rule on things they see fit, just because 
+it's sufficiently important to their eyes. As I detailed in 
+<1756169.he50hsLr7Y@gyllingar>, I'm quite firmly convinced that any 
+ruling restricting software dependencies fails §6.1.1 (as the powers 
+invoked), §6.3.5 and §6.3.6 at this point in time.
+
+OdyX
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 15:54:24 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 15:54:24 GMT) (full text, mbox, link).

+ +

Message #6047 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Sam Hartman <hartmans@debian.org>, + 727708@bugs.debian.org
+
Cc: Colin Watson <cjwatson@debian.org>
+
Subject: Re: Bug#727708: Please clarify L options with regard to interfaces [and 1 more messages]
+
Date: Fri, 7 Feb 2014 15:53:50 +0000
+
+
Sam Hartman writes ("Bug#727708: Please clarify L options with regard to interfaces"):
+> Hmm, I am reading Ian as  against 3.
+
+No, if there are multiple implementations then I am satisfied.  In
+practice I don't think the problem of implementations only
+non-overlapping subsets of init systems will arise.
+
+> I request that TC members work with Ian on the wording of L he has just
+> proposed to make his stance clear.  For my part if the TC were to adopt
+> DL or UL as Ian just proposed I would not actually understand what
+> policy we had adopted.
+
+So, in of your next message you say:
+
+Sam Hartman writes ("Bug#727708: Please clarify L options with regard to interfaces"):
+> I'm sorry, I missed the message that was a direct reply to me.
+> 
+> I now understand Ian's position to mean that we must not require users
+> to select a certain  init system for things to work.
+
+Precisely.
+
+> Sorry for the extra message and for reading out-of-order
+
+Are you now happy that with the meaning of L is clear enough ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 16:03:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 16:03:15 GMT) (full text, mbox, link).

+ +

Message #6052 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org, + secretary@debian.org
+
Subject: Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
+
Date: Fri, 7 Feb 2014 16:01:12 +0000
+
+
Kurt Roeckx writes ("Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)"):
+> I'm currently of the opinion that gnome made an initial decisions
+> and as reaction to that they are setting policy and that this will
+> be allowed under 6.1.1.
+
+It's clear that whether this kind of dependency is allowed is a key
+issue (perhaps even _the_ key issue) in this dispute.  The question of
+the default init system is in some ways a proxy for the coupling
+question.  And the extent and timing of such dependencies is clearly a
+matter that ought to be dealt with in the policy manual.  So it is
+definitely a matter of technical policy.
+
+Whether the matter is ripe for the TC is not something that I would
+expect the Secretary to rule on.  I think that's a matter for the TC.
+(The alternative would be to contemplate the TC making a decision on
+policy and the Secretary then stating that the TC decision was invalid
+and of no effect.)
+
+But even if it is for the Secretary to rule on, I hope that the
+Secretary will agree that it's clear that the question is ripe for a
+TC decision (if not wildly overdue).
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 16:45:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 16:45:09 GMT) (full text, mbox, link).

+ +

Message #6057 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Paul Hedderly <prh@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Please clarify L options with regard to interfaces [and + 1 more messages]
+
Date: Fri, 7 Feb 2014 16:43:59 +0000
+
+
Paul Hedderly writes ("Bug#727708: Please clarify L options with regard to interfaces [and 1 more messages]"):
+> Ian Jackson wrote:
+> > Sam Hartman writes ("Bug#727708: Please clarify L options with regard to interfaces"):
+> >> I now understand Ian's position to mean that we must not require users
+> >> to select a certain  init system for things to work.
+> 
+> > Precisely.
+> 
+> [ polemic ]
+
+This is not helpful.  No-one's mind is going to be changed on the key
+issues at this stage.  We are working on the details of drafting.
+
+> > Are you now happy that with the meaning of L is clear enough ?
+> 
+> Yes you have made your intentions quite clear.
+
+I was asking Sam Hartman who was raising a point about whether the L
+text needs clarification.  Your response has nothing to do with that.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 16:51:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ansgar Burchardt <ansgar@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 16:51:10 GMT) (full text, mbox, link).

+ +

Message #6062 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Fri, 07 Feb 2014 17:46:15 +0100
+
+
On 02/07/2014 17:01, Ian Jackson wrote:
+> Kurt Roeckx writes ("Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)"):
+>> I'm currently of the opinion that gnome made an initial decisions
+>> and as reaction to that they are setting policy and that this will
+>> be allowed under 6.1.1.
+> 
+> It's clear that whether this kind of dependency is allowed is a key
+> issue (perhaps even _the_ key issue) in this dispute.  The question of
+> the default init system is in some ways a proxy for the coupling
+> question.  And the extent and timing of such dependencies is clearly a
+> matter that ought to be dealt with in the policy manual.  So it is
+> definitely a matter of technical policy.
+> 
+> Whether the matter is ripe for the TC is not something that I would
+> expect the Secretary to rule on.  I think that's a matter for the TC.
+
+So you suggest to just ignore "In each case the usual maintainer of the
+relevant software or documentation makes decisions initially"?
+
+If you decide on the init system question first, you could just file a
+bug against debian-policy and things could go their usual way.
+Alternatively, the Policy maintainers could defer this decision to the
+technical committee under 6.1.3.
+
+> But even if it is for the Secretary to rule on, I hope that the
+> Secretary will agree that it's clear that the question is ripe for a
+> TC decision (if not wildly overdue).
+
+Can the Secretary decide that the second part of 6.1.1 is to be ignored?
+
+Ansgar
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 17:36:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sam Hartman <hartmans@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 17:36:20 GMT) (full text, mbox, link).

+ +

Message #6067 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sam Hartman <hartmans@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Please clarify L options with regard to interfaces [and 1 more messages]
+
Date: Fri, 07 Feb 2014 12:34:09 -0500
+
+
Yeah, I now understand what you mean by L.
+
+I'll be writing more in the form of a blog post and probably GR text.  I
+will send a pointer to the TC as I think I may be hitting close to
+something that  Russ may find useful.
+
+I'll refrain from trying to convince the TC because you have enough
+voices there.  If Russ or Colin find what I right captures some of what
+they are saying they can bring it into the discussion.  If not it only
+complicates an impossible mess for me to send lots of mail.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 17:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 17:51:05 GMT) (full text, mbox, link).

+ +

Message #6072 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Didier 'OdyX' Raboud <odyx@debian.org>
+
Cc: 727708@bugs.debian.org, secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler + (was: Re: Call for votes on init system resolution)
+
Date: Fri, 7 Feb 2014 18:47:51 +0100
+
+
On Fri, Feb 07, 2014 at 04:43:33PM +0100, Didier 'OdyX' Raboud wrote:
+> Hi Kurt,
+> 
+> Le jeudi, 6 février 2014, 21.19:36 Kurt Roeckx a écrit :
+> > On Thu, Feb 06, 2014 at 08:38:25PM +0100, Kurt Roeckx wrote:
+> > > I'm guessing that under you're asking for the interpretation of
+> > > 
+> > > this in 6.1.1:
+> > > | In each case the usual maintainer of the relevant software or
+> > > | documentation makes decisions initially
+> > > 
+> > > And think that because the policy maintainers didn't try to make
+> > > any decision yet, the ctte can't make that decisions?
+> 
+> Yes. I stand to this interpretation, see below.
+> 
+> > I'm currently of the opinion that gnome made an initial decisions
+> > and as reaction to that they are setting policy and that this will
+> > be allowed under 6.1.1.
+> 
+> Back then, the gnome maintainers added a dependency on another package, 
+> which happened to be providing an /sbin/init. This was allowed by the 
+> Debian Policy of the time as well as by the Debian archive. The 
+> maintainers of the Policy maintainers haven't tried to rule on this at 
+> all since then. How is this matter now magically taken off the Policy 
+> maintainers' hands (while it _is_ a matter of Policy) and become a 
+> matter for the technical committee?
+
+Do you agree that the ctte can decide policy?  Under what
+conditions?
+
+I think it all boils down to what "relevant software or
+documentation" means.
+
+> I feel compelled to write that I'm quite concerned to see technical 
+> committee members propose to rule on things they see fit, just because 
+> it's sufficiently important to their eyes. As I detailed in 
+> <1756169.he50hsLr7Y@gyllingar>, I'm quite firmly convinced that any 
+> ruling restricting software dependencies fails §6.1.1 (as the powers 
+> invoked), §6.3.5 and §6.3.6 at this point in time.
+
+About detailed design work: You could argue that they proposed the
+alternative solutions and aren't just deciding between them.  As
+far as I know those proposols come from the ctte itself, in which
+case it should probably go under 6.1.5 to give advice.
+
+About 6.3.6: I think trying to resolve this via consensus failed.
+
+Anyway, I'm still not sure.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 17:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 17:57:04 GMT) (full text, mbox, link).

+ +

Message #6077 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler + (was: Re: Call for votes on init system resolution)
+
Date: Fri, 7 Feb 2014 18:55:44 +0100
+
+
On Fri, Feb 07, 2014 at 04:01:12PM +0000, Ian Jackson wrote:
+> Kurt Roeckx writes ("Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)"):
+> > I'm currently of the opinion that gnome made an initial decisions
+> > and as reaction to that they are setting policy and that this will
+> > be allowed under 6.1.1.
+> 
+> It's clear that whether this kind of dependency is allowed is a key
+> issue (perhaps even _the_ key issue) in this dispute.  The question of
+> the default init system is in some ways a proxy for the coupling
+> question.  And the extent and timing of such dependencies is clearly a
+> matter that ought to be dealt with in the policy manual.  So it is
+> definitely a matter of technical policy.
+
+I don't think anybody is arguing that it's not technical policy.
+
+> Whether the matter is ripe for the TC is not something that I would
+> expect the Secretary to rule on.  I think that's a matter for the TC.
+> (The alternative would be to contemplate the TC making a decision on
+> policy and the Secretary then stating that the TC decision was invalid
+> and of no effect.)
+
+I think we all want to avoid that I have to retract the decision
+and so maybe it's best that we try to find the answer before the
+vote.  Anyway, I've already been asked about this, so I see little
+point in waiting.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 18:18:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 18:18:07 GMT) (full text, mbox, link).

+ +

Message #6082 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ansgar Burchardt <ansgar@debian.org>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Fri, 7 Feb 2014 10:14:23 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Feb 07, 2014 at 05:46:15PM +0100, Ansgar Burchardt wrote:
+> On 02/07/2014 17:01, Ian Jackson wrote:
+> > Kurt Roeckx writes ("Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)"):
+> >> I'm currently of the opinion that gnome made an initial decisions
+> >> and as reaction to that they are setting policy and that this will
+> >> be allowed under 6.1.1.
+
+> > It's clear that whether this kind of dependency is allowed is a key
+> > issue (perhaps even _the_ key issue) in this dispute.  The question of
+> > the default init system is in some ways a proxy for the coupling
+> > question.  And the extent and timing of such dependencies is clearly a
+> > matter that ought to be dealt with in the policy manual.  So it is
+> > definitely a matter of technical policy.
+
+> > Whether the matter is ripe for the TC is not something that I would
+> > expect the Secretary to rule on.  I think that's a matter for the TC.
+
+> So you suggest to just ignore "In each case the usual maintainer of the
+> relevant software or documentation makes decisions initially"?
+
+The TC has the authority to set technical policy.  The maintainers are
+empowered to interpret how that technical policy applies to their particular
+packages.  And the TC has the power to overrule the maintainers and tell
+them that their interpretation is incorrect.
+
+But the TC does not have to wait for a maintainer to take a decision they
+disagree with before they decide the technical policy in the abstract which
+may affect a maintainer's package.
+
+> If you decide on the init system question first, you could just file a
+> bug against debian-policy and things could go their usual way.
+> Alternatively, the Policy maintainers could defer this decision to the
+> technical committee under 6.1.3.
+
+The Policy maintainers are the maintainers of the policy document, they are
+not "maintainers of the relevant software" in this context.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 18:33:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 18:33:10 GMT) (full text, mbox, link).

+ +

Message #6087 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 19:29:30 +0100
+
+
On Fri, Feb 07, 2014 at 02:04:42PM +0000, Ian Jackson wrote:
+> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
+> > I would really like it that you indicated under which power the
+> > CTTE is making decisions, and the majority requirements that go
+> > with that the options, for all your votes.
+> 
+> I have added the following texts to the drafts in git:
+> 
+> +  == introduction (all versions except GR) ==
+> +
+> +     We exercise our powers to set technical policy (Constitution 6.1.1)
+> +     and decide in cases of overlapping jurisdiction (6.1.2):
+
+Could you instead add that to the individual options, so it's
+clear for which part of the text you use which power?
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 18:33:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Didier 'OdyX' Raboud" <odyx@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 18:33:13 GMT) (full text, mbox, link).

+ +

Message #6092 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Didier 'OdyX' Raboud" <odyx@debian.org>
+
To: 727708@bugs.debian.org
+
Cc: secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
+
Date: Fri, 07 Feb 2014 19:31:06 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Le vendredi, 7 février 2014, 18.47:51 Kurt Roeckx a écrit :
+> > Back then, the gnome maintainers added a dependency on another
+> > package, which happened to be providing an /sbin/init. This was
+> > allowed by the Debian Policy of the time as well as by the Debian
+> > archive. The maintainers of the Policy maintainers haven't tried to
+> > rule on this at all since then. How is this matter now magically
+> > taken off the Policy maintainers' hands (while it _is_ a matter of
+> > Policy) and become a matter for the technical committee?
+> 
+> Do you agree that the ctte can decide policy?  Under what
+> conditions?
+
+For the general question of deciding policy, I think the following 
+articles are relevant:
+
+* § 6.1.1 says "In each case the usual maintainer of the relevant (…) 
+documentation makes decisions initially"
+* § 6.3.6 says "Technical Committee makes decisions only as last resort"
+
+In the specific case of deciding what types of software requirements are 
+acceptable in Debian, which I think is of the responsibility of the 
+Policy team, then the tech-ctte can decide policy only if the Policy 
+team (aka maintainer of the relevant documentation) has made an initial 
+decision (6.1.1) or has delegated one of its decisions to the tech-ctte 
+(6.1.3).
+
+Any of the proposed L or S would certainly impose amendments of various 
+parts of the Debian Policy (I could think of 2.2.1, 3.5, and certainly 
+9.11); that makes them quite clearly of the Debian Policy Team realm. If 
+the decision could come in force through another way, that would be 
+through amending the definition of bug severities, but that would be 
+quite odd.
+
+> I think it all boils down to what "relevant software or
+> documentation" means.
+
+Clearly. L and S amend what software requirements are acceptable in 
+Debian, for which the only limit we've had until now was the DFSG and 
+the Debian Policy.
+
+> > I feel compelled to write that I'm quite concerned to see technical
+> > committee members propose to rule on things they see fit, just
+> > because it's sufficiently important to their eyes. As I detailed in
+> > <1756169.he50hsLr7Y@gyllingar>, I'm quite firmly convinced that any
+> > ruling restricting software dependencies fails §6.1.1 (as the powers
+> > invoked), §6.3.5 and §6.3.6 at this point in time.
+> 
+> About detailed design work: You could argue that they proposed the
+> alternative solutions and aren't just deciding between them. 
+
+Yes, that's what I'm saying.
+
+> As far as I know those proposols come from the ctte itself, in which
+> case it should probably go under 6.1.5 to give advice.
+
+I'd be totally fine with the tech-ctte giving advice under 6.1.5. In 
+this case it should only be formulated _as_ an advice, such as:
+
+	"We think that software outside of an init system'simplementation
+	 should not require a specific init system to be pid 1, although
+	 degraded operation would be tolerable."
+
+That would be clearly non-binding.
+
+> About 6.3.6: I think trying to resolve this via consensus failed.
+
+I agree that attempts at deciding about the default init via consensus 
+failed, and I am definitely looking forward to a decision, it's long 
+due.
+
+I disagree that attempts at deciding what software requirements with 
+regards to init systems are acceptable in Debian have failed: I don't 
+think they have started at all in the forum where they should have: the 
+Policy Team. (It's probably because in the absence of a decision, 
+there's not much to discuss yet!)
+
+Finally, I think that ruling on these specifics now is not 
+constitutionally in the hands of the technical committee, terribly 
+premature, and assumes bad faith from a quite wide set of Debian package 
+maintainers and upstream authors. The latter is what puzzles me most.
+
+Cheers,
+
+OdyX
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 18:39:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 18:39:09 GMT) (full text, mbox, link).

+ +

Message #6097 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Keith Packard <keithp@keithp.com>, 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 20:34:20 +0200
+
+
On Fri, Feb 07, 2014 at 01:08:46AM -0800, Keith Packard wrote:
+> Russ Allbery <rra@debian.org> writes:
+> 
+> > I consider the L option as currently written to be a commitment to a
+> > course of action that is technically broken and unsustainable.  I also
+> > think the effect of L is contrary to its intended goal and will make it
+> > less likely, not more likely, that Debian will provide working support for
+> > any init system other than the default in the long run.  (More on that
+> > below.)
+> 
+> I agree with this, with a slightly greater emphasis on ensuring that
+> Debian developers continue to have great latitude in choosing how to
+> package software. I would also have preferred to continue Bdale's ballot
+> which didn't mention this issue at all.
+>...
+
+The main discussion among TC members regarding L seems to be around
+the fact that its validity is in the current proposal not limited
+to jessie.
+
+IMHO this is a mostly theoretical discussion, since I'd expect that 
+after any "multiple init systems in jessie" decision the whole
+init system discussion covering all aspects will anyway have to
+be done again for jessie+1.
+
+And that's not just kicking the can a bit further down the road:
+
+In 2 years [1] the situation will anyway be different with many things 
+more clear - perhaps everything desktop environments want is provided by 
+both systemd and upstart so a new L saying "either systemd or upstart" 
+will be noncontroversial, or perhaps Canonical has abandoned upstart in 
+favour of systemd, or perhaps Lennart has abandoned systemd in favour
+of OpenRC, or whatever else might happen during the next 2 years.
+
+
+My impression is that with L limited to jessie [2], both DL and UL could 
+be acceptable for all TC members.
+
+That's far from a deadlock.
+
+
+cu
+Adrian
+
+[1] rough estimate for the timing for the jessie+1 init system discussion
+[2] and expecting that a decision for jessie+1 will be made after jessie,
+    if someone insists you could even write explicitly into the
+    resolution that the TC will re-evaluate the situation for jessie+1 
+    after the release of jessie
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 18:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 18:45:04 GMT) (full text, mbox, link).

+ +

Message #6102 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org, Anthony Towns <aj@erisian.com.au>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 07 Feb 2014 10:42:13 -0800
+
+
Andreas Barth <aba@ayous.org> writes:
+> * Russ Allbery (rra@debian.org) [140207 02:09]:
+
+>> I also flatly disagree with Adrian over whether we're deadlocked.  I
+>> don't see any point in discussing it, though.
+
+> I agree with you, I don't see any reason why we are deadlocked. If we
+> want to do yet another round on improving texts this is fine for me,
+> but should be finished soon. And the following vote should really be
+> finished, and I expect an outcome from the votes and statements I have
+> seeing so far.
+
+Just to be very clear here, I do believe that we're deadlocked, even
+though I expect the resolution process to be able to spit out a decision.
+I don't mean deadlocked in the sense that Condorcet will fail, but rather
+deadlock in the sense that the preferences above FD will result in a tie
+and the question will be decided by casting vote.
+
+I consider deciding the question by casting vote to be synonymous with
+being deadlocked, since the whole point of a casting vote is to break
+deadlocks.  I realize, in retrospect, that this may be an idiosyncratic
+use of the term "deadlock" and that other people thought I meant that no
+option would get a majority above FD.
+
+The casting vote is the process we have, and the process that everyone
+agreed to.  But I must say that I'm personally quite uncomfortable with
+deciding an issue of this magnitude by casting vote.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 18:48:04 GMT) (full text, mbox, link).

+ +

Message #6105 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Fri, 07 Feb 2014 19:44:31 +0100
+
+
Steve Langasek <vorlon@debian.org> writes:
+> On Fri, Feb 07, 2014 at 05:46:15PM +0100, Ansgar Burchardt wrote:
+>> If you decide on the init system question first, you could just file a
+>> bug against debian-policy and things could go their usual way.
+>> Alternatively, the Policy maintainers could defer this decision to the
+>> technical committee under 6.1.3.
+>
+> The Policy maintainers are the maintainers of the policy document, they are
+> not "maintainers of the relevant software" in this context.
+
+No, but they are "maintainers of the relevant documentation", that is
+the Policy. And they don't just maintain the package, see the delegation
+text.
+
+So let me ask you again: do you choose to ignore the requirement that
+"maintainers of the relevent documentation" (that is the Policy editors)
+make decisions initially?
+
+Or do you think defining policies such as package dependencies do not
+fall within the Policy team delegation?
+
+Ansgar
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 18:57:09 GMT) (full text, mbox, link).

+ +

Message #6108 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 07 Feb 2014 19:53:10 +0100
+
+
Hi,
+
+Russ Allbery <rra@debian.org> writes:
+> Just to be very clear here, I do believe that we're deadlocked, even
+> though I expect the resolution process to be able to spit out a decision.
+> I don't mean deadlocked in the sense that Condorcet will fail, but rather
+> deadlock in the sense that the preferences above FD will result in a tie
+> and the question will be decided by casting vote.
+
+What would you think is the way forward in this case? A GR after all?
+
+Ansgar
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 19:06:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 19:06:10 GMT) (full text, mbox, link).

+ +

Message #6113 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: "Didier 'OdyX' Raboud" <odyx@debian.org>
+
Cc: 727708@bugs.debian.org, secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Fri, 07 Feb 2014 11:04:12 -0800
+
+
"Didier 'OdyX' Raboud" <odyx@debian.org> writes:
+
+> Back then, the gnome maintainers added a dependency on another package,
+> which happened to be providing an /sbin/init. This was allowed by the
+> Debian Policy of the time as well as by the Debian archive. The
+> maintainers of the Policy maintainers haven't tried to rule on this at
+> all since then. How is this matter now magically taken off the Policy
+> maintainers' hands (while it _is_ a matter of Policy) and become a
+> matter for the technical committee?
+
+I appreciate what you're saying here (although I think 6.1.1 overrides
+that), but as one of the delegated Policy Editors, I would immediately
+punt such a question arising in the Policy context to the TC under 6.1.1
+and 6.1.3.  There is absolutely no way the normal Policy maintenance
+process could deal with this debate.
+
+If it makes you feel more comfortable with this process, please assume
+that's happened.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 19:09:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 19:09:11 GMT) (full text, mbox, link).

+ +

Message #6118 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: Anthony Towns <aj@erisian.com.au>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 21:07:36 +0200
+
+
On Fri, Feb 07, 2014 at 10:42:13AM -0800, Russ Allbery wrote:
+> Andreas Barth <aba@ayous.org> writes:
+> > * Russ Allbery (rra@debian.org) [140207 02:09]:
+> 
+> >> I also flatly disagree with Adrian over whether we're deadlocked.  I
+> >> don't see any point in discussing it, though.
+> 
+> > I agree with you, I don't see any reason why we are deadlocked. If we
+> > want to do yet another round on improving texts this is fine for me,
+> > but should be finished soon. And the following vote should really be
+> > finished, and I expect an outcome from the votes and statements I have
+> > seeing so far.
+> 
+> Just to be very clear here, I do believe that we're deadlocked, even
+> though I expect the resolution process to be able to spit out a decision.
+> I don't mean deadlocked in the sense that Condorcet will fail, but rather
+> deadlock in the sense that the preferences above FD will result in a tie
+> and the question will be decided by casting vote.
+> 
+> I consider deciding the question by casting vote to be synonymous with
+> being deadlocked, since the whole point of a casting vote is to break
+> deadlocks.  I realize, in retrospect, that this may be an idiosyncratic
+> use of the term "deadlock" and that other people thought I meant that no
+> option would get a majority above FD.
+> 
+> The casting vote is the process we have, and the process that everyone
+> agreed to.  But I must say that I'm personally quite uncomfortable with
+> deciding an issue of this magnitude by casting vote.
+
+Thanks for the explanation, that explains where I misunderstood you.
+
+You are right that there is no clear majority for any option.
+
+But after all the hefty debates I was positively surprised to see that 
+it might be possible that the winner is acceptable for all TC members
+(IOW: beats FD 8:0).
+
+IMHO a 4:4 decision with casting vote where 4 members consider the 
+result as a second best but acceptable solution is better than
+e.g. a 5:3 decision with 3 TC members vehemently opposing the result.
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 19:15:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 19:15:09 GMT) (full text, mbox, link).

+ +

Message #6123 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ansgar Burchardt <ansgar@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 07 Feb 2014 11:12:05 -0800
+
+
Ansgar Burchardt <ansgar@debian.org> writes:
+> Russ Allbery <rra@debian.org> writes:
+
+>> Just to be very clear here, I do believe that we're deadlocked, even
+>> though I expect the resolution process to be able to spit out a
+>> decision.  I don't mean deadlocked in the sense that Condorcet will
+>> fail, but rather deadlock in the sense that the preferences above FD
+>> will result in a tie and the question will be decided by casting vote.
+
+> What would you think is the way forward in this case? A GR after all?
+
+Yes, which is what will happen anyway.  Multiple people have already
+indicated their intention to hold a GR on this topic given various
+possible outcomes.
+
+Given that the GR is happening anyway, I don't think it's particularly
+harmful for the TC to arrive at a decision via casting vote, since the
+casting vote decision will not actually be the final decision for the
+project.  But I think the final decision in this case will have to be made
+by GR.
+
+If the TC had been able to reach consensus, or at least a strong majority,
+it's possible that we would have avoided that, but given the essentially
+equal split over the primary question, I don't think there's a way to
+avoid it, and it's not clear to me that we even *should* avoid it.
+
+I'm sorry that y'all are going to have to go through the same discussion
+process that we went through, since it's quite exhausting.  Hopefully the
+extensive analysis and discussion record done by the TC will be useful to
+project members at large in forming their own opinions, and will allow
+people to avoid having to redo some of our research.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 21:09:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Didier 'OdyX' Raboud" <odyx@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 21:09:05 GMT) (full text, mbox, link).

+ +

Message #6128 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Didier 'OdyX' Raboud" <odyx@debian.org>
+
To: 727708@bugs.debian.org
+
Cc: secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Fri, 07 Feb 2014 22:05:47 +0100
+
+
Le vendredi, 7 février 2014, 11.04:12 Russ Allbery a écrit :
+> "Didier 'OdyX' Raboud" <odyx@debian.org> writes:
+> > Back then, the gnome maintainers added a dependency on another
+> > package, which happened to be providing an /sbin/init. This was
+> > allowed by the Debian Policy of the time as well as by the Debian
+> > archive. The maintainers of the Policy maintainers haven't tried to
+> > rule on this at all since then. How is this matter now magically
+> > taken off the Policy maintainers' hands (while it _is_ a matter of
+> > Policy) and become a matter for the technical committee?
+> 
+> I appreciate what you're saying here (although I think 6.1.1 overrides
+> that), but as one of the delegated Policy Editors, I would
+> immediately punt such a question arising in the Policy context to the
+> TC under 6.1.1 and 6.1.3. There is absolutely no way the normal
+> Policy maintenance process could deal with this debate.
+>
+> If it makes you feel more comfortable with this process, please assume
+> that's happened.
+
+It does, thank you for the clarification.
+
+As I was carrying the "constitutional nitpicker" hat [0], let me finish: 
+I think any confusion would have been avoided if the issue had been 
+referred explicitely and separately to the tech-ctte by the Policy 
+editors. The fact that it's needed to have that done after the fact 
+shows that the issue got taken by the Technical Committee, while it 
+hadn't been asked to, failing the mandatory earlier attempts at reaching 
+consensus [1].
+
+I keep thinking that bundling the default init decision with ruling on 
+what software dependencies are allowed in Debian packs two quite 
+different issues, allows (or "features", one could say) tactical voting 
+and has, in effect, delayed the core decision by several weeks now.
+
+OdyX
+
+[0] Who wants it now?
+[1] Furthermore, I'd be quite surprised if any non-T variant would stand
+    a GR, but that's mostly speculation at this point.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 21:09:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 21:09:08 GMT) (full text, mbox, link).

+ +

Message #6133 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 13:07:54 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Hi Russ,
+
+On Thu, Feb 06, 2014 at 11:25:02PM -0800, Russ Allbery wrote:
+> Adrian Bunk <bunk@stusta.de> writes:
+
+> > Leaving tactical aspects aside, IMHO the important point is that there
+> > is a compromise line that seems reasonable for all members of the TC:
+
+> > For the upstart side of the TC, the most important question is T/L.
+> > For the systemd side of the TC, the most important question is D/U.
+
+> I don't agree with this analysis.
+
+> I consider the L option as currently written to be a commitment to a
+> course of action that is technically broken and unsustainable.  I also
+> think the effect of L is contrary to its intended goal and will make it
+> less likely, not more likely, that Debian will provide working support for
+> any init system other than the default in the long run.  (More on that
+> below.)
+
+> L is only "less important" to me because I believe it is unworkable and
+> unimplementable in the long run, so it doesn't matter *that* much if it
+> wins, since it will naturally get dropped over time.  Eventually, package
+> maintainers will realize that the sysvinit scripts everyone has been
+> keeping around to give lip service to L don't actually work and aren't
+> actually maintained, and it will end up like other similar Debian features
+> that are "required" but uninteresting to nearly everyone and therefore
+> bitrot and are effectively non-functional.
+
+> L will cause less short-term damage with systemd as the default init than
+> with upstart or OpenRC as the default init, so I'm grudgingly willing to
+> vote DL above FD because the results wouldn't be quite as absurd as the
+> results of UL would be, but I'm quite far from happy with it.  In
+> practice, I expect any of the L options to require another round of this
+> discussion post-jessie to get rid of L again so that we can move forward
+> without keeping sysvinit scripts.  I certainly hope they will, since the
+> alternative is to have a decision on the books that maintainers are
+> supposed to comply with but, in practice, won't, which is an embarassing
+> and annoying situation to be in.
+
+So to make my position clear:  L does not accurately reflect what I think we
+should be doing; but given the option between L and T, I was willing to vote
+L above FD and was not willing to vote T above FD because I think T
+unambiguously sets the stage for all other init systems to wither away in
+Debian and I think it's foolish for the TC to say they are "welcome" under
+such circumstances.
+
+If option T also dropped the text saying that we "welcome contributions of
+support for all init systems", I would vote T above FD - but narrowly,
+because I don't think this is a good outcome either.
+
+Here's what I think is the right technical policy, that we should be
+addressing with this resolution.
+
+ - Packages in jessie must retain compatibility with sysvinit startup
+   interfaces (i.e., init scripts in /etc/init.d).
+ - Packages can require other interfaces for their operation that are
+   provided by an init system implementation, but which are unrelated to
+   service management; however, these requirements must be expressed in a
+   way that does not tie them to a single init system package.  E.g., a
+   package that uses the logind dbus interfaces is absolutely free to do so,
+   but must not express this usage as 'Depends: systemd'.
+ - The TC should make no ruling at this time regarding releases beyond
+   jessie.
+
+I'm not trying to tell maintainers they can't use native service management
+interfaces to systemd or upstart post-jessie, but I do think we need to make
+clear what's expected for jessie, if for no other reason than because of the
+upgrade requirements (which AIUI you agree with - or did, earlier in the
+discussion).  And I don't object at all to packages using logind - logind
+itself is a very good thing! - but if we actually intend to be open to
+alternative init systems, then maintainers should be expected to do the bare
+minimum of work (i.e., declaring dependencies appropriately) required to
+leave the door open for this.
+
+Laid out like this, do you see room for a compromise option on the ballot?
+Is there any value in me expanding on why I think the second point should be
+part of this decision?
+
+> L makes it less likely that Debian will support anything other than the
+> default init system in the long run because it undermines the process of
+> adding native configuration for non-default init systems.  If we said that
+> packages are required to support the default init system and strongly
+> encouraged to merge support for those with active communities, I think we
+> still wouldn't get 100% archive coverage for the non-default, but I do
+> think we'd get coverage for most or all of the packages that people using
+> the non-default init system care the most about.  That would probably be
+> in the form of native configurations for the init systems that people care
+> about, since all the native configurations are simpler and easier to
+> maintain than sysvinit scripts.  Packages would then depend on the set of
+> init systems that they support.  I think that's about the best solution we
+> can hope for in the long run: strong support for the default init system,
+> and workable but incomplete support for the other init systems, with clear
+> indication in the package dependency structure of what init systems are
+> supported.
+
+Multiple init systems are viable today only because we have a common
+baseline interface, defined in Policy.  Once we allow packages to drop
+support for sysvinit in favor of native systemd units, we no longer have a
+least common denominator interface.  Init systems that can't handle systemd
+units directly are going to have an insurmountable disadvantage.  This is
+not assuming bad faith, only human nature - as soon as sysvinit is not the
+default and sysvinit compatibility is no longer a policy requirement,
+support for non-systemd init is going to bit-rot in the archive, because
+it's no longer a development priority; some maintainers will even stop
+shipping init scripts as unsupported/untested, or because they're known
+broken and no one has stepped forward to update them.  The shift of
+responsibility from individual maintainers to take care of their init
+scripts for proper functioning, to some hypothetical community of init
+system afficionados, is not a trivial thing.
+
+An init system that can only be used for running specific services that the
+init system maintainers have added support for is not technically
+interesting.  I don't see how any member of this committee could believe
+otherwise.
+
+And ultimately, if there's no path forward that sees multiple init systems
+actually supported in Debian, then I think we should be honest about that.
+Hedging to say that some stupendously motivated unknown party *could* make
+another init system work in Debian without the benefit of a common baseline
+just gives people false hope, while distracting from the work of providing
+good native support for the init system we're choosing to make the default.
+Likewise, leaving it to individual maintainers to decide when to drop
+support for sysvinit, instead of providing project-level guidance about when
+this can be done, is only going to prolong the dispute, squandering our
+maintainers' time and motivation.
+
+> My preference would be to vote on Bdale's ballot, and I'm unhappy that we
+> didn't just continue with that vote.  However, I'm almost entirely out of
+> spoons to keep arguing wording and procedural issues, and I think we're at
+> the point where this process is starting to cause active damage by
+> continuing to drag on.  But apparently I'm failing to keep my mouth shut,
+> so, well, here you go.
+
+> Neither T nor L actually imply what I think will happen in practice.  The
+> T option gives explicit blessing to adding dependencies on non-default
+> init systems, which I think is something that's only appropriate on a
+> case-by-case basis for edge packages and cooperating package groups and
+> isn't appropriate general advice.  It also doesn't distinguish between
+> right now and after the jessie release, which I think is inappropriate.  I
+> think there's a huge difference between depending on an init system right
+> now for the jessie release, which is something I think we should only do
+> if there's really no technical alternative available at all, and depending
+> on an init system or set of init systems after jessie, which I think is a
+> reasonable way of handling the long-term migration path away from
+> supporting sysvinit scripts.
+
+> I tried to raise these issues multiple times and was roundly ignored, so I
+> gave up and just voted the best order I could come up with that I think
+> will result in sensible things happening in the long run, even if some of
+> the options are not particularly sensible.
+
+I suspect that in practice you and I are not actually very far apart in what
+we want to see out of a decision, and that we've been talking past each
+other for a good part of this.  I hope that with a little more focused
+discussion, we can converge on something that has the support of the full
+TC.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 21:15:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 21:15:10 GMT) (full text, mbox, link).

+ +

Message #6138 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org, + debian-policy@lists.debian.org
+
Cc: Didier 'OdyX' Raboud <odyx@debian.org>, secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Fri, 7 Feb 2014 22:13:52 +0100
+
+
On Fri, Feb 07, 2014 at 11:04:12AM -0800, Russ Allbery wrote:
+> "Didier 'OdyX' Raboud" <odyx@debian.org> writes:
+> 
+> > Back then, the gnome maintainers added a dependency on another package,
+> > which happened to be providing an /sbin/init. This was allowed by the
+> > Debian Policy of the time as well as by the Debian archive. The
+> > maintainers of the Policy maintainers haven't tried to rule on this at
+> > all since then. How is this matter now magically taken off the Policy
+> > maintainers' hands (while it _is_ a matter of Policy) and become a
+> > matter for the technical committee?
+> 
+> I appreciate what you're saying here (although I think 6.1.1 overrides
+> that), but as one of the delegated Policy Editors, I would immediately
+> punt such a question arising in the Policy context to the TC under 6.1.1
+> and 6.1.3.  There is absolutely no way the normal Policy maintenance
+> process could deal with this debate.
+> 
+> If it makes you feel more comfortable with this process, please assume
+> that's happened.
+
+It would be nice that other members from the policy tean could
+agree to that.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 21:27:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 21:27:19 GMT) (full text, mbox, link).

+ +

Message #6143 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ansgar Burchardt <ansgar@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Fri, 7 Feb 2014 13:22:44 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Feb 07, 2014 at 07:44:31PM +0100, Ansgar Burchardt wrote:
+> Steve Langasek <vorlon@debian.org> writes:
+> > On Fri, Feb 07, 2014 at 05:46:15PM +0100, Ansgar Burchardt wrote:
+> >> If you decide on the init system question first, you could just file a
+> >> bug against debian-policy and things could go their usual way.
+> >> Alternatively, the Policy maintainers could defer this decision to the
+> >> technical committee under 6.1.3.
+
+> > The Policy maintainers are the maintainers of the policy document, they are
+> > not "maintainers of the relevant software" in this context.
+
+> No, but they are "maintainers of the relevant documentation", that is
+> the Policy. And they don't just maintain the package, see the delegation
+> text.
+
+Assuming that by "the delegation text" you're referring to
+<https://lists.debian.org/debian-devel-announce/2013/12/msg00004.html>
+(which is the most recent one I'm aware of), note that the set of
+responsibilities listed as being delegated does *not* include *deciding*
+technical policy.  So while they have other responsibilities besides the
+maintenance of the document, there's nothing in the delegation that
+conflicts with the idea that the TC should rule here.
+
+(The details of that particular delegation were not uncontroversial, anyway
+- see follow-up discussion on debian-project last month - but for reasons
+unrelated to the present question.)
+
+Besides, Russ has explicitly punted the question to the TC with his policy
+delegate hat on, so I think this is a moot point.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 21:27:22 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Christian PERRIER <bubulle@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 21:27:22 GMT) (full text, mbox, link).

+ +

Message #6148 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Christian PERRIER <bubulle@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 22:23:42 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Quoting Cyril Brulebois (kibi@debian.org):
+
+> If you have any question for -boot@, please send a mail there. If you
+> want some input from either Christian or me, please cc us to ensure we
+> don't miss that mail.
+
+And, FWIW, though I *am* in some way following the -ctte list
+(including the giant #727708 story to some extent), I do not consider
+myself qualified to have any *technical* advice or valid *technical* input
+about the decision that has to be taken.
+
+
+
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 22:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 22:06:05 GMT) (full text, mbox, link).

+ +

Message #6153 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org, Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 07 Feb 2014 14:02:19 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Steve Langasek <vorlon@debian.org> writes:
+
+> So to make my position clear:  L does not accurately reflect what I think we
+> should be doing; but given the option between L and T, I was willing to vote
+> L above FD and was not willing to vote T above FD because I think T
+> unambiguously sets the stage for all other init systems to wither away in
+> Debian and I think it's foolish for the TC to say they are "welcome" under
+> such circumstances.
+
+Reading this message, it seems clear to me that you have separated the
+issue originally raised in this bug (default init for jessie) from the
+policy question of whether packages should be allowed to have explicit
+init system dependencies. I think this is a good thing.
+
+I believe that votes cast in the last ballot demonstrate a unanimous
+agreement that the answer for this package dependency question does not
+in any way depend on which init system is the default, and so this
+question could be resolved separately, with the question originally
+brought to the ctte resolved in another vote.
+
+I also think this vote can be represented by two (or maybe three) choices:
+
+ 1) The ctte takes no position on this issue at this time.
+
+ 2) Packages may depend on new init features, but those must be stated
+    as virtual dependencies which can be satisfied by any init system
+
+and/or
+
+ 3) Packages must work with all init systems, potentially with reduced
+    functionality
+   
+Please read all of these as referring to more complete language already
+present in this bug report, and not as an attempt to rewrite the
+proposed options.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 22:27:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Adam D. Barratt" <adam@adam-barratt.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 22:27:10 GMT) (full text, mbox, link).

+ +

Message #6158 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Adam D. Barratt" <adam@adam-barratt.org.uk>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Cc: Ansgar Burchardt <ansgar@debian.org>
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Fri, 07 Feb 2014 22:24:33 +0000
+
+
On Fri, 2014-02-07 at 13:22 -0800, Steve Langasek wrote:
+> On Fri, Feb 07, 2014 at 07:44:31PM +0100, Ansgar Burchardt wrote:
+> > Steve Langasek <vorlon@debian.org> writes:
+> > > The Policy maintainers are the maintainers of the policy document, they are
+> > > not "maintainers of the relevant software" in this context.
+> 
+> > No, but they are "maintainers of the relevant documentation", that is
+> > the Policy. And they don't just maintain the package, see the delegation
+> > text.
+> 
+> Assuming that by "the delegation text" you're referring to
+> <https://lists.debian.org/debian-devel-announce/2013/12/msg00004.html>
+> (which is the most recent one I'm aware of), note that the set of
+> responsibilities listed as being delegated does *not* include *deciding*
+> technical policy.
+
+<https://lists.debian.org/debian-devel-announce/2014/02/msg00003.html>
+was posted earlier today and indicates that "the Debian Policy team
+defines Debian's technical framework, including the structure and
+contents of the Debian archive, design issues of the operating system,
+as well as technical requirements that all packages must satisfy."
+
+(Various issues with the appropriateness of that text have already been
+raised elsewhere.)
+
+Regards,
+
+Adam
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 22:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 22:30:04 GMT) (full text, mbox, link).

+ +

Message #6163 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Didier 'OdyX' Raboud <odyx@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Fri, 7 Feb 2014 14:27:25 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Feb 07, 2014 at 10:05:47PM +0100, Didier 'OdyX' Raboud wrote:
+
+> I keep thinking that bundling the default init decision with ruling on 
+> what software dependencies are allowed in Debian packs two quite 
+> different issues, allows (or "features", one could say) tactical voting 
+> and has, in effect, delayed the core decision by several weeks now.
+
+Quite frankly, given that all members of the TC have by this point weighed
+in with their preference on the "systemd vs. upstart" question and these
+preferences can be tallied by hand, I don't think there should be any doubt
+as to how the vote on that core question will go.  So I don't think any
+maintainers should feel blocked on this by the lack of a formal vote; I
+certainly don't think that the conclusion of the vote is the only blocker
+for switching the default init system in jessie today, what I've seen
+suggests that systemd integration is currently in a state that would cause
+terrible regressions for many server users.
+
+So the only unsettled question today is whether, and how, maintainers should
+be allowed to add dependencies on specific init systems.  And if maintainers
+find themselves blocked on this, well, it's because they should block on
+it...
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 22:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 22:39:04 GMT) (full text, mbox, link).

+ +

Message #6168 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Cc: Didier 'OdyX' Raboud <odyx@debian.org>
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Fri, 7 Feb 2014 17:37:07 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Feb 07, 2014 at 02:27:25PM -0800, Steve Langasek wrote:
+> So I don't think any
+> maintainers should feel blocked on this by the lack of a formal vote; I
+> certainly don't think that the conclusion of the vote is the only blocker
+> for switching the default init system in jessie today [..]
+
+We really need to get a proper vote on this written on paper. We really
+do. It's the case where we need a direction and we need some body
+(frankly, at this point, it doesn't matter who) to say "This is the init
+system for jessie on Linux"
+
+> So the only unsettled question today is whether, and how, maintainers should
+> be allowed to add dependencies on specific init systems.  And if maintainers
+> find themselves blocked on this, well, it's because they should block on
+> it...
+
+I'd say we let maintainers resolve this themselves, and if there's a
+dispute between maintainers, raise that dispute to the ctte and get a
+ruling on that.
+
+I don't like assuming our maintainers aren't fit to make sound technical
+decisions regarding this as of yet. I also trust maintainers to accept
+sound patches fixing such lock-in.
+
+Cheers,
+  Paul
+
+
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
+: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+`. `'`  http://people.debian.org/~paultag
+ `-     http://people.debian.org/~paultag/conduct-statement.txt
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 22:39:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Nikolaus Rath <Nikolaus@rath.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 22:39:07 GMT) (full text, mbox, link).

+ +

Message #6173 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Nikolaus Rath <Nikolaus@rath.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Additional CTTE Drafting Meeting useful?
+
Date: Fri, 07 Feb 2014 14:38:25 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Ansgar Burchardt writes ("Re: Additional CTTE Drafting Meeting useful?"):
+>> In this case I suggest to decide just the question of the default init
+>> system on Linux architectures first and address further details later if
+>> no consensus can be found elsewhere. Finding the correct wording then
+>> should be easier.
+>
+> I strongly object to this approach for the reasons I have given
+> already.
+>
+> If I am given the opportunity to do so, if such a resolution is
+> proposed I will always propose amendments to settle the T vs L
+> question.
+
+I understand that you don't like the simple vote, because it doesn't
+allow you to express that your opinion on the init system depends on the
+outcome of the coupling question (or vice versa).
+
+This is all good in theory. In this particular situation, however, I
+don't think this is a concern in practice. It seems pretty clear that
+the default init system question is going to be decided by Bdale casting
+vote. As I think you said yourself, it's not likely that anyones opinion
+is going to change at this point.
+
+In other words, the decision for the init system is a given, all that is
+necessary is to finally bring it to a formal vote. In practice any
+difference in your vote that would depend on the outcome of the coupling
+question is not going to affect the result.
+
+It seems that the only effect of adding all the coupling and GR stuff is
+to make the ballot more complicated. If adding these options would
+somehow result in a clear majority (without the need for a casting vote)
+for one default init system, then to me this would look more like an
+undesired voting artifact rather than a change in the majority opinion
+of the CTTE.
+
+Am I missing something?
+
+Given the apparent challenges to draft an acceptable ballot, I think
+Bdale's idea of keeping the vote truly simple should be reconsidered.
+
+
+Best,
+Nikolaus
+
+-- 
+Encrypted emails preferred.
+PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
+
+             »Time flies like an arrow, fruit flies like a Banana.«
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 22:42:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 22:42:05 GMT) (full text, mbox, link).

+ +

Message #6178 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Zack Weinberg <zackw@panix.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Resolve impasse by focusing on requirements for + smooth upgrade
+
Date: Fri, 7 Feb 2014 14:39:21 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Feb 07, 2014 at 09:41:18AM -0500, Zack Weinberg wrote:
+> People have made various assertions about how difficult it would be to
+> port the necessary systemd components to run with some other init system,
+> or to create independent compatible implementations, but *no one has
+> actually done that yet*, and we don't know for sure that anyone will.
+
+That's not true, and I'm very cross that I have to keep refuting this claim
+(which I feel that I have to do, because various members of the TC seem to
+*accept* this claim).  The systemd dbus services *have* been made to run in
+an init-system-agnostic environment, this is exactly what Ubuntu is doing
+today.  More time has been wasted on this back-and-forth over whether it's
+possible to make these dbus services work on top of upstart, than it took to
+actually put the systemd-shim package into Debian.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 23:12:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 23:12:14 GMT) (full text, mbox, link).

+ +

Message #6183 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org, Zack Weinberg <zackw@panix.com>
+
Subject: Re: Bug#727708: Resolve impasse by focusing on requirements for smooth upgrade
+
Date: Fri, 07 Feb 2014 14:57:29 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+> On Fri, Feb 07, 2014 at 09:41:18AM -0500, Zack Weinberg wrote:
+
+>> People have made various assertions about how difficult it would be to
+>> port the necessary systemd components to run with some other init
+>> system, or to create independent compatible implementations, but *no
+>> one has actually done that yet*, and we don't know for sure that anyone
+>> will.
+
+> That's not true, and I'm very cross that I have to keep refuting this
+> claim (which I feel that I have to do, because various members of the TC
+> seem to *accept* this claim).  The systemd dbus services *have* been
+> made to run in an init-system-agnostic environment, this is exactly what
+> Ubuntu is doing today.  More time has been wasted on this back-and-forth
+> over whether it's possible to make these dbus services work on top of
+> upstart, than it took to actually put the systemd-shim package into
+> Debian.
+
+I'm not sure which TC members you have in mind.  Just in case it's me, and
+for the record, I know that you've done this now for the version of
+systemd in Debian.  My concern is only over whether it will continue to be
+feasible to do this into the indefinite future as systemd continues to
+develop, particularly including, but not limited to, the cgroup changes in
+current versions of systemd.
+
+My primary point in the various discussions of this is to not lock in a
+course of action predicated on work that everyone *intends* to do, but
+which is not *guaranteed* to actually happen.  As long as the work *does*
+happen, I don't think you and I (and for that matter the GNOME and systemd
+maintainers) actually disagree.  I just don't want the formal decision to
+commit to the assumption that this work will necessarily continue to
+happen and continue to be successful into the indefinite and murky future.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 23:12:17 GMT) (full text, mbox, link).

+ +

Message #6186 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Sat, 08 Feb 2014 00:05:30 +0100
+
+
Hi,
+
+Steve Langasek <vorlon@debian.org> writes:
+> Quite frankly, given that all members of the TC have by this point weighed
+> in with their preference on the "systemd vs. upstart" question and these
+> preferences can be tallied by hand, I don't think there should be any doubt
+> as to how the vote on that core question will go.  So I don't think any
+> maintainers should feel blocked on this by the lack of a formal vote;
+
+I think it would be good for the project to already vote on the default
+init question. Having a first result would take a lot of pressure from
+the commitee and restore trust that you will be able to find a solution
+for the project (which I think a non-negligible number of people is
+losing right now).
+
+> I certainly don't think that the conclusion of the vote is the only blocker
+> for switching the default init system in jessie today, what I've seen
+> suggests that systemd integration is currently in a state that would cause
+> terrible regressions for many server users.
+
+I'm not sure of that (and would leave this to the systemd maintainers),
+but it would probably take at least a few weeks of preparation in any
+case.
+
+Ansgar
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 07 Feb 2014 23:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zack Weinberg <zackw@panix.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 07 Feb 2014 23:21:04 GMT) (full text, mbox, link).

+ +

Message #6191 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zack Weinberg <zackw@panix.com>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Resolve impasse by focusing on requirements for + smooth upgrade
+
Date: Fri, 7 Feb 2014 17:58:51 -0500
+
+
On Fri, Feb 7, 2014 at 5:39 PM, Steve Langasek <vorlon@debian.org> wrote:
+> On Fri, Feb 07, 2014 at 09:41:18AM -0500, Zack Weinberg wrote:
+>> People have made various assertions about how difficult it would be to
+>> port the necessary systemd components to run with some other init system,
+>> or to create independent compatible implementations, but *no one has
+>> actually done that yet*, and we don't know for sure that anyone will.
+>
+> That's not true, and I'm very cross that I have to keep refuting this claim
+
+I admit that I did not check in detail, but I was under the impression
+that systemd-shim only provided the systemd v204 interfaces, not the
+newer ones (and in particular, not the newer logind, which, it is also
+my impression, newer GNOME (possibly newer than is even in
+experimental) wants).  If I am mistaken I apologize for repeating the
+incorrect claim.
+
+However, this was just an example.  I think my larger point stands -
+whichever default init is picked, substantial integration work remains
+to be done for jessie; it will be easier to know what Policy should
+look like on the topic of application -> init dependencies once that
+integration work gets done; in order to get the bus rolling again,
+what policy is written *now* should concentrate on the thing that is
+knowable now, i.e. the requirements for smooth wheezy-jessie upgrades.
+
+zw
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 00:15:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 00:15:14 GMT) (full text, mbox, link).

+ +

Message #6196 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 16:10:39 -0800
+
+
Keith Packard wrote:
+> I believe that votes cast in the last ballot demonstrate a unanimous
+> agreement that the answer for this package dependency question does not
+> in any way depend on which init system is the default, and so this
+> question could be resolved separately, with the question originally
+> brought to the ctte resolved in another vote.
+>
+> I also think this vote can be represented by two (or maybe three) choices:
+>
+>  1) The ctte takes no position on this issue at this time.
+>
+>  2) Packages may depend on new init features, but those must be stated
+>     as virtual dependencies which can be satisfied by any init system
+>
+> and/or
+>
+>  3) Packages must work with all init systems, potentially with reduced
+>     functionality
+>
+> Please read all of these as referring to more complete language already
+> present in this bug report, and not as an attempt to rewrite the
+> proposed options.
+
+I assume option 1 is intended to represent the status quo, in which
+there is no prohibition on depending directly on an init system?  That
+seems like it should be stated explicitly, even if only in clarifying
+text, since at first I wondered why there wasn't an equivalent of option
+2 without the requirement for virtual dependencies, before realizing
+that this is already permitted and the TC need only refrain from adding
+restrictions.
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 00:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 00:27:04 GMT) (full text, mbox, link).

+ +

Message #6201 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Fri, 7 Feb 2014 16:25:25 -0800
+
+
Colin Watson wrote:
+> Part of my concern with T is that it's so mealy-mouthed.  "Where
+> feasible", "should", "encouraged", etc.  By contrast, L is a bit
+> heavy-handed.  It sounds like we may share some common goals between
+> these, and maybe if we want those to stick properly we need to state
+> those more explicitly rather than using proxies.  Do we agree, for
+> instance, that we want it to be possible to run Debian's major desktop
+> environments with any of the init systems with communities active in
+> developing support for them?
+
+Could you elaborate a bit about your objections to the wording of the T
+option?  Is there some particular aspect of the wording of T that you
+believe should be written more clearly, and does that represent a
+syntactic or semantic cleanup?  And, more to the point, is there such a
+cleanup that would affect your vote on T?
+
+> On Thu, Feb 06, 2014 at 11:25:02PM -0800, Russ Allbery wrote:
+> > Neither T nor L actually imply what I think will happen in practice.  The
+> > T option gives explicit blessing to adding dependencies on non-default
+> > init systems, which I think is something that's only appropriate on a
+> > case-by-case basis for edge packages and cooperating package groups and
+> > isn't appropriate general advice.  It also doesn't distinguish between
+> > right now and after the jessie release, which I think is inappropriate.
+> 
+> Agreed on both counts.  I understand why Ian (was it?) wanted to have
+> the "multiple init systems for the foreseeable future" text, as a
+> statement of general intent, and I don't disagree with that.  But I
+> would prefer if the specifics ("Therefore, for jessie and later
+> releases:") were marked simply as "Therefore, for jessie:".  That seems
+> to dispose of part of your objection to L.
+
+Given this statement, and Ian's followup objecting to that language,
+might I suggest that there should be a version of the L rider that
+includes the sunset provision limiting it to jessie, since there is
+clearly support for such an option?
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 11:57:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Dmitry Smirnov <onlyjob@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 11:57:09 GMT) (full text, mbox, link).

+ +

Message #6206 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Dmitry Smirnov <onlyjob@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: init system decision-making concerns
+
Date: Sat, 08 Feb 2014 22:52:48 +1100
+
+
[Message part 1 (text/plain, inline)]
+
Dear all,
+
+I'm sincerely grateful to technical committee members for their dedication 
+and relentless effort to thoroughly research and understand the issue in 
+order to make the best decision possible.
+
+Although most arguments for and against various init systems were already 
+presented I think I still have something to add. I apologise in advance to 
+some who might consider my feedback to be obvious or redundant.
+
+This is the first time ever I'm sharing my concerns regarding init system 
+for Debian.
+
+I think well-balanced decision on this subject would benefit from not being 
+too technical. 
+
+For instance due to controversial contributor's agreement Upstart is pretty 
+much defunct project. Many contributors prefer to spend their time on 
+something else rather than Upstart. If adopted Upstart will likely turn into 
+a big liability for Debian. The very survival of Upstart may depend on 
+whether we going to be involved or not. Canonical/Ubuntu would be very happy 
+to use Debian resources for Upstart as if they succeed in "selling" Upstart 
+to Debian they would be able to offload (i.e. outsource) a significant chunk 
+of effort that they have to dedicate to Upstart development and maintenance 
+otherwise. It is quite possible that Ubuntu might reduce their involvement 
+to Upstart (and "allow" Debian to deal with problems) while they are likely 
+to spend more of their resources formerly allocated to Upstart to contribute 
+to other areas of "added value". (IMHO the only major Ubuntu sell point is a 
+concept of "added value" on top of Debian.) In my opinion Canonical/Ubuntu 
+will benefit the most from Upstart adoption in Debian.
+
+Considering the possibility that in the future Ubuntu might abandon Upstart, 
+Debian may end up with unwanted/obsolete init system. Since Upstart future 
+is uncertain I fear that we might waste a lot of precious resources for 
+Upstart and/or potentially became de-facto upstream for Upstart. IMHO from 
+this prospective Upstart shall not be considered as alternative init system 
+at all.
+
+Indeed I'm concerned about conflict of interests from DDs affiliated with 
+Canonical and Ubuntu. When they advocate for Upstart I doubt they have 
+Debian's best interests in mind. There is a danger for Debian to be overrun 
+by outsiders or to fall under their influence even if some of them are 
+working on both sides.
+
+Besides we can learn from OpenSUSE where Upstart was replaced with Systemd.
+Even without much investigation it should be fairly clear that there are 
+good reasons not to use Upstart and to prefer something else.
+
+As for Systemd I do not fear its adoption. On the bright side it would be 
+nice to reduce our differences with other distros in that area. Systemd may 
+open some exciting opportunities to cooperate and join the efforts with 
+other influential distros. Our users may benefit from feature rich init 
+system and its adoption might make it easier for new users to switch to 
+Debian. It doesn't look like Systemd survival will be influenced much from 
+Debian involvement so from non-technical prospective Systemd is better for 
+us due to strong upstream and wide(r) adoption.
+
+Of course there are concerns regarding integration between Systemd and GNOME 
+but that's a different issue and perhaps not a major one as long as we use 
+GNOME as default desktop environment. Besides GNOME already became notorious 
+for being intrusive (e.g. it depends on "pulseaudio" etc.). 
+
+Also I'd like to notice that shopping for most feature-rich init system 
+might be not our goal after all. OpenRC may be the safest choice that might 
+satisfy majority of developers as it appears to have the least number of 
+objections. I have impression that OpenRC have far less passionate opponents 
+than Systemd.
+
+Finally I'm sure everybody is already getting exhausted by long debates 
+about this topic. At this point it might be tempting to approach on 
+decision, any decision, to put this to end. This is a way to make mistakes 
+of judgement. Unless there is a rush we all need to slow down and perhaps 
+even take a break for several weeks to clear our heads and make a balanced, 
+well thought decision. Taking break may be beneficial for the quality of 
+decision making.
+
+-- 
+Cheers,
+ Dmitry Smirnov
+ GPG key : 4096R/53968D1B
+
+---
+
+Odious ideas are not entitled to hide from criticism behind the human
+shield of their believers' feelings.
+        -- Richard Stallman
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 16:15:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 16:15:14 GMT) (full text, mbox, link).

+ +

Message #6211 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Sat, 8 Feb 2014 16:12:04 +0000
+
+
Steve Langasek writes ("Bug#727708: Call for votes on init system resolution"):
+> Here's what I think is the right technical policy, that we should be
+> addressing with this resolution.
+> 
+>  - Packages in jessie must retain compatibility with sysvinit startup
+>    interfaces (i.e., init scripts in /etc/init.d).
+>  - Packages can require other interfaces for their operation that are
+>    provided by an init system implementation, but which are unrelated to
+>    service management; however, these requirements must be expressed in a
+>    way that does not tie them to a single init system package.  E.g., a
+>    package that uses the logind dbus interfaces is absolutely free to do so,
+>    but must not express this usage as 'Depends: systemd'.
+
+I'm afraid that I find this formulation too weak.  So I don't intend
+to withdraw my version of L in favour of something of that kind, nor
+accept amendments to my L version with that effect.
+
+You are of course entitled to propose your own wording for the ballot.
+
+Sorry,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 16:21:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 16:21:10 GMT) (full text, mbox, link).

+ +

Message #6216 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Kurt Roeckx <kurt@roeckx.be>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Sat, 8 Feb 2014 16:17:09 +0000
+
+
Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
+> On Fri, Feb 07, 2014 at 02:04:42PM +0000, Ian Jackson wrote:
+> > I have added the following texts to the drafts in git:
+> > 
+> > +  == introduction (all versions except GR) ==
+> > +
+> > +     We exercise our powers to set technical policy (Constitution 6.1.1)
+> > +     and decide in cases of overlapping jurisdiction (6.1.2):
+> 
+> Could you instead add that to the individual options, so it's
+> clear for which part of the text you use which power?
+
+I hereby propose and accept amendments to all my proposed versions
+along the lines of the commit below which I have just made to the git
+repo.
+
+I hope this satisfies everyone.
+
+Note that the T options have not yet been formally proposed by
+anyone.  As the sole proposer I can accept amendments at will.
+
+If Russ (or someone else) had proposed the T options, then I would
+have proposed these as amendments to Russ's versions which it would
+fall to Russ to accept (or reject).
+
+Ian.
+
+commit 3efd31ea34869570218ead29eeca2e018bb289b6
+Author: Ian Jackson <ijackson@chiark.greenend.org.uk>
+Date:   Sat Feb 8 16:15:19 2014 +0000
+
+    727708: split powers thing out as requested by Kurt
+
+diff --git a/727708_initsystem/draft-resolution.txt b/727708_initsystem/draft-resolution.txt
+index a1cb9b8..8045e42 100644
+--- a/727708_initsystem/draft-resolution.txt
++++ b/727708_initsystem/draft-resolution.txt
+@@ -18,8 +18,8 @@ Options on the ballot:
+ 
+ == introduction (all versions except GR) ==
+ 
+-   We exercise our powers to set technical policy (Constitution 6.1.1)
+-   and decide in cases of overlapping jurisdiction (6.1.2):
++   We exercise our power to decide in cases of overlapping
++   jurisdiction (6.1.2):
+ 
+ == version D (systemD) ==
+ 
+@@ -55,7 +55,8 @@ Options on the ballot:
+    init systems for the foreseeable future; we continue to welcome
+    contributions of support for all init systems.
+ 
+-   Therefore, for jessie and later releases:
++   Therefore, for jessie and later releases, we exercise our power to
++   set technical policy (Constitution 6.1.1):
+ 
+ == dependencies rider version T (Tight coupling) ==
+ 
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 16:48:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 16:48:09 GMT) (full text, mbox, link).

+ +

Message #6221 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
+
To: Kurt Roeckx <kurt@roeckx.be>
+
Cc: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org, + debian-policy@lists.debian.org, + Didier 'OdyX' Raboud <odyx@debian.org>, secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Sat, 8 Feb 2014 17:45:19 +0100
+
+
On Fri, Feb 07, 2014 at 10:13:52PM +0100, Kurt Roeckx wrote:
+> On Fri, Feb 07, 2014 at 11:04:12AM -0800, Russ Allbery wrote:
+> > "Didier 'OdyX' Raboud" <odyx@debian.org> writes:
+> > 
+> > > Back then, the gnome maintainers added a dependency on another package,
+> > > which happened to be providing an /sbin/init. This was allowed by the
+> > > Debian Policy of the time as well as by the Debian archive. The
+> > > maintainers of the Policy maintainers haven't tried to rule on this at
+> > > all since then. How is this matter now magically taken off the Policy
+> > > maintainers' hands (while it _is_ a matter of Policy) and become a
+> > > matter for the technical committee?
+> > 
+> It would be nice that other members from the policy tean could
+> agree to that.
+
+The policy maintainers job is to maintain the policy document, not
+to adjudicate conflicts. 
+
+We can offer advice whether some practice is compliant with the policy
+document, but that is about it. We do not have more authority to report RC bug
+than any other DD.
+
+The policy document does not cover every issue. It is restricted to situation
+when there is a consensus to pick one possible implementation and to codify
+in policy.
+
+Whether the policy allows or not gnome to depend on non-default /sbin/init is a
+side issue until we know what the default init is going to be.
+
+Cheers,
+Bill.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 17:18:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 17:18:08 GMT) (full text, mbox, link).

+ +

Message #6226 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, + 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>, debian-policy@lists.debian.org, + Didier 'OdyX' Raboud <odyx@debian.org>, secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Sat, 8 Feb 2014 18:15:52 +0100
+
+
On Sat, Feb 08, 2014 at 05:45:19PM +0100, Bill Allombert wrote:
+> On Fri, Feb 07, 2014 at 10:13:52PM +0100, Kurt Roeckx wrote:
+> > On Fri, Feb 07, 2014 at 11:04:12AM -0800, Russ Allbery wrote:
+> > > "Didier 'OdyX' Raboud" <odyx@debian.org> writes:
+> > > 
+> > > > Back then, the gnome maintainers added a dependency on another package,
+> > > > which happened to be providing an /sbin/init. This was allowed by the
+> > > > Debian Policy of the time as well as by the Debian archive. The
+> > > > maintainers of the Policy maintainers haven't tried to rule on this at
+> > > > all since then. How is this matter now magically taken off the Policy
+> > > > maintainers' hands (while it _is_ a matter of Policy) and become a
+> > > > matter for the technical committee?
+> > > 
+> > It would be nice that other members from the policy tean could
+> > agree to that.
+> 
+> The policy maintainers job is to maintain the policy document, not
+> to adjudicate conflicts. 
+
+I would have to disagree with that.  The recent delegation among
+other things says "defines [...] technical requirements that all
+packages must satisfy".  What the ctte here wants to do is set
+policy about having a Depends on an init system.  Under the
+delegation I think this is something for the policy editors to
+decide.
+
+> We can offer advice whether some practice is compliant with the policy
+> document, but that is about it. We do not have more authority to report RC bug
+> than any other DD.
+
+This is not about being RC or not.  This is about setting policy.
+
+> The policy document does not cover every issue. It is restricted to situation
+> when there is a consensus to pick one possible implementation and to codify
+> in policy.
+> 
+> Whether the policy allows or not gnome to depend on non-default /sbin/init is a
+> side issue until we know what the default init is going to be.
+
+What is going on here is that as policy editors you need to set
+policy and that the ctte here is setting policy instead of you.
+The question has been asked that it is at this time allowed for
+them to do so.  It's not up to the ctte to do detailed design
+work, and that they should decide between the options discussed
+somewhere else if they can not come to a consensus.  It has been
+argued that this has not been discussed somewhere else, and so
+that it's not yet up to the ctte to decide this.
+
+What I understand that Russ is now saying is that if this was
+brought to the policy team, he would refer it to ctte.  As
+delegate he can decide this on his own, but it would be nice
+that the other delegates didn't disagree with that.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 18:06:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uoti Urpala <uoti.urpala@pp1.inet.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 18:06:10 GMT) (full text, mbox, link).

+ +

Message #6231 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uoti Urpala <uoti.urpala@pp1.inet.fi>
+
To: 727708@bugs.debian.org
+
Subject: Re: init system decision-making concerns
+
Date: Sat, 08 Feb 2014 20:03:19 +0200
+
+
On Sat, 2014-02-08 at 22:52 +1100, Dmitry Smirnov wrote:
+> Also I'd like to notice that shopping for most feature-rich init system 
+> might be not our goal after all. OpenRC may be the safest choice that might 
+> satisfy majority of developers as it appears to have the least number of 
+> objections. I have impression that OpenRC have far less passionate opponents 
+> than Systemd.
+
+That there are less "passionate opponents" is likely only because OpenRC
+changes, and achieves, less. "Passionate" opposition typically occurs
+when things change, even for the better. I don't think that is a good
+metric to choose a system. I don't believe a majority of developers
+would actually believe OpenRC to be a particularly good choice either.
+More likely the lesser number of public objections to OpenRC is
+explained by two other reasons. First, fewer developers have looked at
+it enough to have even a superficial idea they could object to. Second,
+it already seems to be a near consensus that OpenRC is not a top choice,
+so people don't see a reason to argue against it. Using the criterion of
+least objections, there are even less objections to the alternative of
+creating and using a new port of launchd. But if it actually looked
+plausible that this alternative might win, a lot more people would voice
+their objections.
+
+
+> Finally I'm sure everybody is already getting exhausted by long debates 
+> about this topic. At this point it might be tempting to approach on 
+> decision, any decision, to put this to end. This is a way to make mistakes 
+> of judgement. Unless there is a rush we all need to slow down and perhaps 
+> even take a break for several weeks to clear our heads and make a balanced, 
+> well thought decision. Taking break may be beneficial for the quality of 
+> decision making.
+
+It doesn't look likely to me that delaying the decision would have
+beneficial effects, at least not greater than the cost of the delay
+itself. If the CTTE could find 5 members willing to vote "systemd is the
+default init for Jessie" (and nothing more) above FD, and do that within
+a day, I'm pretty sure that would have a better outcome than any
+improvement they would plausibly make after waiting for weeks more.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 19:51:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 19:51:08 GMT) (full text, mbox, link).

+ +

Message #6236 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: call for votes on default Linux init system for jessie
+
Date: Sat, 08 Feb 2014 12:49:37 -0700
+
+
[Message part 1 (text/plain, inline)]
+
I have carefully considered Ian's current proposal for a process and
+schedule to reach a next ballot on the init system issue, and do not
+believe it is the best way for us to proceed.
+
+The fundamental problem is that I remain as convinced now as I was when
+I posted my last CFV that conflating multiple questions in a single
+ballot is a bad idea.  Our voting system works exceptionally well when
+we're trying to choose between multiple alternatives for a single
+question.  But as others have observed, trying to mix questions into a
+matrix of alternatives in a single ballot really complicates the
+process.  I believe it both tempts us all to take a more tactical
+approach to voting than appropriate, and increases the risk of stumbling
+over corner cases in the process which could lead to surprising results.
+
+My other concern is that while it is clearly within our constitutional
+right, to the best of my recollection the committee has never before
+issued a binding ruling on an issue not explicitly put before it.  Thus,
+a vote on the "T vs L" question in whatever form might evolve through
+further discussion seems precedent-setting to me... and thus deserves to
+be voted on discretely, so the outcome is clear and unambiguous input to
+the project. 
+
+I expect that Debian can and should continue to support multiple init
+systems for the foreseeable future.  I also believe that Debian can and
+should take an active role working with upstream projects on software
+that is important to us, such as init system projects. 
+
+So... I want to try and simplify this again using essentially the same
+ballot I put forth before, but with all the concerns raised by other
+committee members addressed... except for Ian's demand that we conflate
+the "T vs L" question in the same vote.  I understand this means Ian
+will most likely vote further discussion as his first choice, but I
+sincerely hope the rest of you will not do that and instead vote this
+ballot to a useful conclusion. 
+
+I explicitly sought and have received our project Secretary's review of
+the text of this ballot.  Both the assertion of jurisdiction and text
+allowing a GR to override our conclusion incorporate his inputs.
+
+As per Constitution 6.3.1, I call for an immediate vote on the following
+ballot, with a voting period of one week or until the outcome is no
+longer in doubt:
+
+- - - start ballot - - -
+
+We exercise our power to decide in cases of overlapping jurisdiction
+(6.1.2) by asserting that the default init system for Linux
+architectures in jessie should be
+
+  D    systemd 
+
+  U    upstart
+
+  O    openrc
+
+  V    sysvinit (no change)
+
+  F    requires further discussion
+
+Should the project pass a General Resolution before the release of
+"jessie" asserting a "position statement about issues of the day" on
+init systems, that position replaces the outcome of this vote and is
+adopted by the Technical Committee as its own decision.
+
+- - - end ballot - - -
+
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 20:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 20:00:05 GMT) (full text, mbox, link).

+ +

Message #6241 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Sat, 08 Feb 2014 12:56:56 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Bdale Garbee <bdale@gag.com> writes:
+
+> - - - start ballot - - -
+>
+> We exercise our power to decide in cases of overlapping jurisdiction
+> (6.1.2) by asserting that the default init system for Linux
+> architectures in jessie should be
+>
+>   D    systemd 
+>
+>   U    upstart
+>
+>   O    openrc
+>
+>   V    sysvinit (no change)
+>
+>   F    requires further discussion
+>
+> Should the project pass a General Resolution before the release of
+> "jessie" asserting a "position statement about issues of the day" on
+> init systems, that position replaces the outcome of this vote and is
+> adopted by the Technical Committee as its own decision.
+>
+> - - - end ballot - - -
+
+I vote D U O V F.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 20:21:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 20:21:10 GMT) (full text, mbox, link).

+ +

Message #6246 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Sat, 08 Feb 2014 12:16:51 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Bdale Garbee <bdale@gag.com> writes:
+
+> The fundamental problem is that I remain as convinced now as I was when
+> I posted my last CFV that conflating multiple questions in a single
+> ballot is a bad idea.  Our voting system works exceptionally well when
+> we're trying to choose between multiple alternatives for a single
+> question.  But as others have observed, trying to mix questions into a
+> matrix of alternatives in a single ballot really complicates the
+> process.  I believe it both tempts us all to take a more tactical
+> approach to voting than appropriate, and increases the risk of stumbling
+> over corner cases in the process which could lead to surprising results.
+
+Thank you.  I'm strongly in agreement with this.
+
+The discussion over coupling is very important.  I will be continuing that
+today, simultaneous with this.  I think that Steve, Colin, and I are
+actually very close to wording that all three of us agree on, and which I
+suspect both Bdale and Keith will also agree with.  I have some wording to
+propose today.
+
+I don't think that changes the merits of what Bdale says above.  Yes,
+there is interplay between the various things that we want to decide, but
+iteratively narrowing the state space makes the ballots much more
+comprehensible and avoids wandering into corner cases of our voting
+method.  I really disliked how tactical the analysis got with the combined
+ballot; to me, it feels against the spirit of how we're expected to try to
+resolve problems within Debian.
+
+The ability to hold multiple iterative votes on different angles of the
+question is a huge advantage of the TC process over the GR process.  The
+latter has a variety of constraints that makes holding multiple rounds of
+votes incredibly painful.  Given that our decision is likely to be
+reviewed by GR no matter what happens, I think we can take advantage of
+our faster voting turnaround to try to at least sketch out a few
+reasonable courses of action that have support from sections of the TC,
+which can in turn provide useful input into what GR questions people may
+want to propose.
+
+> - - - start ballot - - -
+
+> We exercise our power to decide in cases of overlapping jurisdiction
+> (6.1.2) by asserting that the default init system for Linux
+> architectures in jessie should be
+
+>   D    systemd 
+
+>   U    upstart
+
+>   O    openrc
+
+>   V    sysvinit (no change)
+
+>   F    requires further discussion
+
+> Should the project pass a General Resolution before the release of
+> "jessie" asserting a "position statement about issues of the day" on
+> init systems, that position replaces the outcome of this vote and is
+> adopted by the Technical Committee as its own decision.
+
+> - - - end ballot - - -
+
+I vote:
+
+    D U O V F
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 20:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 20:39:04 GMT) (full text, mbox, link).

+ +

Message #6251 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Sat, 08 Feb 2014 12:38:21 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> So to make my position clear:  L does not accurately reflect what I
+> think we should be doing; but given the option between L and T, I was
+> willing to vote L above FD and was not willing to vote T above FD
+> because I think T unambiguously sets the stage for all other init
+> systems to wither away in Debian and I think it's foolish for the TC to
+> say they are "welcome" under such circumstances.
+
+I completely understand how you would end up in that situation.
+
+> Here's what I think is the right technical policy, that we should be
+> addressing with this resolution.
+
+>  - Packages in jessie must retain compatibility with sysvinit startup
+>    interfaces (i.e., init scripts in /etc/init.d).
+>  - Packages can require other interfaces for their operation that are
+>    provided by an init system implementation, but which are unrelated to
+>    service management; however, these requirements must be expressed in a
+>    way that does not tie them to a single init system package.  E.g., a
+>    package that uses the logind dbus interfaces is absolutely free to do so,
+>    but must not express this usage as 'Depends: systemd'.
+>  - The TC should make no ruling at this time regarding releases beyond
+>    jessie.
+
+Here is the language that I came up independently of (and before) your
+message, which I think demonstrates how close we actually are on this
+point.
+
+    The following is technical advice offered to the project by the
+    Technical Committee under section 6.1.5 of the constitution.  It does
+    not constitute an override of maintainer decisions past or future:
+
+    Packages should normally support the default Linux init system.  There
+    are some exceptional cases where lack of support for the default init
+    system may be appropriate, such as alternative init system
+    implementations, special-use packages such as managers for non-default
+    init systems, and cooperating groups of packages intended for use with
+    non-default init systems.  However, package maintainers should be
+    aware that a requirement for a non-default init system will mean the
+    package will be unusable for most Debian users and should normally be
+    avoided.
+
+    Package maintainers are strongly encouraged to merge any contributions
+    for support of init systems other than the Linux default, and to add
+    that support themselves if they're willing and capable of doing so.
+    In particular, package maintainers should put a high priority on
+    merging changes to support any init system which is the default on one
+    of Debian's non-Linux ports.
+
+    For the jessie release, all packages that currently support being run
+    under sysvinit should continue to support sysvinit unless there is no
+    technically feasible way to do so.  Reasonable changes to preserve or
+    improve sysvinit support should be accepted through the jessie
+    release.  There may be some loss of functionality under sysvinit if
+    that loss is considered acceptable by the package maintainer and the
+    package is still basically functional.  All packages should support
+    smooth upgrades from wheezy to jessie, including upgrades done on a
+    system booted with sysvinit.
+
+    The Technical Committee offers no advice at this time on requirements
+    or package dependencies on specific init systems after the jessie
+    release.  There are too many variables at this point to know what the
+
+I think this is broadly similar to what you propose above.  The
+differences I can identify are:
+
+* I don't explicitly require that all dependencies on non-init
+  functionality provided by the init system be redirected through a
+  virtual package immediately.  I think this is an implementation detail;
+  I don't have fundamental objections to your language, but I do think
+  it's overspecified.  I think we get to the same place with the above
+  advice, combined with the stronger advice for jessie.
+
+* We deal with the question of what happens if logind without systemd
+  fails to materialize in slightly different ways.  I approach that with
+  the "technically feasible" language, and you approach that by allowing
+  for a dependency that can only be satisfied by one package.  I think
+  either of those are reasonable approaches.  My language tries to avoid
+  specifying the technical solution and instead tries to state the desired
+  result.
+
+In general, I would be happy to use my language, your language, or some
+merger between them.  There are some things I prefer about how I put this,
+but the only thing that I'd really like to change is to give the
+maintainer some discretion over your first bullet.  You sort of do this
+already by saying "retain" rather than saying that packages must support
+sysvinit, but I think I was somewhat clearer.  I don't see any reason why,
+say, mountall or socklog-run should be required to support sysvinit.
+
+My statement is written using 6.1.5 because it sidesteps the whole issue
+of delegations and whatnot and I think should be an entirely
+uncontroversial power of the TC, and I don't think anything stronger than
+advice is actually needed.  If we still end up with conflicts, we can
+cross that bridge when we come to it, but I don't think that's likely.
+However, if people feel strongly that this should use 6.1.1 instead, I
+don't think it makes a huge difference.  I do think that invoking 6.1.4
+would be inappropriate (and I think there's general consensus there; I
+don't believe anyone is intending for us to override anyone at this
+point).
+
+> I'm not trying to tell maintainers they can't use native service
+> management interfaces to systemd or upstart post-jessie,
+
+This is the biggest thing that bothers me about L, so that's, from my
+perspective, a huge step towards something that I can get on board with.
+
+> but I do think we need to make clear what's expected for jessie, if for
+> no other reason than because of the upgrade requirements (which AIUI you
+> agree with - or did, earlier in the discussion).
+
+Yes, I completely agree with this.
+
+> And I don't object at all to packages using logind - logind itself is a
+> very good thing! - but if we actually intend to be open to alternative
+> init systems, then maintainers should be expected to do the bare minimum
+> of work (i.e., declaring dependencies appropriately) required to leave
+> the door open for this.
+
+I agree with this as well, and I think the only difference between your
+text and my text is how we'd word it.
+
+> Multiple init systems are viable today only because we have a common
+> baseline interface, defined in Policy.  Once we allow packages to drop
+> support for sysvinit in favor of native systemd units, we no longer have
+> a least common denominator interface.  Init systems that can't handle
+> systemd units directly are going to have an insurmountable disadvantage.
+> This is not assuming bad faith, only human nature - as soon as sysvinit
+> is not the default and sysvinit compatibility is no longer a policy
+> requirement, support for non-systemd init is going to bit-rot in the
+> archive, because it's no longer a development priority; some maintainers
+> will even stop shipping init scripts as unsupported/untested, or because
+> they're known broken and no one has stepped forward to update them.  The
+> shift of responsibility from individual maintainers to take care of
+> their init scripts for proper functioning, to some hypothetical
+> community of init system afficionados, is not a trivial thing.
+
+To the extent that this is what will happen, and I'm not entirely
+convinced that it's as dire as you believe, I think exactly the same
+argument applies to upstart.  In other words, this particular issue is not
+dependent on what init system we choose, provided that the init system is
+not sysvinit.  All three alternatives have considerably superior init
+system syntaxes, and all of them are mutually incompatible.
+
+My feeling here, and the reason why I'm not as pessimistic as you are, is
+that I think maintaining both a systemd unit file and an upstart init file
+is considerably less work than maintaining a single sysvinit init script.
+Both upstart init files and systemd unit files are quite simple for the
+typical daemon and will not pose any major ongoing maintenance work.  I
+think both are simple enough to be akin to doc-base files, which I
+maintain in all of my packages where appropriate despite the fact that I
+never run any program that uses doc-base and literally never test them.
+This is possible to do with a sufficiently simple syntax.  I don't think
+it really works with current sysvinit scripts.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 20:45:18 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 20:45:18 GMT) (full text, mbox, link).

+ +

Message #6256 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Cc: Steve Langasek <vorlon@debian.org>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Sat, 08 Feb 2014 12:42:39 -0800
+
+
Russ Allbery <rra@debian.org> writes:
+
+>     The Technical Committee offers no advice at this time on requirements
+>     or package dependencies on specific init systems after the jessie
+>     release.  There are too many variables at this point to know what the
+
+Sorry, cut and paste error.  The entire intended paragraph there was:
+
+    The Technical Committee offers no advice at this time on requirements
+    or package dependencies on specific init systems after the jessie
+    release.  There are too many variables at this point to know what the
+    correct course of action will be.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 20:57:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 20:57:10 GMT) (full text, mbox, link).

+ +

Message #6261 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Colin Watson <cjwatson@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Sat, 08 Feb 2014 12:52:47 -0800
+
+
Colin Watson <cjwatson@debian.org> writes:
+
+> I do think it's bizarre that we seem to have ended up with coupling
+> options that don't treat the default init system differently.  This
+> makes no sense to me, for *either* T or L.  Unfortunately I was severely
+> backlogged at the point when this was being thrashed out, and I'm not
+> confident that I follow the reasoning that led to them being drafted in
+> a way that's entirely agnostic of the default, which is why I haven't
+> proposed anything else.
+
+It's been a really long thread, and I think we're all running low on
+spoons.  It's clear that I should have pushed a bit harder on some points
+that Ian indicated continued disagreement with rather than assuming his
+disagreement was echoed by you, Steve, and Andi.
+
+> My reasoning about the probable effects of L is much more based on
+> jessie than the long run.  Given that, I don't agree with your reasoning
+> because I think the injunction to avoid tying higher-level packages to a
+> specific init system carries more force than the effects of sysvinit
+> inertia possibly outweighing the activity levels of the various init
+> system communities; there's still plenty of motivation for those
+> communities to flesh out native support.
+
+Oh, yes, absolutely.  I agree with most of L for jessie as long as we
+carve out a few reasonable exceptions.  I think I proposed limiting L to
+jessie somewhere in the thread, Ian disagreed, and I dropped it.  I'd be
+very happy to resurrect something akin to that.
+
+> Part of my concern with T is that it's so mealy-mouthed.  "Where
+> feasible", "should", "encouraged", etc.  By contrast, L is a bit
+> heavy-handed.  It sounds like we may share some common goals between
+> these, and maybe if we want those to stick properly we need to state
+> those more explicitly rather than using proxies.  Do we agree, for
+> instance, that we want it to be possible to run Debian's major desktop
+> environments with any of the init systems with communities active in
+> developing support for them?
+
+Yes.
+
+I don't think the GNOME maintainers, to take a concrete example, should be
+required to make that support appear if it doesn't exist.  But so long as
+someone provides a logind-compatible service that doesn't require systemd,
+it certainly seems reasonable to me to advise the GNOME maintainers to
+allow it to satisfy the dependencies of GNOME.  My impression is that none
+of the GNOME maintainers object to this idea, only to the assumption that
+such a service will necessarily materialize and that it's therefore
+reasonable to flatly require they not depend on systemd.  If things go as
+both you and Steve expect them to go, this whole problem simply
+disappears, and is replaced with some technical work about how best to
+represent the dependency structure, source packages, and so forth, which
+I'm confident can be resolved amicably by all parties.
+
+> Your comments about the package dependency structure make sense to me in
+> the long term.  Where I'm going with my support for L is something like
+> the zero-one-infinity rule: if a non-init-system package only supports
+> one system (natively or otherwise, and excluding obvious hacks like
+> packaging a -dev version of the same system), that may well indicate a
+> degree of inflexibility, whereas a package that supports more than one
+> is probably not hard to extend to others.
+
+I think one of the problems that we ran into was that we ended up
+entangling what init system configuration the package ships with and the
+whole logind issue, and they're really somewhat separate issues with
+different long-term dynamics.
+
+> I get that people want to dispose of this so we never have to consider
+> it again, and that we want to provide more certainty of direction; but I
+> honestly don't think we should be trying to do that.  As people have
+> been saying in other contexts, the probability space collapses quite a
+> bit following this decision; with a year of subsequent development the
+> proper long-term approach will be much clearer.
+
+I completely agree with this.  I think there's some reasonable chance
+that, a year or two from now, things will have sorted out sufficiently
+that we can reach a normal project consensus on where to go next.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 21:30:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 21:30:13 GMT) (full text, mbox, link).

+ +

Message #6266 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: Steve Langasek <vorlon@debian.org>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Sat, 8 Feb 2014 23:27:59 +0200
+
+
On Sat, Feb 08, 2014 at 12:38:21PM -0800, Russ Allbery wrote:
+>...
+> I don't see any reason why,
+> say, mountall or socklog-run should be required to support sysvinit.
+>...
+
+What about udev?
+
+cu
+Adrian
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 22:21:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 22:21:08 GMT) (full text, mbox, link).

+ +

Message #6271 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Bdale Garbee <bdale@gag.com>
+
Cc: debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Sat, 8 Feb 2014 14:18:39 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Feb 08, 2014 at 12:49:37PM -0700, Bdale Garbee wrote:
+> So... I want to try and simplify this again using essentially the same
+> ballot I put forth before, but with all the concerns raised by other
+> committee members addressed... except for Ian's demand that we conflate
+> the "T vs L" question in the same vote.  I understand this means Ian
+> will most likely vote further discussion as his first choice, but I
+> sincerely hope the rest of you will not do that and instead vote this
+> ballot to a useful conclusion. 
+
+I agree with Ian on this.  At this point, it should be clear to everyone
+that, given the stated preferences of each member of the TC, the default
+init system for jessie will be systemd.  But I do not think this is the most
+important aspect of the problem that needs to be decided.  The question of
+how, or if, multiple init systems will coexist in the Debian archive for
+jessie is what needs to be decided in order to unblock maintainers and give
+them clarity for their own packages.
+
+The only thing that an "up/down" vote on init systems does is placate the
+crowds of onlookers who are not part of Debian's decision-making processes,
+at the expense of settling the more nuanced questions that need to be
+answered for the project.  This should not be our priority.  Our purpose
+here is to make sound technical decisions on behalf of the project, not to
+preserve the TC's (or Debian's) "reputation" among third parties who have no
+legitimate say in the outcome.
+
+I will note for the record here that a number of DDs have at this point
+given the TC an ultimatum in private, stating that they will start a GR if
+the TC does not call for votes within a specified time limit.  I suspect
+that this ultimatum didn't have much effect on Bdale's decision to call for
+a vote (since he was already predisposed to having the up/down vote in
+question).  Likewise, such an ultimatum doesn't change my view about what
+ballot should be voted and when.  And every DD has a constitutional right to
+start a GR on this question, at any point.  But it's highly inappropriate to
+attempt to pressure the TC into making a quick decision using the *threat*
+of a GR.  TC decisions take time precisely because they deal with nuanced
+issues that don't get handled any other way.  Rushing to a vote only delays
+efforts to reach a consensus in the project, and is counter to the long-term
+health of Debian.
+
+> - - - start ballot - - -
+
+> We exercise our power to decide in cases of overlapping jurisdiction
+> (6.1.2) by asserting that the default init system for Linux
+> architectures in jessie should be
+
+>   D    systemd 
+>   U    upstart
+>   O    openrc
+>   V    sysvinit (no change)
+>   F    requires further discussion
+
+> Should the project pass a General Resolution before the release of
+> "jessie" asserting a "position statement about issues of the day" on
+> init systems, that position replaces the outcome of this vote and is
+> adopted by the Technical Committee as its own decision.
+> 
+> - - - end ballot - - -
+
+I vote F U D O V
+
+I will also point out that splitting this issue into separate ballots in no
+way prevents tactical voting, particularly given the small pool of voters
+and the resulting likelihood of voting blocks.  If I were less committed to
+the integrity of this process, I might have used burying to vote a ballot
+like:
+
+  U F O V D
+
+But seeing as I do value the integrity of the process, I will instead
+confine myself to observing that I think it's very rude to call a vote while
+other members of the committee have made it clear they are still engaged in
+discussion to identify ballot options that the whole committee can support.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 22:33:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 22:33:08 GMT) (full text, mbox, link).

+ +

Message #6276 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Sat, 08 Feb 2014 14:30:11 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> I agree with Ian on this.  At this point, it should be clear to everyone
+> that, given the stated preferences of each member of the TC, the default
+> init system for jessie will be systemd.  But I do not think this is the
+> most important aspect of the problem that needs to be decided.  The
+> question of how, or if, multiple init systems will coexist in the Debian
+> archive for jessie is what needs to be decided in order to unblock
+> maintainers and give them clarity for their own packages.
+
+Given that you feel like it's clear what the default init system will be,
+and given that the previous rounds of partial voting show that the choice
+of dependency models will have no effect on that outcome, I don't see any
+point in delaying this part of the decision.  You feel like this is all
+but decided; fine, let's decide it, so that we have a decision on record,
+and then continue the discussion.
+
+Or, put another way, why *don't* you want to vote on this right now?  That
+it's not the most important question is not a reason to delay voting on
+it; if anything, it's a reason to vote on it first, so that we can dispose
+of the questions with clear answers while we're working on language for
+the more complex options.
+
+We held the ballot to entangle it with other questions on the assumption
+that this entangling may change the result for the primary question.  It
+turns out that this is not the case, so there was no need for that
+entangling.  I would really like to establish things that you think are
+already apparent so that we have some forward progress and so that we
+don't have to hold open sockets for things that we think are *probably*
+decided but that we've not yet actually decided.
+
+If you feel like deciding this will mean losing some momentum on a
+question that you consider more important, I personally commit to
+continuing the discussions on that process and working on a ballot and
+arriving at a decision as quickly as possible.  I don't think any of us
+intend to abandon this discussion once the init system default on Linux is
+decided.
+
+> I will note for the record here that a number of DDs have at this point
+> given the TC an ultimatum in private, stating that they will start a GR
+> if the TC does not call for votes within a specified time limit.  I
+> suspect that this ultimatum didn't have much effect on Bdale's decision
+> to call for a vote (since he was already predisposed to having the
+> up/down vote in question).  Likewise, such an ultimatum doesn't change
+> my view about what ballot should be voted and when.  And every DD has a
+> constitutional right to start a GR on this question, at any point.  But
+> it's highly inappropriate to attempt to pressure the TC into making a
+> quick decision using the *threat* of a GR.  TC decisions take time
+> precisely because they deal with nuanced issues that don't get handled
+> any other way.  Rushing to a vote only delays efforts to reach a
+> consensus in the project, and is counter to the long-term health of
+> Debian.
+
+I think a group of DDs are telling us that we're not doing our job in a
+timely fashion.  While one may or may not agree with that, I think it's
+intended as constructive feedback, and personally I welcome the
+accountability to the rest of the project here.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 22:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 22:48:04 GMT) (full text, mbox, link).

+ +

Message #6281 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: Bdale Garbee <bdale@gag.com>, debian-ctte@lists.debian.org, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Sat, 8 Feb 2014 17:46:07 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Feb 08, 2014 at 02:18:39PM -0800, Steve Langasek wrote:
+> I agree with Ian on this.  At this point, it should be clear to everyone
+> that, given the stated preferences of each member of the TC, the default
+> init system for jessie will be systemd.
+
+Without an official vote we can *not* say this.
+
+> But I do not think this is the most
+> important aspect of the problem that needs to be decided. 
+
+Perhaps not, but it was the problem that was escelated to the TC
+
+> The question of
+> how, or if, multiple init systems will coexist in the Debian archive for
+> jessie is what needs to be decided in order to unblock maintainers and give
+> them clarity for their own packages.
+
+Why not let it to the maintainers to work through such issues, and
+resolve it in the TC when and if that process breaks down, like every
+other issue.
+
+> The only thing that an "up/down" vote on init systems does is placate the
+> crowds of onlookers who are not part of Debian's decision-making processes,
+> at the expense of settling the more nuanced questions that need to be
+> answered for the project.
+
+The more nuanced question was not asked of the TC
+
+> This should not be our priority.  Our purpose
+> here is to make sound technical decisions on behalf of the project, not to
+> preserve the TC's (or Debian's) "reputation" among third parties who have no
+> legitimate say in the outcome.
+
+At this point, it's blocking folks inside Debian, who are stakeholders.
+It's not just the trolls of reddit and the internet, it's DDs who are
+annoyed there's no decision and integration work isn't started. We're
+less than a year from freeze.
+
+[snip]
+
+Cheers,
+  Paul
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
+: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+`. `'`  http://people.debian.org/~paultag
+ `-     http://people.debian.org/~paultag/conduct-statement.txt
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 22:48:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 22:48:07 GMT) (full text, mbox, link).

+ +

Message #6286 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Sat, 08 Feb 2014 15:46:53 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Steve Langasek <vorlon@debian.org> writes:
+
+> I will note for the record here that a number of DDs have at this point
+> given the TC an ultimatum in private, stating that they will start a GR if
+> the TC does not call for votes within a specified time limit.  I suspect
+> that this ultimatum didn't have much effect on Bdale's decision to call for
+> a vote (since he was already predisposed to having the up/down vote in
+> question).
+
+That is correct.  I had already posted the call for votes on this ballot
+before I discovered that email in my inbox.
+
+I'm disappointed, particularly since you seem inclined to agree that the
+outcome of the simple part of this vote really isn't in question any
+more, that you've chosen to vote F first.  That's certainly your right,
+but I do hope you will reconsider.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 22:48:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 22:48:10 GMT) (full text, mbox, link).

+ +

Message #6291 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Steve Langasek <vorlon@debian.org>, Bdale Garbee <bdale@gag.com>
+
Cc: debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Sat, 08 Feb 2014 14:47:06 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Steve Langasek <vorlon@debian.org> writes:
+
+> I agree with Ian on this.  At this point, it should be clear to everyone
+> that, given the stated preferences of each member of the TC, the default
+> init system for jessie will be systemd.
+
+Let's finish that vote then and move on.
+
+> But I do not think this is the most important aspect of the problem
+> that needs to be decided.  The question of how, or if, multiple init
+> systems will coexist in the Debian archive for jessie is what needs to
+> be decided in order to unblock maintainers and give them clarity for
+> their own packages.
+
+That is an entirely separate issue. I agree that it is important and
+needs to be resolved, but the Technical Committee is the wrong place to
+be designing this policy. We must (by 6.3.5) not engage in design of new
+proposals and policies.
+
+Yes, as individuals, we may choose to collaborate with others on the
+development of a suitable policy, and that group may well decide that
+they cannot reach a consensus and bring the issue back to the Technical
+Committee for advice. Please stop trying to bypass the constitutional
+process for policy design.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 22:54:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 22:54:10 GMT) (full text, mbox, link).

+ +

Message #6296 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Sat, 8 Feb 2014 14:51:13 -0800
+
+
On Sat, 08 Feb 2014, Bdale Garbee wrote:
+> - - - start ballot - - -
+> 
+> We exercise our power to decide in cases of overlapping jurisdiction
+> (6.1.2) by asserting that the default init system for Linux
+> architectures in jessie should be
+> 
+>   D    systemd 
+> 
+>   U    upstart
+> 
+>   O    openrc
+> 
+>   V    sysvinit (no change)
+> 
+>   F    requires further discussion
+> 
+> Should the project pass a General Resolution before the release of
+> "jessie" asserting a "position statement about issues of the day" on
+> init systems, that position replaces the outcome of this vote and is
+> adopted by the Technical Committee as its own decision.
+> 
+> - - - end ballot - - -
+
+I vote D > U > O > V > F.
+
+I also agree that given that while the additional questions of how
+packages are able to depend or rely on the default init system is
+important, it is not necessary to resolve that question to determine
+which system is going to be the default init system, as in no ballot yet
+has anyone changed their D/U ranking on the basis of which of the T, S,
+or L options were being voted for.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+There is no form of lead-poisoning which more rapidly and thoroughly
+pervades the blood and bones and marrow than that which reaches the
+young author through mental contact with type metal.
+ -- Oliver Wendell Holmes (Tilton 1947 p67)
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:00:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:00:07 GMT) (full text, mbox, link).

+ +

Message #6301 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Keith Packard <keithp@keithp.com>
+
Cc: Steve Langasek <vorlon@debian.org>, Bdale Garbee <bdale@gag.com>, debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Sat, 08 Feb 2014 14:56:41 -0800
+
+
Keith Packard <keithp@keithp.com> writes:
+
+> That is an entirely separate issue. I agree that it is important and
+> needs to be resolved, but the Technical Committee is the wrong place to
+> be designing this policy. We must (by 6.3.5) not engage in design of new
+> proposals and policies.
+
+Well, in defense of the discussion that Steve, Colin, and I have been
+having, I do think it's worthwhile for the TC to try to hammer out a
+compromise on that point as well and express it as either technical advice
+to the project or as technical policy.
+
+While it may not have been explicitly listed in the message that referred
+this debate to the TC, the question of logind dependencies and the
+question of how to handle packages that no longer support a
+lowest-common-denominator sysvinit script have come up repeatedly in the
+interminable debian-devel discussions on this topic.  I believe they're
+controversial questions and that we'd benefit from hashing out a
+reasonable approach in the TC context and offering it as advice.
+
+I also don't think that the approaches that we're discussing at the moment
+involve design work or are at all novel.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:00:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:00:10 GMT) (full text, mbox, link).

+ +

Message #6306 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Bdale Garbee <bdale@gag.com>, debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Sat, 08 Feb 2014 14:57:52 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Bdale Garbee <bdale@gag.com> writes:
+
+> - - - start ballot - - -
+>
+> We exercise our power to decide in cases of overlapping jurisdiction
+> (6.1.2) by asserting that the default init system for Linux
+> architectures in jessie should be
+>
+>   D    systemd 
+>
+>   U    upstart
+>
+>   O    openrc
+>
+>   V    sysvinit (no change)
+>
+>   F    requires further discussion
+>
+> Should the project pass a General Resolution before the release of
+> "jessie" asserting a "position statement about issues of the day" on
+> init systems, that position replaces the outcome of this vote and is
+> adopted by the Technical Committee as its own decision.
+>
+> - - - end ballot - - -
+
+I vote:
+
+        1.      D
+        2.      U
+        3.      O
+        4.      V
+        5.      F
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:09:05 GMT) (full text, mbox, link).

+ +

Message #6311 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Russ Allbery <rra@debian.org>
+
Cc: Steve Langasek <vorlon@debian.org>, Bdale Garbee <bdale@gag.com>, debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Sat, 08 Feb 2014 15:07:47 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Russ Allbery <rra@debian.org> writes:
+
+> Well, in defense of the discussion that Steve, Colin, and I have been
+> having, I do think it's worthwhile for the TC to try to hammer out a
+> compromise on that point as well and express it as either technical advice
+> to the project or as technical policy.
+
+I'm really pleased that the three of you have constructed a policy that
+looks like a good compromise for this problem. I was worried that this
+would also become mired in controversy, when in fact there is already
+broad agreement and consensus.
+
+> I also don't think that the approaches that we're discussing at the moment
+> involve design work or are at all novel.
+
+It's not sophisticated or novel, but you're definitely crafting new
+policy for the project. Given that the group doing this are likely to
+reach consensus, it sounds like the Technical Committee process will not
+be necessary in this case. And I think we'll all be pleased if that
+happens.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:15:04 GMT) (full text, mbox, link).

+ +

Message #6316 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Sat, 8 Feb 2014 18:11:26 -0500
+
+
On Sat, Feb 8, 2014 at 5:56 PM, Russ Allbery wrote:
+> Keith Packard writes:
+>
+>> That is an entirely separate issue. I agree that it is important and
+>> needs to be resolved, but the Technical Committee is the wrong place to
+>> be designing this policy. We must (by 6.3.5) not engage in design of new
+>> proposals and policies.
+>
+> Well, in defense of the discussion that Steve, Colin, and I have been
+> having, I do think it's worthwhile for the TC to try to hammer out a
+> compromise on that point as well and express it as either technical advice
+> to the project or as technical policy.
+
+Why not hammer that out on -policy in public, and only if something
+goes wrong there, then defer it to the TC?
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:15:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:15:07 GMT) (full text, mbox, link).

+ +

Message #6321 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Kurt Roeckx <kurt@roeckx.be>
+
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, + 727708@bugs.debian.org, Russ Allbery <rra@debian.org>, + debian-policy@lists.debian.org, + Didier 'OdyX' Raboud <odyx@debian.org>, secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Sat, 8 Feb 2014 15:13:36 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Feb 08, 2014 at 06:15:52PM +0100, Kurt Roeckx wrote:
+> On Sat, Feb 08, 2014 at 05:45:19PM +0100, Bill Allombert wrote:
+> > On Fri, Feb 07, 2014 at 10:13:52PM +0100, Kurt Roeckx wrote:
+> > > On Fri, Feb 07, 2014 at 11:04:12AM -0800, Russ Allbery wrote:
+> > > > "Didier 'OdyX' Raboud" <odyx@debian.org> writes:
+
+> > > > > Back then, the gnome maintainers added a dependency on another
+> > > > > package, which happened to be providing an /sbin/init.  This was
+> > > > > allowed by the Debian Policy of the time as well as by the Debian
+> > > > > archive.  The maintainers of the Policy maintainers haven't tried
+> > > > > to rule on this at all since then.  How is this matter now
+> > > > > magically taken off the Policy maintainers' hands (while it _is_ a
+> > > > > matter of Policy) and become a matter for the technical committee?
+
+> > > It would be nice that other members from the policy tean could
+> > > agree to that.
+
+> > The policy maintainers job is to maintain the policy document, not
+> > to adjudicate conflicts. 
+
+> I would have to disagree with that.  The recent delegation among
+> other things says "defines [...] technical requirements that all
+> packages must satisfy".  What the ctte here wants to do is set
+> policy about having a Depends on an init system.  Under the
+> delegation I think this is something for the policy editors to
+> decide.
+
+I question the whole notion of DPL delegation of policy powers to the policy
+editors.  The power to decide the contents of the debian-policy package
+follows from their status as package maintainers; package maintenance is not
+something that I believe it's in the purview of the DPL to delegate.
+
+What happens if the TC disagrees with the DPL's choice of policy
+maintainers, and exercises its power under 6.1.2 to name different package
+maintainers?  Since this is a power expressly given to the TC, I think a
+consistent interpretation of the constitution requires that the DPL does not
+have the authority to make such a delegation.  The alternative
+interpretation is that we have a baked-in constitutional crisis, which I
+don't believe is the intent.
+
+I'm not arguing that I don't think the policy editors are doing a good job -
+I'm grateful to them for the work they do.  But constitutionally, I think
+the DPL doesn't have any authority to delegate the power to decide technical
+policy (which is a power reserved to the TC in the absence of consensus),
+only the power to act as recognized facilitators for policy discussions
+(i.e., the previous delegation that was in place).
+
+> What is going on here is that as policy editors you need to set
+> policy and that the ctte here is setting policy instead of you.
+> The question has been asked that it is at this time allowed for
+> them to do so.  It's not up to the ctte to do detailed design
+> work, and that they should decide between the options discussed
+> somewhere else if they can not come to a consensus.  It has been
+> argued that this has not been discussed somewhere else, and so
+> that it's not yet up to the ctte to decide this.
+
+> What I understand that Russ is now saying is that if this was
+> brought to the policy team, he would refer it to ctte.  As
+> delegate he can decide this on his own, but it would be nice
+> that the other delegates didn't disagree with that.
+
+This much is reasonable, whether the policy editors' authority is delegated
+or not.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:27:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:27:05 GMT) (full text, mbox, link).

+ +

Message #6326 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Michael Gilbert <mgilbert@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sat, 08 Feb 2014 15:23:41 -0800
+
+
Michael Gilbert <mgilbert@debian.org> writes:
+> On Sat, Feb 8, 2014 at 5:56 PM, Russ Allbery wrote:
+
+>> Well, in defense of the discussion that Steve, Colin, and I have been
+>> having, I do think it's worthwhile for the TC to try to hammer out a
+>> compromise on that point as well and express it as either technical
+>> advice to the project or as technical policy.
+
+> Why not hammer that out on -policy in public, and only if something goes
+> wrong there, then defer it to the TC?
+
+Because -policy doesn't have a decision-making process other than
+consensus, so Ian's objections to all of the positions shy of L and my
+objections to L would deadlock and effectively block the -policy
+discussion from ever reaching a decision.  There is no method for either
+of us to be overridden.
+
+Now, there would have been no way of knowing in advance that something
+like that would happen... but based on my past experience with Policy
+discussions and the level of controversy over this particular question, I
+would have been stunned if it hadn't happened, which is exactly why I
+would have immediately punted to the TC.
+
+Policy doesn't have a strong decision-making method other than consensus,
+which means that it will fail to arrive at a conclusion for anything
+that's even vaguely controversial (and sometimes even for things that are
+not very controversial but which don't inspire people to express an
+opinion).  Maybe that's a bug that should be fixed, or maybe we should
+just use the TC as the way of reaching conclusions on controversial
+issues; I can see arguments either way.  (The first Policy issue that I
+escalated to the TC as an experiment in using the TC to make these
+decisions was decided but was never implemented, and the second is still
+pending before the TC, so the track record here is not great, for a
+variety of reasons.)  But as matters stand right now, there's no way for
+the Policy process to reach a conclusion on questions like this.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:27:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:27:08 GMT) (full text, mbox, link).

+ +

Message #6331 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Paul Tagliamonte <paultag@debian.org>
+
Cc: Bdale Garbee <bdale@gag.com>, debian-ctte@lists.debian.org, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Sat, 8 Feb 2014 15:24:34 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Feb 08, 2014 at 05:46:07PM -0500, Paul Tagliamonte wrote:
+> > This should not be our priority.  Our purpose
+> > here is to make sound technical decisions on behalf of the project, not to
+> > preserve the TC's (or Debian's) "reputation" among third parties who have no
+> > legitimate say in the outcome.
+
+> At this point, it's blocking folks inside Debian, who are stakeholders.
+> It's not just the trolls of reddit and the internet, it's DDs who are
+> annoyed there's no decision and integration work isn't started. We're
+> less than a year from freeze.
+
+Annoyed, yes.  Blocked, no.  There has never been anything blocking any
+Debian developer from doing work on improving the integration of systemd in
+Debian, on their own packages or on the packages of others.  This has always
+been possible, without making systemd the default at all.
+
+If anyone *does* think they are blocked in doing this integration work
+because the default has not been decided, that can only be because of a
+misunderstanding of what deciding the default *means*.  And that is
+precisely why I don't think it's good for the TC to send such an easily
+misinterpreted message by deciding the default without addressing the
+surrounding issues.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:39:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:39:17 GMT) (full text, mbox, link).

+ +

Message #6336 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Kurt Roeckx <kurt@roeckx.be>
+
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 727708@bugs.debian.org, debian-policy@lists.debian.org, Didier 'OdyX' Raboud <odyx@debian.org>, secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Sat, 08 Feb 2014 15:30:10 -0800
+
+
Steve Langasek <vorlon@debian.org> writes:
+
+> I question the whole notion of DPL delegation of policy powers to the
+> policy editors.  The power to decide the contents of the debian-policy
+> package follows from their status as package maintainers; package
+> maintenance is not something that I believe it's in the purview of the
+> DPL to delegate.
+
+This came up in the discussion over the delegation text.  I disagree with
+this characterization of the Policy Editor role, and I think the other
+Policy Editors also disagree.  I don't think we are just package
+maintainers in the normal sense.  The debian-policy package is an artifact
+of the process and a means for documenting its results, not the only
+purpose of the group.
+
+If debian-policy were merely a package like any other, then anyone else
+who introduced a similar package into the archive would have the same role
+within the project as the debian-policy package maintainers.  I don't
+think this is how the project actually looks at the matter.  The Lintian
+maintainers, the release team, the ftp-masters, and many other teams in
+Debian take formal notice of the acts of the Policy Editors in a way that
+wouldn't equally apply to some other package that people introduced into
+the archive, and would continue to do so even if the results weren't
+published as a Debian package.
+
+> I'm not arguing that I don't think the policy editors are doing a good
+> job - I'm grateful to them for the work they do.
+
+I'm definitely *not* doing a good job as a Policy Editor at the moment,
+but that's neither here nor there.  :)
+
+> But constitutionally, I think the DPL doesn't have any authority to
+> delegate the power to decide technical policy (which is a power reserved
+> to the TC in the absence of consensus), only the power to act as
+> recognized facilitators for policy discussions (i.e., the previous
+> delegation that was in place).
+
+This was basically the approach that I took in the delegation discussion,
+and I still think it's basically correct.  The job of that role is to try
+to document and coordinate discussions about the technical policy of the
+project.  Formal decision-making in the event of a conflict rests with the
+TC; the Policy Editor role is to try to dispose of the vast majority of
+issues which do not require a formal discussion process or a vote.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:39:20 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:39:20 GMT) (full text, mbox, link).

+ +

Message #6341 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Sat, 8 Feb 2014 18:34:56 -0500
+
+
On Fri, Feb 7, 2014 at 5:37 PM, Paul Tagliamonte wrote:
+> On Fri, Feb 07, 2014 at 02:27:25PM -0800, Steve Langasek wrote:
+>> So I don't think any
+>> maintainers should feel blocked on this by the lack of a formal vote; I
+>> certainly don't think that the conclusion of the vote is the only blocker
+>> for switching the default init system in jessie today [..]
+>
+> We really need to get a proper vote on this written on paper. We really
+> do. It's the case where we need a direction and we need some body
+> (frankly, at this point, it doesn't matter who) to say "This is the init
+> system for jessie on Linux"
+
+Prior to any change, the project should be assuming no change (i.e.
+sysvinit).  Any inhibition on init system work is currently
+self-imposed (excepting the logind issue).
+
+The logind issue is legitimately blocking some progress, but that only
+more clearly illustrates the fundamental problem.  That logind issue
+is the one that needs referral to the TC, but no one has done that
+yet.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:45:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:45:09 GMT) (full text, mbox, link).

+ +

Message #6346 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: Bdale Garbee <bdale@gag.com>, debian-ctte@lists.debian.org, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Sat, 8 Feb 2014 18:40:23 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Feb 08, 2014 at 03:24:34PM -0800, Steve Langasek wrote:
+> > At this point, it's blocking folks inside Debian, who are stakeholders.
+> > It's not just the trolls of reddit and the internet, it's DDs who are
+> > annoyed there's no decision and integration work isn't started. We're
+> > less than a year from freeze.
+> 
+> Annoyed, yes.  Blocked, no.  There has never been anything blocking any
+> Debian developer from doing work on improving the integration of systemd in
+> Debian, on their own packages or on the packages of others.  This has always
+> been possible, without making systemd the default at all.
+
+I understand you think that, and I empathize, but I disagree.
+
+The fact is, I have limited time. If I'm going to focus on making a
+bigger impact with my work, I'm going to stick to dealing with issues
+that effect the most users.
+
+I don't care about the init system all that much, in the end, it's not
+important. I do care about ensuring we have something maintainable and
+stable.
+
+As soon as we settle which init system is default (and by a rough count,
+I believe this issue is resolved now, thank you TC :) ), I can start
+spending time on ensuring we have a polished distro throughout this
+change by testing, and contributing patches when I hit issues that I
+have time to fix.
+
+I think this is the norm. I assure you it was not only annoying, but
+also blocking.
+
+> If anyone *does* think they are blocked in doing this integration work
+> because the default has not been decided, that can only be because of a
+> misunderstanding of what deciding the default *means*.
+
+I don't grok. Default means it's going to be used by all users unless
+they're technical enough to change it, in which case, I care slighly
+less, since they're able to fix it and provide patches when they hit
+issues.
+
+> And that is
+> precisely why I don't think it's good for the TC to send such an easily
+> misinterpreted message by deciding the default without addressing the
+> surrounding issues.
+
+I understand why you might think that, but I believe it to not be
+entirely in-line with how many view the situation.
+
+Cheers,
+  Paul
+
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
+: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+`. `'`  http://people.debian.org/~paultag
+ `-     http://people.debian.org/~paultag/conduct-statement.txt
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:45:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:45:12 GMT) (full text, mbox, link).

+ +

Message #6351 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sat, 8 Feb 2014 18:43:40 -0500
+
+
On Sat, Feb 8, 2014 at 6:23 PM, Russ Allbery wrote:
+> Michael Gilbert writes:
+>> Why not hammer that out on -policy in public, and only if something goes
+>> wrong there, then defer it to the TC?
+>
+> Because -policy doesn't have a decision-making process other than
+> consensus, so Ian's objections to all of the positions shy of L and my
+> objections to L would deadlock and effectively block the -policy
+> discussion from ever reaching a decision.  There is no method for either
+> of us to be overridden.
+
+But at least it would follow the usual process, and only when
+consensus does actually fail does the TC need to mediate.
+
+There would also presumably be proposed diffs to the policy text from
+both sides for the TC to review, and decide among the options, and
+that would be far more nuanced than this or that init as currently
+proposed.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:45:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:45:15 GMT) (full text, mbox, link).

+ +

Message #6356 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Cc: Sam Hartman <hartmans@debian.org>
+
Subject: Re: Bug#727708: Please clarify L options with regard to interfaces
+
Date: Sat, 8 Feb 2014 15:44:23 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Feb 07, 2014 at 01:44:42PM +0000, Ian Jackson wrote:
+> Sam Hartman writes ("Bug#727708: Please clarify L options with regard to interfaces"):
+> > * Colin said that it would be OK to depend on a stable interface such as
+> >   logind-208 provided that multiple implementations could exist.
+
+> Colin, I think you need to clarify this.  I think it matters very much
+> whether multiple implementations _do_ exist.
+
+> > * Ian said that this dependency would not be OK.
+
+> > I'd like the ballot options to clarify:
+
+> > 1) Whether these interface dependencies are acceptable
+
+> I don't have an opinion on the technical implementation details such
+> as dependencies.
+
+> > 2) Whether they are acceptable in cases where there is only one
+> > implementation.
+
+> My view on that is "no".  The key question for me is whether it is
+> actually possible to use a different init system.
+
+So my view on this is a strong "yes", because:
+
+ - The Debian TC saying "no" will not stop upstreams from making use of
+   these interfaces if they exist (or not enough upstreams for it to
+   matter).
+ - It's not the responsibility of systemd upstream to make these dbus
+   interfaces available on upstart, it's the responsibility of the upstart
+   community to do so; and Debian should not artificially retard the
+   evolution of systemd's interfaces with a requirement that they be
+   available on non-systemd systems before they can be used in the
+   distribution.
+
+I think there is value in Debian not being tied irrevocably to systemd
+upstream.  The upstream policy of component bundling has already been a
+problem for Debian, and I believe it will continue to be a problem in the
+future.  But I think the way to achieve such independence is by like-minded
+developers working together to provide the necessary technical solutions on
+top of other init systems, not by using the TC's power to block Debian from
+taking advantage of software features that make the distribution better out
+of the box.
+
+We can and should make sure the preconditions are in place so that *if*
+developers care about keeping non-systemd init usable in Debian, they have a
+fair shot at doing this.  But we shouldn't go beyond that; and I think
+requiring multiple implementations of the dbus interfaces to be in place
+before other software can make use of them in the distro, as a top-down,
+hard and fast rule, does go beyond that.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:51:16 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:51:16 GMT) (full text, mbox, link).

+ +

Message #6361 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Paul Tagliamonte <paultag@debian.org>
+
Cc: Bdale Garbee <bdale@gag.com>, debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sat, 08 Feb 2014 15:48:26 -0800
+
+
Paul Tagliamonte <paultag@debian.org> writes:
+
+> As soon as we settle which init system is default (and by a rough count,
+> I believe this issue is resolved now, thank you TC :) )
+
+It's not.  All ballot options have to have a majority above FD in order to
+be eligible to win the ballot.  At least one more person has to vote
+another option above FD for there to be a winner other than FD.
+
+If all remaining TC members vote FD first, FD wins.  That would be the way
+of indicating support for Ian's position that we should not hold
+independent votes.
+
+If all remaining TC members other than one vote FD first and the remaining
+one votes something else first, that option wins, since our resolution
+method fails later-no-harm spectacularly.  As Steve points out, all those
+who have voted so far have voted in explicit disregard to this
+possibility.  I did so on the grounds that I refuse to vote tactically at
+that level, and it sounds like Steve is of a similar feeling.
+
+FWIW, that's also why I want to vote the issues separately, since it
+avoids a giant tactical morass.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:51:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:51:19 GMT) (full text, mbox, link).

+ +

Message #6366 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sat, 08 Feb 2014 23:50:00 +0000
+
+
[Message part 1 (text/plain, inline)]
+
On 08/02/14 23:24, Steve Langasek wrote:
+> There has never been anything blocking any
+> Debian developer from doing work on improving the integration of systemd in
+> Debian, on their own packages or on the packages of others.
+
+OTOH I'm eagerly awaiting the TC's decision[s] because it will likely
+influence the direction of the non-Linux ports.
+
+If Upstart had won somehow, most people working on GNU/kFreeBSD seemed
+willing to adopt it on those grounds.  But it no longer seems the likely
+choice for GNU/Linux.
+
+And assuming systemd wins, a policy decision on dependencies and level
+of coupling may lead to ports either supporting or dropping certain
+packages, or a whole desktop environment.
+
+IMHO it was a little frustrating that Ian's ballot couldn't go ahead
+last week and reach a consensus on both issues.
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:54:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:54:19 GMT) (full text, mbox, link).

+ +

Message #6371 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Michael Gilbert <mgilbert@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sat, 08 Feb 2014 15:52:13 -0800
+
+
Michael Gilbert <mgilbert@debian.org> writes:
+> On Sat, Feb 8, 2014 at 6:23 PM, Russ Allbery wrote:
+
+>> Because -policy doesn't have a decision-making process other than
+>> consensus, so Ian's objections to all of the positions shy of L and my
+>> objections to L would deadlock and effectively block the -policy
+>> discussion from ever reaching a decision.  There is no method for
+>> either of us to be overridden.
+
+> But at least it would follow the usual process, and only when
+> consensus does actually fail does the TC need to mediate.
+
+If you're looking for Policy Editors who enjoy running things through a
+process that won't be successful just so that we can say they've been run
+through a process, you're going to need someone other than me.  I find
+that sort of thing to be tedious in the extreme and a giant waste of
+everyone's time.  I have about four thousand things I could be working on
+in Debian that would be more useful than going through that exercise.
+
+> There would also presumably be proposed diffs to the policy text from
+> both sides for the TC to review, and decide among the options, and
+> that would be far more nuanced than this or that init as currently
+> proposed.
+
+I certainly hope that no one would spend lots of time drafting wording
+without some broad agreement on what we wanted to say.  It's rare that the
+question really rests on some point of minor nuance or phrasing; it's
+better to hash out rough, broad statements until we get to some general
+point of agreement and then work on diffs.  Otherwise, again, you run the
+risk of wasting a bunch of people's time.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:54:22 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:54:22 GMT) (full text, mbox, link).

+ +

Message #6376 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Steven Chamberlain <steven@pyro.eu.org>
+
Cc: 727708@bugs.debian.org, Steve Langasek <vorlon@debian.org>
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sat, 08 Feb 2014 15:53:40 -0800
+
+
Steven Chamberlain <steven@pyro.eu.org> writes:
+
+> IMHO it was a little frustrating that Ian's ballot couldn't go ahead
+> last week and reach a consensus on both issues.
+
+I would be very interested in your comments, from the perspective of a
+non-Linux port maintainer, on the language that Steve and I have been
+discussing.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:57:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:57:11 GMT) (full text, mbox, link).

+ +

Message #6381 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Russ Allbery <rra@debian.org>
+
Cc: Paul Tagliamonte <paultag@debian.org>, Bdale Garbee <bdale@gag.com>, + debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Sat, 08 Feb 2014 23:46:41 -0008
+
+
[Message part 1 (text/plain, inline)]
+
El Sat, 8 de Feb 2014 a las 3:48 PM, Russ Allbery <rra@debian.org> 
+escribió:
+> Paul Tagliamonte <paultag@debian.org> writes:
+> 
+>>  As soon as we settle which init system is default (and by a rough 
+>> count,
+>>  I believe this issue is resolved now, thank you TC :) )
+>> 
+> It's not.  All ballot options have to have a majority above FD in 
+> order to
+> be eligible to win the ballot.  At least one more person has to vote
+> another option above FD for there to be a winner other than FD.
+> 
+> If all remaining TC members vote FD first, FD wins.  That would be 
+> the way
+> of indicating support for Ian's position that we should not hold
+> independent votes.
+> 
+
+I think it moreso indicates that if there are separate votes, that the 
+init system choice can not be first. I do wonder, how many TC members 
+would support voting on GR, then on T/L (or whatever it is you, Colin, 
+and Steve are working on), then on the init system?
+
+--
+Cameron Norman
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 08 Feb 2014 23:57:22 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 08 Feb 2014 23:57:22 GMT) (full text, mbox, link).

+ +

Message #6386 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sat, 8 Feb 2014 18:56:10 -0500
+
+
On Sat, Feb 8, 2014 at 6:40 PM, Paul Tagliamonte wrote:
+> I understand you think that, and I empathize, but I disagree.
+>
+> The fact is, I have limited time. If I'm going to focus on making a
+> bigger impact with my work, I'm going to stick to dealing with issues
+> that effect the most users.
+>
+> I don't care about the init system all that much, in the end, it's not
+> important. I do care about ensuring we have something maintainable and
+> stable.
+
+Why bring such a controversial and polarizing issue before the TC if
+the outcome doesn't matter much to you?
+
+sysvinit is maintainable and stable, so why seek to change it?
+
+Paul, you know I think you're awesome, but you've stirred up a whole
+lot of trouble here with a questionable motive.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 00:03:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cameron Norman <camerontnorman@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 00:03:09 GMT) (full text, mbox, link).

+ +

Message #6391 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cameron Norman <camerontnorman@gmail.com>
+
To: Michael Gilbert <mgilbert@debian.org>, 727708@bugs.debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Sat, 08 Feb 2014 23:53:03 -0008
+
+
[Message part 1 (text/plain, inline)]
+
El Sat, 8 de Feb 2014 a las 3:56 PM, Michael Gilbert 
+<mgilbert@debian.org> escribió:
+> On Sat, Feb 8, 2014 at 6:40 PM, Paul Tagliamonte wrote:
+>>  I understand you think that, and I empathize, but I disagree.
+>> 
+>>  The fact is, I have limited time. If I'm going to focus on making a
+>>  bigger impact with my work, I'm going to stick to dealing with 
+>> issues
+>>  that effect the most users.
+>> 
+>>  I don't care about the init system all that much, in the end, it's 
+>> not
+>>  important. I do care about ensuring we have something maintainable 
+>> and
+>>  stable.
+>> 
+> Why bring such a controversial and polarizing issue before the TC if
+> the outcome doesn't matter much to you?
+> 
+> sysvinit is maintainable and stable, so why seek to change it?
+> 
+
+Perhaps the movement in GNOME to depend on a number of systemd provided 
+interfaces has led Paul to believe that sysvinit is unmaintainable? 
+AFAIR, systemd-shim was not available when he presented the question to 
+the TC (or am I mistaken?).
+
+--
+Cameron
+
+
+
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 00:06:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 00:06:14 GMT) (full text, mbox, link).

+ +

Message #6396 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sat, 8 Feb 2014 19:03:34 -0500
+
+
On Sat, Feb 8, 2014 at 6:52 PM, Russ Allbery wrote:
+>> But at least it would follow the usual process, and only when
+>> consensus does actually fail does the TC need to mediate.
+>
+> If you're looking for Policy Editors who enjoy running things through a
+> process that won't be successful just so that we can say they've been run
+> through a process, you're going to need someone other than me.  I find
+> that sort of thing to be tedious in the extreme and a giant waste of
+> everyone's time.  I have about four thousand things I could be working on
+> in Debian that would be more useful than going through that exercise.
+
+That's only true if someone does actually get in the way.  There may
+actually be a clear path to consensus at this point, given that you
+already seem to have people from both D and U sides apparently
+agreeing in private.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 00:21:24 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 00:21:24 GMT) (full text, mbox, link).

+ +

Message #6401 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Michael Gilbert <mgilbert@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sat, 08 Feb 2014 16:17:43 -0800
+
+
Michael Gilbert <mgilbert@debian.org> writes:
+> On Sat, Feb 8, 2014 at 6:52 PM, Russ Allbery wrote:
+
+>> If you're looking for Policy Editors who enjoy running things through a
+>> process that won't be successful just so that we can say they've been
+>> run through a process, you're going to need someone other than me.  I
+>> find that sort of thing to be tedious in the extreme and a giant waste
+>> of everyone's time.  I have about four thousand things I could be
+>> working on in Debian that would be more useful than going through that
+>> exercise.
+
+> That's only true if someone does actually get in the way.  There may
+> actually be a clear path to consensus at this point, given that you
+> already seem to have people from both D and U sides apparently agreeing
+> in private.
+
+There aren't any private discussions about the T and L options between TC
+members that aware of, for whatever it's worth.  All the discussion is
+here on the bug.  We got to a place where we're hammering out something
+we're all happy with only in the context of a decision-making process and
+two failed votes, and only by discussing options that one of the parties
+to the discussion has explicitly rejected as unacceptable.
+
+Look, I've been involved in Policy work for years now.  I think I have a
+pretty good intuition for what sort of questions can be dealt with
+usefully in that framework and which ones can't.  You're certainly
+entitled to think that I'm wrong, but it's unlikely that I'm going to
+change my mind on this particular question, since I don't think it's even
+close.
+
+It's hard to avoid the feeling that you'd rather not have the TC discuss
+this question since the TC is arriving at a conclusion that you don't
+like.  That's understandable, but I don't think the results are going to
+be any more to your liking regardless of the forum, whether it be the TC,
+a GR, or Policy.  I certainly don't believe, after having waded through
+most of the debian-devel threads on the topic, that the project was going
+to suddenly realize that everyone had good points and arrive at an
+amicable consensus.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 00:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 00:27:04 GMT) (full text, mbox, link).

+ +

Message #6406 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: Steven Chamberlain <steven@pyro.eu.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Sat, 8 Feb 2014 16:23:58 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Feb 08, 2014 at 03:53:40PM -0800, Russ Allbery wrote:
+> Steven Chamberlain <steven@pyro.eu.org> writes:
+
+> > IMHO it was a little frustrating that Ian's ballot couldn't go ahead
+> > last week and reach a consensus on both issues.
+
+> I would be very interested in your comments, from the perspective of a
+> non-Linux port maintainer, on the language that Steve and I have been
+> discussing.
+
+FWIW, it occurred to me about a week ago that, although we've been
+discussing a question that has implications for all of Debian ports (even if
+the current ballot only considers the Linux ports), at no time has the TC
+actually asked the Hurd and FreeBSD porters for input - aside from those who
+have found their own way to this bug.  Considering that some of the
+discussions have made assumptions about what the porters will be inclined to
+implement given a particular decision by the TC, I think this is an
+oversight that we should correct by explicitly reaching out to the porter
+lists.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 00:30:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 00:30:04 GMT) (full text, mbox, link).

+ +

Message #6411 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Sun, 09 Feb 2014 01:27:03 +0100
+
+
]] Adrian Bunk 
+
+> On Sat, Feb 08, 2014 at 12:38:21PM -0800, Russ Allbery wrote:
+> >...
+> > I don't see any reason why,
+> > say, mountall or socklog-run should be required to support sysvinit.
+> >...
+> 
+> What about udev?
+
+We will continue supporting udev at the current level for the jessie
+release cycle.
+
+Can you please find another dead horse to flog soon?
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 00:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 00:33:05 GMT) (full text, mbox, link).

+ +

Message #6416 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sat, 8 Feb 2014 19:29:05 -0500
+
+
On Sat, Feb 8, 2014 at 7:17 PM, Russ Allbery wrote:
+> Look, I've been involved in Policy work for years now.  I think I have a
+> pretty good intuition for what sort of questions can be dealt with
+> usefully in that framework and which ones can't.  You're certainly
+> entitled to think that I'm wrong, but it's unlikely that I'm going to
+> change my mind on this particular question, since I don't think it's even
+> close.
+>
+> It's hard to avoid the feeling that you'd rather not have the TC discuss
+> this question since the TC is arriving at a conclusion that you don't
+> like.
+
+It's not that I dislike any particular conclusion, it is that I
+dislike the apparent rush toward conclusion.  The TC is a deliberative
+body that is only supposed to act when all normal means have been
+exhausted.  The fact that no policy discussion ever happened means
+that something has really going wrong here.
+
+I'd be happy to see a change post-jessie, but I feel like it is a
+self-imposed rush to push anything through for jessie.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 00:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 00:45:04 GMT) (full text, mbox, link).

+ +

Message #6421 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sun, 09 Feb 2014 01:41:23 +0100
+
+
]] Steve Langasek 
+
+> Annoyed, yes.  Blocked, no.  There has never been anything blocking any
+> Debian developer from doing work on improving the integration of systemd in
+> Debian, on their own packages or on the packages of others.  This has always
+> been possible, without making systemd the default at all.
+
+It seems a bit pointless to start doing the work on how to change the
+default to systemd until that was actually decided.  Once we have a
+decision (and assuming that the default will be systemd), I was planning
+on starting at looking at how to best do the transition.
+
+So maybe not blocked as such, but «annoyed and unwilling to spend effort
+that might be wasted».
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 02:12:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Tagliamonte <paultag@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 02:12:04 GMT) (full text, mbox, link).

+ +

Message #6426 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Tagliamonte <paultag@debian.org>
+
To: Michael Gilbert <mgilbert@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Sat, 8 Feb 2014 21:08:27 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Feb 08, 2014 at 06:56:10PM -0500, Michael Gilbert wrote:
+> Why bring such a controversial and polarizing issue before the TC if
+> the outcome doesn't matter much to you?
+
+OK, phrased badly. I don't care what it is, so long as it's not
+sysvinit :)
+
+I believe it to be broken, and not a future-proof solution, and I
+assumed that was sorta taken for granted that others agreed. The general
+consensus[0] is that sysvinit is not a solution going forward.
+
+> sysvinit is maintainable and stable, so why seek to change it?
+
+It's stable, but it's not going to be maintainable in the long-run, and
+I believe it will become unmaintainable very soon.
+
+> Paul, you know I think you're awesome, but you've stirred up a whole
+> lot of trouble here with a questionable motive.
+
+What motive is that, if I might ask?[1] :)
+
+We were already flaming pretty hard, it was out of control, it was in
+the best interest of everyone to get it resolved in a quick way. I
+believed (and still believe) the TC was the best way out of the
+situation, so I did the natrual thing.
+
+I care in so far as we are able to keep Debian maintainable and use
+software that allows future releases[2] to get sent to users without
+fuss.
+
+> Best wishes,
+> Mike
+
+Much love,
+  Paul
+
+[0]: Yes, I know tg disagrees.
+[1]: Assuming ill intent are we?
+[2]: of Debian itself and new upstream releases (say, GNOME)
+
+-- 
+ .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
+: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
+`. `'`  http://people.debian.org/~paultag
+ `-     http://people.debian.org/~paultag/conduct-statement.txt
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 02:27:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 02:27:17 GMT) (full text, mbox, link).

+ +

Message #6431 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sat, 8 Feb 2014 21:23:43 -0500
+
+
On Sat, Feb 8, 2014 at 9:08 PM, Paul Tagliamonte wrote:
+> On Sat, Feb 08, 2014 at 06:56:10PM -0500, Michael Gilbert wrote:
+>> Paul, you know I think you're awesome, but you've stirred up a whole
+>> lot of trouble here with a questionable motive.
+>
+> What motive is that, if I might ask?[1] :)
+> [1]: Assuming ill intent are we?
+
+Not my intent to give that impression at all.  I know you have the
+best of intentions, but the phrasing of the question posed lead the TC
+in a very specific high controversy direction.
+
+I think it would have been better to ask for some smaller less
+controversial decisions solving existing known init system related
+problems (like logind), and once enough of those were decided, it
+would probably be abundantly clear which default the init should
+change to.
+
+Instead, none of the important implementation related stuff has been discussed.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 02:30:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 02:30:07 GMT) (full text, mbox, link).

+ +

Message #6436 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sat, 8 Feb 2014 21:25:41 -0500
+
+
On Sat, Feb 8, 2014 at 9:23 PM, Michael Gilbert wrote:
+> Instead, none of the important implementation related stuff has been discussed.
+
+Correction, a lot of that has been discussed, but there has been no
+progress on it due to the distraction on the bigger political problem.
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 02:36:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 02:36:05 GMT) (full text, mbox, link).

+ +

Message #6441 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Cc: Michael Gilbert <mgilbert@debian.org>
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sun, 9 Feb 2014 12:34:15 +1000
+
+
On 9 February 2014 09:52, Russ Allbery <rra@debian.org> wrote:
+> If you're looking for Policy Editors who enjoy running things through a
+> process that won't be successful just so that we can say they've been run
+> through a process, you're going to need someone other than me.
+
+In that case, wouldn't it make sense to have a quick chat with the
+other policy editors about officially delegating the task of deciding
+on policy for depending on init systems to the tech ctte?
+
+Could even open a new bug for it!
+
+Cheers,
+aj
+
+-- 
+Anthony Towns <aj@erisian.com.au>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 03:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 03:09:04 GMT) (full text, mbox, link).

+ +

Message #6446 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org, + Steve Langasek <vorlon@debian.org>
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Sun, 09 Feb 2014 03:04:40 +0000
+
+
[Message part 1 (text/plain, inline)]
+
Hi,
+
+Thank you both for inviting comments on this from a porter's POV.
+
+Steve Langasek <vorlon@debian.org> writes:
+>>  - Packages in jessie must retain compatibility with sysvinit startup
+>>    interfaces (i.e., init scripts in /etc/init.d).
+
+This would be greatly reassuring;  if adopting systemd, this is IMHO the
+primary concern for the non-Linux ports (and of using other init systems
+on GNU/Linux).  I don't know how willing maintainers are to accept it,
+but I assume there are multiple reasons to still maintain sysvinit
+scripts in jessie:
+
+1. a smooth upgrade process
+2. ease of backporting, perhaps
+3. for the benefit of using other init systems on GNU/Linux
+4. for the benefit of non-systemd ports
+
+If 4. had been the only reason, I think porters would accept some number
+of packages becoming linux-any, to avoid burdening their maintainers
+unreasonably.  (Similarly, we may yet be unable to support packages
+requiring logind, if nobody ports it).
+
+On 08/02/14 20:38, Russ Allbery wrote:
+>     Package maintainers are strongly encouraged to merge any contributions
+>     for support of init systems other than the Linux default, and to add
+>     that support themselves if they're willing and capable of doing so.
+>     In particular, package maintainers should put a high priority on
+>     merging changes to support any init system which is the default on one
+>     of Debian's non-Linux ports.
+
+A quick poll on the debian-bsd@ list showed that if Upstart had been
+chosen as default on GNU/Linux, it would have been favoured on
+GNU/kFreeBSD, too.  (BTW I'm extremely thankful to Dimitri and any
+others at Canonical who made efforts to port it).
+
+But otherwise, given systemd as default, the overall preference was to
+keep using sysvinit for jessie (which surprised me, as this wasn't my
+own preference).  In second place would be OpenRC (4:0 over Upstart,
+again surprising as it is a reversal of the above).
+
+https://lists.debian.org/debian-bsd/2014/01/msg00300.html
+
+A draft statement on the debian-hurd@ list asks that sysvinit scripts
+remain in place, and proposes that GNU/Hurd porters help maintain them,
+being keen to adopt OpenRC later:
+
+https://lists.debian.org/debian-hurd/2014/01/msg00051.html
+
+This actually sounds beneficial all around.  If porters were only
+writing OpenRC runscripts, that wouldn't help much with the need to
+anyway keep the sysvinit scripts maintained:  work that benefits
+GNU/Linux users too.
+
+What I also like about this is that non-default init systems will all
+have plenty of time to evolve (or appear, or disappear);  I'm hopeful
+that for jessie+1 the successor to sysvinit will have become obvious.
+
+So Russ's paragraph above, referring to the default init system on
+non-Linux ports - if that is going to be sysvinit - would have
+effectively the same meaning as the following:
+
+>     For the jessie release, all packages that currently support being run
+>     under sysvinit should continue to support sysvinit unless there is no
+>     technically feasible way to do so.  Reasonable changes to preserve or
+>     improve sysvinit support should be accepted through the jessie
+>     release.
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
[signature.asc (application/pgp-signature, attachment)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 09:54:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Richard Hartmann <richih.mailinglist@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 09:54:05 GMT) (full text, mbox, link).

+ +

Message #6451 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Richard Hartmann <richih.mailinglist@gmail.com>
+
To: Don Armstrong <don@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sun, 9 Feb 2014 10:52:19 +0100
+
+
On Sat, Feb 8, 2014 at 11:51 PM, Don Armstrong <don@debian.org> wrote:
+> I vote D > U > O > V > F.
+
+I would appreciate it if you could reply to self with signed mail
+re-stating this.
+
+
+Thanks,
+Richard
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 11:24:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 11:24:10 GMT) (full text, mbox, link).

+ +

Message #6456 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, + 727708@bugs.debian.org, Russ Allbery <rra@debian.org>, + debian-policy@lists.debian.org, + Didier 'OdyX' Raboud <odyx@debian.org>, secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Sun, 9 Feb 2014 12:21:18 +0100
+
+
On Sat, Feb 08, 2014 at 03:13:36PM -0800, Steve Langasek wrote:
+> 
+> I question the whole notion of DPL delegation of policy powers to the policy
+> editors.
+
+Can I suggest you start a GR about if you think the DPL is maing
+decisions he can not make?
+
+I also suggest you re-read Neil's text on the subject, because it
+does have room for interpretation.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 11:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Emilio Pozuelo Monfort <pochu@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 11:36:05 GMT) (full text, mbox, link).

+ +

Message #6461 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Emilio Pozuelo Monfort <pochu@debian.org>
+
To: Didier 'OdyX' Raboud <odyx@debian.org>, 727708@bugs.debian.org
+
Cc: secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Sun, 09 Feb 2014 12:33:02 +0100
+
+
On 07/02/14 16:43, Didier 'OdyX' Raboud wrote:
+> Back then, the gnome maintainers added a dependency on another package, 
+> which happened to be providing an /sbin/init.
+
+That's plain wrong.
+
+Emilio
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 11:51:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Didier 'OdyX' Raboud" <odyx@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 11:51:09 GMT) (full text, mbox, link).

+ +

Message #6466 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Didier 'OdyX' Raboud" <odyx@debian.org>
+
To: Emilio Pozuelo Monfort <pochu@debian.org>
+
Cc: 727708@bugs.debian.org, secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Sun, 09 Feb 2014 12:48:36 +0100
+
+
Le dimanche, 9 février 2014, 12.33:02 Emilio Pozuelo Monfort a écrit :
+> On 07/02/14 16:43, Didier 'OdyX' Raboud wrote:
+> > Back then, the gnome maintainers added a dependency on another
+> > package, which happened to be providing an /sbin/init.
+> 
+> That's plain wrong.
+
+Fair enough, I was being imprecise: gnome-settings-daemon got a 
+dependency on systemd, which triggered the debian-devel thread at [0]. 
+The rest of what I wrote stands: this move was allowed by all policies 
+of the time.
+
+[0] https://lists.debian.org/debian-devel/2013/10/msg00444.html
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 13:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Didier 'OdyX' Raboud" <odyx@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 13:03:04 GMT) (full text, mbox, link).

+ +

Message #6471 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Didier 'OdyX' Raboud" <odyx@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for votes on init system resolution
+
Date: Sun, 09 Feb 2014 13:59:08 +0100
+
+
Hi Steve,
+
+Le vendredi, 7 février 2014, 13.07:54 Steve Langasek a écrit :
+> Here's what I think is the right technical policy, that we should be
+> addressing with this resolution.
+> 
+>  - Packages in jessie must retain compatibility with sysvinit startup
+>    interfaces (i.e., init scripts in /etc/init.d).
+>  - Packages can require other interfaces for their operation that are
+>    provided by an init system implementation, but which are unrelated
+> to service management; however, these requirements must be expressed
+> in a way that does not tie them to a single init system package. 
+> E.g., a package that uses the logind dbus interfaces is absolutely
+> free to do so, but must not express this usage as 'Depends: systemd'.
+>  - The TC should make no ruling at this time regarding releases beyond
+> jessie.
+
+I'm quite surprised by this proposal: given the state of the 
+discussions, I have the impression that it mostly is the actual 
+consensus for jessie. More specifically: 
+
+* "packages in jessie must retain compatibility with sysvinit startup
+  interfaces" was not challenged given the constraints of stable-
+  -to-stable upgrades.
+* "packages can require other interfaces for their operation that are
+  provided by an init system implementation (…) E.g., a package that
+  uses the logind dbus interfaces is absolutely free to do so, but must
+  not express this usage as 'Depends: systemd'." I don't have the
+  impression that either the logind interface maintainers or the logind
+  consumer maintainers wouldn't have reached that consensus point by
+  themselves. The only blocker that I remember was that people didn't
+  want to invest time on ironing details without knowing what the
+  default init would be.
+
+A resolution along these lines assumes that the relevant maintainers 
+would fail to reach these consensual points by themselves: it would 
+unnecessarily paternalize them and would show little trust in said 
+maintainers.
+
+Sorry to insist, but the "relevant maintainers" (which, in these cases, 
+wouldn't be the policy editors, but systemd maintainers probably) 
+haven't had a chance to make initial decisions and I think the TC 
+wouldn't be acting as "last resort" here, but as "preemptive early 
+resort", which is uncalled for as far as I'm concerned.
+
+That said, reformulating the resolution to read as an advice (aka "we 
+expect maintainers of packages in jessie to retain compatibility …"), 
+and deciding it under 6.1.5 would be totally fine.
+
+Cheers, OdyX
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 13:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 13:09:05 GMT) (full text, mbox, link).

+ +

Message #6476 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Sun, 9 Feb 2014 13:04:31 +0000
+
+
[Message part 1 (text/plain, inline)]
+
On Sat, Feb 08, 2014 at 12:49:37PM -0700, Bdale Garbee wrote:
+> I have carefully considered Ian's current proposal for a process and
+> schedule to reach a next ballot on the init system issue, and do not
+> believe it is the best way for us to proceed.
+> 
+> The fundamental problem is that I remain as convinced now as I was when
+> I posted my last CFV that conflating multiple questions in a single
+> ballot is a bad idea.  Our voting system works exceptionally well when
+> we're trying to choose between multiple alternatives for a single
+> question.  But as others have observed, trying to mix questions into a
+> matrix of alternatives in a single ballot really complicates the
+> process.  I believe it both tempts us all to take a more tactical
+> approach to voting than appropriate, and increases the risk of stumbling
+> over corner cases in the process which could lead to surprising results.
+
+I have a lot of sympathy with Ian's position here, hence my previous FD
+votes; I think we do need to finish hashing this out, and it was
+valuable to run the combined votes (even abortively) since the
+combination certainly could have made a significant and important
+difference.  However, looking through the votes cast so far, I do not
+see how separating them is actually going to make a discernible
+difference to the outcome of either part, and so I don't feel that I can
+personally justify holding things up any more for this.  I also hope
+that resolving this part will vent a little pressure so that we can deal
+with the rest more effectively.
+
+> As per Constitution 6.3.1, I call for an immediate vote on the following
+> ballot, with a voting period of one week or until the outcome is no
+> longer in doubt:
+> 
+> - - - start ballot - - -
+> 
+> We exercise our power to decide in cases of overlapping jurisdiction
+> (6.1.2) by asserting that the default init system for Linux
+> architectures in jessie should be
+> 
+>   D    systemd 
+> 
+>   U    upstart
+> 
+>   O    openrc
+> 
+>   V    sysvinit (no change)
+> 
+>   F    requires further discussion
+> 
+> Should the project pass a General Resolution before the release of
+> "jessie" asserting a "position statement about issues of the day" on
+> init systems, that position replaces the outcome of this vote and is
+> adopted by the Technical Committee as its own decision.
+
+I vote UDOFV.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 13:09:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Didier 'OdyX' Raboud" <odyx@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 13:09:08 GMT) (full text, mbox, link).

+ +

Message #6481 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Didier 'OdyX' Raboud" <odyx@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Sun, 09 Feb 2014 14:07:56 +0100
+
+
Le vendredi, 7 février 2014, 14.27:25 Steve Langasek a écrit :
+> (…), what I've seen suggests that systemd integration is currently in
+> a state that would cause terrible regressions for many server users.
+
+Le samedi, 8 février 2014, 14.18:39 Steve Langasek a écrit :
+> I vote F U D (…)
+
+Quite frankly, I don't have much more to add.
+
+Could you please either refrain from blanket statements about the 
+brokenness of systemd or back them with bugreports?
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 13:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Lucas Nussbaum <lucas@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 13:21:05 GMT) (full text, mbox, link).

+ +

Message #6486 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Lucas Nussbaum <lucas@debian.org>
+
To: Kurt Roeckx <kurt@roeckx.be>, 727708@bugs.debian.org
+
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Russ Allbery <rra@debian.org>, debian-policy@lists.debian.org, Didier 'OdyX' Raboud <odyx@debian.org>, secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Sun, 9 Feb 2014 14:16:25 +0100
+
+
On 09/02/14 at 12:21 +0100, Kurt Roeckx wrote:
+> On Sat, Feb 08, 2014 at 03:13:36PM -0800, Steve Langasek wrote:
+> > 
+> > I question the whole notion of DPL delegation of policy powers to the policy
+> > editors.
+> 
+> Can I suggest you start a GR about if you think the DPL is maing
+> decisions he can not make?
+
+The way I understand the current situation is that either:
+1) the policy editors decide on technical policy, and the TC acts as
+a last resort instance -- however, on this specific set of issues, I
+think that the policy editors have expressed that they are happy to
+defer the decision to the TC. So the TC decides;
+2) the policy editors cannot decide on technical policy -- their roles
+are to document the [consensual] technical policies, and organize
+discussions so that such consensus can emerge. The TC decides on
+controversial technical policy.
+
+So, in both cases, it's up to the TC to decide here.
+
+We should probably re-discuss the policy editors delegation to clarify
+the role of this team. However, as long as the TC and the policy editors
+do not disagree on who should make a decision on a specific technical
+policy, I don't think that such a clarification is extremely urgent.
+
+Also, I think that the starting point of such a discussion should be:
+"how do we want to split powers inside Debian on the definition of
+technical policy?" and not "let's try to guess what's the spirit of the
+Constitution on that, and how we can work around it." We should seek an
+efficient model where the policy editors and the TC can work in
+cooperation for the benefit of Debian as a whole, and document that
+model in an update of the policy editors delegation (and maybe, in an
+update of the constitution, if needed).  We should also remember that
+the role of Debian's foundation documents is to help Debian achieve its
+goals by defining a framework. When that framework prevents processes
+that are otherwise consensual, maybe we should question whether it
+shouldn't be slightly redefined.
+
+Lucas
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 14:21:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Matthias Urlichs <matthias@urlichs.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 14:21:09 GMT) (full text, mbox, link).

+ +

Message #6491 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Matthias Urlichs <matthias@urlichs.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Sun, 9 Feb 2014 15:18:07 +0100
+
+
Hi,
+
+Michael Gilbert:
+> I'd be happy to see a change post-jessie, but I feel like it is a
+> self-imposed rush to push anything through for jessie.
+> 
+Given that certain other distributions switched to systemd umpteen months
+ago, I see that less as "rushing" and more as "we're late to the game and
+do NOT want to burden everybody with buggy init scripts, missing features,
+and an unmaintained pseudo-solution (ConsoleKit) for another two+ years".
+
+-- 
+-- Matthias Urlichs
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 14:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Matthias Urlichs <matthias@urlichs.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 14:39:04 GMT) (full text, mbox, link).

+ +

Message #6496 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Matthias Urlichs <matthias@urlichs.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Sun, 9 Feb 2014 15:35:51 +0100
+
+
Hi,
+
+Michael Gilbert:
+> The logind issue is legitimately blocking some progress, but that only
+> more clearly illustrates the fundamental problem.  That logind issue
+> is the one that needs referral to the TC, but no one has done that
+> yet.
+> 
+I don't think so. Gnome wants a logind implementation, systemd delivers
+one, and so does systemd-shim (or will do that, anyway). The details of how
+to make sure that the one or the other is available haven't been hashed out
+yet, but the reason for that is not an impasse between developers.
+(Or at least I don't see one.) Therefore, the TC shouldn't be involved.
+
+-- 
+-- Matthias Urlichs
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 15:30:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Michael Gilbert <mgilbert@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 15:30:07 GMT) (full text, mbox, link).

+ +

Message #6501 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Michael Gilbert <mgilbert@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sun, 9 Feb 2014 10:27:11 -0500
+
+
On Sun, Feb 9, 2014 at 8:04 AM, Colin Watson wrote:
+> I vote UDOFV.
+
+So, this vote effectively gives systemd the win (assuming Bdale opts
+for the casting vote).
+
+This trumps the fact that Steve was in the midst of drafting a
+potentially agreeable ballot all around, and had stated his
+disappointment about this out of the blue CFV since he just needed
+some more time to get that done.
+
+Wouldn't it be far more preferable to take a little more time to
+refine the text so that it can be backed by a somewhat unified TC?
+
+Best wishes,
+Mike
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 17:33:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Serge Kosyrev <skosyrev@ptsecurity.ru>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 17:33:17 GMT) (full text, mbox, link).

+ +

Message #6506 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Serge Kosyrev <skosyrev@ptsecurity.ru>
+
To: <727708@bugs.debian.org>
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Sun, 9 Feb 2014 21:14:43 +0400
+
+
On Sun, Feb 9, 2014 at 19:27, Michael Gilbert wrote:
+> > I vote UDOFV.
+>
+> So, this vote effectively gives systemd the win (assuming Bdale opts
+> for the casting vote).
+>
+> This trumps the fact that Steve was in the midst of drafting a
+> potentially agreeable ballot all around, and had stated his
+> disappointment about this out of the blue CFV since he just needed
+> some more time to get that done.
+
+Many have voiced the concern I'm going to address, but as I see your
+words, I cannot help but see the need to reiterate.
+
+There is a point of view, that Steve's role as a debian's upstart maintainer
+is in a direct conflict with the spirit of the process here.
+
+From such a viewpoint, one would rather see Steve abstain from
+_any_ participation on bug #727708.
+
+In fact, one can't help but be amazed at the level of tolerance to this
+issue from other members of the CTTE.
+
+-- 
+regards,
+Samium Gromoff
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 17:51:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 17:51:10 GMT) (full text, mbox, link).

+ +

Message #6511 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org, debian-policy@lists.debian.org, + Didier 'OdyX' Raboud <odyx@debian.org>, secretary@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Sun, 9 Feb 2014 18:47:50 +0100
+
+
On Sat, Feb 08, 2014 at 03:30:10PM -0800, Russ Allbery wrote:
+> Steve Langasek <vorlon@debian.org> writes:
+> 
+> > I question the whole notion of DPL delegation of policy powers to the
+> > policy editors.  The power to decide the contents of the debian-policy
+> > package follows from their status as package maintainers; package
+> > maintenance is not something that I believe it's in the purview of the
+> > DPL to delegate.
+> 
+> This came up in the discussion over the delegation text.  I disagree with
+> this characterization of the Policy Editor role, and I think the other
+> Policy Editors also disagree.  I don't think we are just package
+> maintainers in the normal sense.  The debian-policy package is an artifact
+> of the process and a means for documenting its results, not the only
+> purpose of the group.
+> 
+> If debian-policy were merely a package like any other, then anyone else
+> who introduced a similar package into the archive would have the same role
+> within the project as the debian-policy package maintainers.  I don't
+> think this is how the project actually looks at the matter.  The Lintian
+> maintainers, the release team, the ftp-masters, and many other teams in
+> Debian take formal notice of the acts of the Policy Editors in a way that
+> wouldn't equally apply to some other package that people introduced into
+> the archive, and would continue to do so even if the results weren't
+> published as a Debian package.
+
+Without going into the constitutionnal question, for me the essential
+role of the Policy editors is to ensure that the policy update process is
+followed, and that the policy changes reflect the consensus in Debian.
+
+On the other hand, Policy editors do not have more authority to issue
+policy proposals than any other developers except they are likely
+to be more experienced.
+
+This is different from package maintainers which has much more freedom
+when dealing with their packages.
+
+Cheers,
+Bill
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 19:18:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 19:18:09 GMT) (full text, mbox, link).

+ +

Message #6516 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: debian-ctte@lists.debian.org, + 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Sun, 9 Feb 2014 19:15:58 +0000
+
+
Bdale Garbee writes ("call for votes on default Linux init system for jessie"):
+> I have carefully considered Ian's current proposal for a process and
+> schedule to reach a next ballot on the init system issue, and do not
+> believe it is the best way for us to proceed.
+
+This unannounced CFV is an abuse of process.  I am EXTREMELY ANGRY
+and I will sponsor any GR that seeks to overturn it.
+
+I vote F, V, O, U, D.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 19:24:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 19:24:10 GMT) (full text, mbox, link).

+ +

Message #6521 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Keith Packard <keithp@keithp.com>
+
Cc: Steve Langasek <vorlon@debian.org>, + Bdale Garbee <bdale@gag.com>, + debian-ctte@lists.debian.org, + 727708@bugs.debian.org, + secretary@debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Sun, 9 Feb 2014 19:21:09 +0000
+
+
Keith Packard writes ("Re: call for votes on default Linux init system for jessie"):
+> Let's finish that vote then and move on.
+
+Once again Bdale has proposed a vote on his own motion.
+
+However, my own proposal was on the table and has not been withdrawn.
+
+Bdale chose to put forward his ballot entirely on his own without
+giving me the chance to put forward amendments, and without putting
+his ballot forward as amendments to mine.
+
+Bdale has punished me for being a good citizen.  I could have called
+for a vote on my own proposal without warning.  Or indeed allowed my
+own last vote to carry on.
+
+This grievous abuse of process, when I have myself made it very clear
+what I expected, means that I have totally lost confidence in Bdale's
+position as TC chair.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 19:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 19:36:04 GMT) (full text, mbox, link).

+ +

Message #6526 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org, + secretary@debian.org
+
Subject: Init system Call for Votes, Ian's drafts
+
Date: Sun, 9 Feb 2014 19:32:48 +0000
+
+
I hereby propose the L versions from git:
+
+  == dependencies rider version L (Loose coupling) ==
+
+     Software outside of an init system's implementation may not require
+     a specific init system to be pid 1, although degraded operation is
+     tolerable.
+
+     Maintainers are encouraged to accept technically sound patches
+     to enable improved interoperation with various init systems.
+
+as amendments to my own formal proposal, and do not accept them.
+
+I hereby call for votes on my own formal proposal.
+
+Ian.
+
+
+Options on the ballot:
+
+  DT   systemd default in jessie, requiring specific init is allowed
+  DL   systemd default in jessie, requiring specific init NOT allowed
+
+  UT   upstart default in jessie, requiring specific init is allowed
+  UL   upstart default in jessie, requiring specific init NOT allowed
+
+  OT   openrc default in jessie, requiring specific init is allowed
+  OL   openrc default in jessie, requiring specific init NOT allowed
+
+  VT   sysvinit default in jessie, requiring specific init is allowed
+  VL   sysvinit default in jessie, requiring specific init NOT allowed
+
+  GR   project should decide via GR
+
+  FD   further discussion
+
+== introduction (all versions except GR) ==
+
+   We exercise our power to decide in cases of overlapping
+   jurisdiction (6.1.2):
+
+== version D (systemD) ==
+
+   The default init system for Linux architectures in jessie should
+   be systemd.
+
+== version U (Upstart) ==
+
+   The default init system for Linux architectures in jessie should
+   be upstart.
+
+== version O (Openrc) ==
+
+   The default init system for Linux architectures in jessie should
+   be openrc.
+
+== version V (sysVinit) ==
+
+   The default init system for Linux architectures in jessie should
+   be sysvinit (no change).
+
+== version GR (General Resolution) ==
+
+   The Technical Committee requests that the project decide the
+   default init system for jessie by means of General Resolution.
+
+   (This is advice, pursuant to Constitution 6.1.5.)
+
+== clarification text for all versions except GR ==
+
+   This decision is limited to selecting a default initsystem for
+   jessie.  We expect that Debian will continue to support multiple
+   init systems for the foreseeable future; we continue to welcome
+   contributions of support for all init systems.
+
+   Therefore, for jessie and later releases, we exercise our power to
+   set technical policy (Constitution 6.1.1):
+
+== dependencies rider version T (Tight coupling) ==
+
+   Software may require a specific init system to be pid 1.
+
+   However, where feasible, software should interoperate with
+   all init systems; maintainers are encouraged to accept
+   technically sound patches to enable interoperation, even if it
+   results in degraded operation while running under the init system
+   the patch enables interoperation with.
+
+== dependencies rider version L (Loose coupling) ==
+
+   Software outside of an init system's implementation may not require
+   a specific init system to be pid 1, although degraded operation is
+   tolerable.
+
+   Maintainers are encouraged to accept technically sound patches
+   to enable improved interoperation with various init systems.
+
+== rider for all versions except GR ==
+
+   If the project passes (before the release of jessie) by a General
+   Resolution, a "position statement about issues of the day", on the
+   subject of init systems, the views expressed in that position
+   statement entirely replace the substance of this TC resolution; the
+   TC hereby adopts any such position statement as its own decision.
+
+   Such a position statement could, for example, use these words:
+
+      The Project requests (as a position statement under s4.1.5 of the
+      Constitution) that the TC reconsider, and requests that the TC
+      would instead decide as follows:
+
+-- 
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 19:39:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 19:39:11 GMT) (full text, mbox, link).

+ +

Message #6531 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org, + secretary@debian.org
+
Subject: Re: Init system Call for Votes, Ian's drafts
+
Date: Sun, 9 Feb 2014 19:36:42 +0000
+
+
Ian Jackson writes ("Init system Call for Votes, Ian's drafts"):
+> I hereby propose the L versions from git:
+> 
+>   == dependencies rider version L (Loose coupling) ==
+> 
+>      Software outside of an init system's implementation may not require
+>      a specific init system to be pid 1, although degraded operation is
+>      tolerable.
+> 
+>      Maintainers are encouraged to accept technically sound patches
+>      to enable improved interoperation with various init systems.
+> 
+> as amendments to my own formal proposal, and do not accept them.
+> 
+> I hereby call for votes on my own formal proposal.
+
+I vote
+
+1.  UL   upstart default in jessie, requiring specific init NOT allowed
+2.  DL   systemd default in jessie, requiring specific init NOT allowed
+3.  OL   openrc default in jessie, requiring specific init NOT allowed
+4.  VL   sysvinit default in jessie, requiring specific init NOT allowed
+5.  GR   project should decide via GR
+6.  FD   further discussion
+7.  UT   upstart default in jessie, requiring specific init is allowed
+8.  OT   openrc default in jessie, requiring specific init is allowed
+9.  VT   sysvinit default in jessie, requiring specific init is allowed
+10. DT   systemd default in jessie, requiring specific init is allowed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 19:51:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to svante.signell@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 19:51:08 GMT) (full text, mbox, link).

+ +

Message #6536 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Svante Signell <svante.signell@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Why open voting?
+
Date: Sun, 09 Feb 2014 20:47:33 +0100
+
+
Hi,
+
+Following this bug report for several months now this is really becoming
+a farce. Who is in charge calling for votes, and why don't you have a
+closed voting procedure?
+
+Of course the people voting later has a advantage against the others.
+Have you ever heard of game theory? This is like scheduling four quarter
+finals in e.g. football championship -after_ each other, not concurrent.
+Things like this happens, but is very seldom in high quality
+sports/events :-(  
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 19:51:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 19:51:11 GMT) (full text, mbox, link).

+ +

Message #6541 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Init system coupling call for votes
+
Date: Sun, 9 Feb 2014 19:48:40 +0000
+
+
I hereby call for votes on the following resolution:
+
+   The init system decision is limited to selecting a default
+   initsystem for jessie.  We expect that Debian will continue to
+   support multiple init systems for the foreseeable future; we
+   continue to welcome contributions of support for all init systems.
+
+   Therefore, for jessie and later releases, we exercise our power to
+   set technical policy (Constitution 6.1.1):
+
+   Software outside of an init system's implementation may not require
+   a specific init system to be pid 1, although degraded operation is
+   tolerable.
+
+   Maintainers are encouraged to accept technically sound patches
+   to enable improved interoperation with various init systems.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 19:51:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 19:51:14 GMT) (full text, mbox, link).

+ +

Message #6546 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Init system coupling call for votes
+
Date: Sun, 9 Feb 2014 19:50:01 +0000
+
+
Ian Jackson writes ("Init system coupling call for votes"):
+> I hereby call for votes on the following resolution:
+> 
+>    The init system decision is limited to selecting a default
+>    initsystem for jessie.  We expect that Debian will continue to
+>    support multiple init systems for the foreseeable future; we
+>    continue to welcome contributions of support for all init systems.
+> 
+>    Therefore, for jessie and later releases, we exercise our power to
+>    set technical policy (Constitution 6.1.1):
+> 
+>    Software outside of an init system's implementation may not require
+>    a specific init system to be pid 1, although degraded operation is
+>    tolerable.
+> 
+>    Maintainers are encouraged to accept technically sound patches
+>    to enable improved interoperation with various init systems.
+
+I vote
+
+  1. requiring specific init NOT allowed
+  2. FD
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 19:51:38 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to James Rhodes <jrhodes@redpointsoftware.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 19:51:38 GMT) (full text, mbox, link).

+ +

Message #6551 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: James Rhodes <jrhodes@redpointsoftware.com.au>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: secretary@debian.org, Keith Packard <keithp@keithp.com>, Bdale Garbee <bdale@gag.com>, + Steve Langasek <vorlon@debian.org>, debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Mon, 10 Feb 2014 06:50:42 +1100
+
+
[Message part 1 (text/plain, inline)]
+
On 10/02/2014 6:21 AM, "Ian Jackson" <ijackson@chiark.greenend.org.uk>
+wrote:
+>
+> Keith Packard writes ("Re: call for votes on default Linux init system
+for jessie"):
+> > Let's finish that vote then and move on.
+>
+> Once again Bdale has proposed a vote on his own motion.
+>
+> However, my own proposal was on the table and has not been withdrawn.
+>
+> Bdale chose to put forward his ballot entirely on his own without
+> giving me the chance to put forward amendments, and without putting
+> his ballot forward as amendments to mine.
+>
+> Bdale has punished me for being a good citizen.  I could have called
+> for a vote on my own proposal without warning.  Or indeed allowed my
+> own last vote to carry on.
+
+Just a heads up; you clearly stated in your original timeline email:
+
+> If anyone jumps the gun on this schedule by calling for votes early
+> and without gettign consensus the list, I think TC members who agree
+> with my proposed schedule should rank FD first.
+
+> If you think this schedule is wrong you will need to convince your
+> fellow TC members to (a) vote FD on the 3rd CFV, to postpone again; or
+> (b) refrain from voting FD on an earlier CFV.
+
+You have stated that people can hold other and earlier votes; and given
+that people are not voting FD first, that clearly indicates that they think
+Bdale's proposal is acceptable in it's current form and does not require
+amendments.  You are free to vote FD if you feel otherwise.
+
+Regards, James.
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 19:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 19:57:04 GMT) (full text, mbox, link).

+ +

Message #6556 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Init system GR override call for votes
+
Date: Sun, 9 Feb 2014 19:55:48 +0000
+
+
I hereby call for votes on the following resolution
+
+   If the project passes (before the release of jessie) by a General
+   Resolution, a "position statement about issues of the day", on the
+   subject of init systems, the views expressed in that position
+   statement entirely replace the substance of any TC resolution (past
+   or future) on the same topic; the TC hereby adopts any such
+   position statement as its own decision.
+
+   Such a position statement could, for example, use these words:
+
+      The Project requests (as a position statement under s4.1.5 of the
+      Constitution) that the TC reconsider, and requests that the TC
+      would instead decide as follows:
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 19:57:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 19:57:07 GMT) (full text, mbox, link).

+ +

Message #6561 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Init system GR override call for votes
+
Date: Sun, 9 Feb 2014 19:56:17 +0000
+
+
Ian Jackson writes ("Init system GR override call for votes"):
+> I hereby call for votes on the following resolution
+> 
+>    If the project passes (before the release of jessie) by a General
+>    Resolution, a "position statement about issues of the day", on the
+>    subject of init systems, the views expressed in that position
+>    statement entirely replace the substance of any TC resolution (past
+>    or future) on the same topic; the TC hereby adopts any such
+>    position statement as its own decision.
+> 
+>    Such a position statement could, for example, use these words:
+> 
+>       The Project requests (as a position statement under s4.1.5 of the
+>       Constitution) that the TC reconsider, and requests that the TC
+>       would instead decide as follows:
+
+I vote
+  1.  GR can psuedo-override TC with 1:1
+  2.  FD
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 20:03:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 20:03:14 GMT) (full text, mbox, link).

+ +

Message #6566 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Why open voting?
+
Date: Sun, 09 Feb 2014 11:59:02 -0800
+
+
Svante Signell <svante.signell@gmail.com> writes:
+
+> Following this bug report for several months now this is really becoming
+> a farce. Who is in charge calling for votes,
+
+The Debian constitution is quite clear about this: any member can propose
+a vote and call for votes immediately or with a discussion period at their
+discretion.
+
+> and why don't you have a closed voting procedure?
+
+I think Anthony Towns's messages are a very clear demonstration of the
+benefits of public voting.  Would you have preferred that Condorcet
+analysis only happen in private?
+
+> Of course the people voting later has a advantage against the others.
+
+I don't believe this holds when changing one's vote later is permitted.
+There are some edge case possibilities around the voting period deadline
+or about the triggering condition for "the vote is no longer in question"
+(depending on how that is interpreted), but so far none of those have
+triggered, and it's fairly obvious among a small group of people if that
+happens.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 20:21:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 20:21:09 GMT) (full text, mbox, link).

+ +

Message #6571 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system GR override call for votes
+
Date: Sun, 09 Feb 2014 13:18:14 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I hereby call for votes on the following resolution
+
+Equivalent language reviewed by our project secretary was included in my
+resolution.  Is there some particular value you see in running this as a
+separate resolution? 
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 20:33:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Friedrich Gunter <friedrich.gunter@aim.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 20:33:15 GMT) (full text, mbox, link).

+ +

Message #6576 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Friedrich Gunter <friedrich.gunter@aim.com>
+
To: 727708@bugs.debian.org
+
Subject: Removal of Ian Jackson from TC
+
Date: Sun, 9 Feb 2014 15:23:07 -0500 (EST)
+
+
Hello TC,
+
+I hereby request that you begin the procedure for removing Ian Jackson 
+from his position in the TC. He has consistently derailed debates, 
+engaged in dishonest tactical voting methods, and tarnished the good 
+reputation of the TC. He is a nuisance to the Debian project and a 
+dishonest man to entrust with such responsibility.
+
+I would further suggest that any similar calls to remove Bdale from his 
+post be ignored, as Bdale has been doing an excellent and honest job.
+
+
+Thank you for your consideration.
+
+Friedrich Gunter
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 20:45:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Serge Kosyrev <skosyrev@ptsecurity.ru>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 20:45:15 GMT) (full text, mbox, link).

+ +

Message #6581 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Serge Kosyrev <skosyrev@ptsecurity.ru>
+
To: <727708@bugs.debian.org>
+
Cc: Ondřej Surý <ondrej@sury.org>
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Mon, 10 Feb 2014 00:41:38 +0400
+
+
Serge Kosyrev <skosyrev@ptsecurity.ru> writes:
+> On Sun, Feb 9, 2014 at 19:27, Michael Gilbert wrote:
+> > > I vote UDOFV.
+> >
+> > So, this vote effectively gives systemd the win (assuming Bdale opts
+> > for the casting vote).
+> >
+> > This trumps the fact that Steve was in the midst of drafting a
+> > potentially agreeable ballot all around, and had stated his
+> > disappointment about this out of the blue CFV since he just needed
+> > some more time to get that done.
+> 
+> Many have voiced the concern I'm going to address, but as I see your
+> words, I cannot help but see the need to reiterate.
+> 
+> There is a point of view, that Steve's role as a debian's upstart maintainer
+> is in a direct conflict with the spirit of the process here.
+> 
+> From such a viewpoint, one would rather see Steve abstain from
+> _any_ participation on bug #727708.
+>
+> In fact, one can't help but be amazed at the level of tolerance to this
+> issue from other members of the CTTE.
+
+Ondřej Surý <ondrej@sury.org> writes:
+> This has been repeated many times
+
+I have said so, indeed -- as well as stated a reason for reiteration.
+
+> and refused
+
+False.  Three messages on this list brought this conflict of interest
+into light:
+
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2810 by Anthony Towns
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#5912 by Friedrich Gunther
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6206 by Dmitry Smirnov
+
+There was no answer.
+
+> and I would really prefer that you would stop
+> reiterating this again and again. It's really annoyning and it feels like you are not listening
+> anf just blindly repeating your position. Please stop, you are not helping neither Debian nor
+> the process.
+
+Such is your unexplained (and ill-substantiated) preference.
+
+-- 
+regards,
+Samium Gromoff
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 20:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 20:51:05 GMT) (full text, mbox, link).

+ +

Message #6586 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system Call for Votes, Ian's drafts
+
Date: Sun, 9 Feb 2014 12:49:32 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sun, Feb 09, 2014 at 07:32:48PM +0000, Ian Jackson wrote:
+> I hereby call for votes on my own formal proposal.
+
+> Options on the ballot:
+> 
+>   DT   systemd default in jessie, requiring specific init is allowed
+>   DL   systemd default in jessie, requiring specific init NOT allowed
+> 
+>   UT   upstart default in jessie, requiring specific init is allowed
+>   UL   upstart default in jessie, requiring specific init NOT allowed
+> 
+>   OT   openrc default in jessie, requiring specific init is allowed
+>   OL   openrc default in jessie, requiring specific init NOT allowed
+> 
+>   VT   sysvinit default in jessie, requiring specific init is allowed
+>   VL   sysvinit default in jessie, requiring specific init NOT allowed
+> 
+>   GR   project should decide via GR
+> 
+>   FD   further discussion
+
+On Sun, Feb 09, 2014 at 07:48:40PM +0000, Ian Jackson wrote:
+> I hereby call for votes on the following resolution:
+
+>    The init system decision is limited to selecting a default
+>    initsystem for jessie.  We expect that Debian will continue to
+>    support multiple init systems for the foreseeable future; we
+>    continue to welcome contributions of support for all init systems.
+
+>    Therefore, for jessie and later releases, we exercise our power to
+>    set technical policy (Constitution 6.1.1):
+
+>    Software outside of an init system's implementation may not require
+>    a specific init system to be pid 1, although degraded operation is
+>    tolerable.
+
+>    Maintainers are encouraged to accept technically sound patches
+>    to enable improved interoperation with various init systems.
+
+On Sun, Feb 09, 2014 at 07:55:48PM +0000, Ian Jackson wrote:
+> I hereby call for votes on the following resolution
+> 
+>    If the project passes (before the release of jessie) by a General
+>    Resolution, a "position statement about issues of the day", on the
+>    subject of init systems, the views expressed in that position
+>    statement entirely replace the substance of any TC resolution (past
+>    or future) on the same topic; the TC hereby adopts any such
+>    position statement as its own decision.
+> 
+>    Such a position statement could, for example, use these words:
+> 
+>       The Project requests (as a position statement under s4.1.5 of the
+>       Constitution) that the TC reconsider, and requests that the TC
+>       would instead decide as follows:
+
+In the interest of avoiding any procedural accidents given that there's been
+a formal CFV on each of these resolutions:  I vote 'FD' on each, leaving all
+other options unranked (i.e., below 'FD').
+
+As I've already said, I share Ian's concern that Bdale's call for votes was
+disrespectful, depriving his fellow committee members of the right to
+participate in the drafting process, which is just as much an exploit of the
+voting system as tactical voting is.  But this barrage of CFVs only
+compounds the problem.
+
+I do support the idea of fixing the constitution to require a minimum
+discussion period on ballots for TC resolutions.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 20:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 20:54:04 GMT) (full text, mbox, link).

+ +

Message #6591 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Friedrich Gunter <friedrich.gunter@aim.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Removal of Ian Jackson from TC
+
Date: Sun, 09 Feb 2014 12:51:10 -0800
+
+
Friedrich Gunter <friedrich.gunter@aim.com> writes:
+
+> Hello TC,
+
+> I hereby request that you begin the procedure for removing Ian Jackson
+> from his position in the TC. He has consistently derailed debates, engaged
+> in dishonest tactical voting methods, and tarnished the good reputation of
+> the TC. He is a nuisance to the Debian project and a dishonest man to
+> entrust with such responsibility.
+
+> I would further suggest that any similar calls to remove Bdale from his
+> post be ignored, as Bdale has been doing an excellent and honest job.
+
+Look, please, everyone just stop and breathe.
+
+No one is going to kick anyone off of the TC today.  Not while passions
+are running high, and not while we're dealing with the fallout from a hard
+and extremely controversial vote.  It's not even something we should be
+discussing right now.
+
+We're in unprecedented procedural territory here in multiple ways.  We do
+not normally call for immediate votes, and we do not normally do so to
+prevent amendments.  This is the first time I can recall that we had an
+unresolvable dispute over how to construct a ballot.  Given that Ian had
+said that he intended to propose amendments for any minimal ballot, I
+don't see that Bdale had any possible procedural method to advocate a
+minimal ballot that would be effective apart from an immediate vote and
+ask that it be voted down with FD if the rest of the group disagrees.  But
+it's still necessarily very confrontational.  It's entirely understandable
+that Ian is angry.  Please give him some space to be angry.  I think we've
+all been there before.
+
+Ian has been passionately arguing what he considers to be both an ethical
+and design requirement for loose coupling and independently replacable
+components.  I understand that a lot of other people disagree with his
+perspective here, but it's a valid and consistent perspective.  This is a
+point about which people can reasonably disagree.  Ian's job on this
+committee, like all of us, is to argue his perspective and to try to
+convince other people of his position.
+
+It's very hard to have deep disagreements with professional colleagues
+about what you consider to be foundational and ethical decisions.  It can
+be both baffling and then very frustrating and infuriating when what you
+feel like are overwhelming arguments in favor of your position aren't
+considered important by other people.  This stuff is hard in every way:
+socially, emotionally, and procedurally.
+
+Please give people the space to be angry, disappointed, frustrated, and in
+total disagreement with both process and outcome.  We have a process, and
+we're following it as best as we all collectively can given a lot of
+deeply conflicting goals and opinions.  One of the points of a process is
+to force some distance and emotional separation.  It does not help
+*anyone* to push for further confrontation right now.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 21:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 21:00:04 GMT) (full text, mbox, link).

+ +

Message #6596 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Serge Kosyrev <skosyrev@ptsecurity.ru>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Sun, 9 Feb 2014 12:57:26 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Mon, Feb 10, 2014 at 12:41:38AM +0400, Serge Kosyrev wrote:
+> Serge Kosyrev <skosyrev@ptsecurity.ru> writes:
+> > On Sun, Feb 9, 2014 at 19:27, Michael Gilbert wrote:
+> > > > I vote UDOFV.
+
+> > > So, this vote effectively gives systemd the win (assuming Bdale opts
+> > > for the casting vote).
+
+> > > This trumps the fact that Steve was in the midst of drafting a
+> > > potentially agreeable ballot all around, and had stated his
+> > > disappointment about this out of the blue CFV since he just needed
+> > > some more time to get that done.
+
+> > Many have voiced the concern I'm going to address, but as I see your
+> > words, I cannot help but see the need to reiterate.
+
+> > There is a point of view, that Steve's role as a debian's upstart maintainer
+> > is in a direct conflict with the spirit of the process here.
+
+> > From such a viewpoint, one would rather see Steve abstain from
+> > _any_ participation on bug #727708.
+
+> > In fact, one can't help but be amazed at the level of tolerance to this
+> > issue from other members of the CTTE.
+
+> Ondřej Surý <ondrej@sury.org> writes:
+> > This has been repeated many times
+
+> I have said so, indeed -- as well as stated a reason for reiteration.
+
+Whether my conflict of interest in this decision constitutes a problem is a
+question for the Debian project to decide, not you.  I have been convinced,
+as a result of conversations with my fellow TC members early in this
+process, that there was no need for me to recuse myself from the discussion. 
+If the Debian Developers feel that my conflict of interest has resulted in a
+wrong decision being taken, they have the authority to override the TC with
+a GR.
+
+But until then, kindly stop distracting the committee from its rightful
+business.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 21:06:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 21:06:07 GMT) (full text, mbox, link).

+ +

Message #6601 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Didier 'OdyX' Raboud <odyx@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Sun, 9 Feb 2014 13:02:21 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Sun, Feb 09, 2014 at 02:07:56PM +0100, Didier 'OdyX' Raboud wrote:
+> Le vendredi, 7 février 2014, 14.27:25 Steve Langasek a écrit :
+> > (…), what I've seen suggests that systemd integration is currently in
+> > a state that would cause terrible regressions for many server users.
+
+> Le samedi, 8 février 2014, 14.18:39 Steve Langasek a écrit :
+> > I vote F U D (…)
+
+> Quite frankly, I don't have much more to add.
+
+> Could you please either refrain from blanket statements about the 
+> brokenness of systemd or back them with bugreports?
+
+I am no more bound by such a request to stop speaking the truth, than systemd
+proponents are bound by requests that they stop spreading FUD about the
+viability of logind on non-systemd-init systems.  The evidence of the broken
+integration has been posted to this bug; anyone who cares about making
+systemd robust for jessie is free to act on that information by filing bug
+reports against systemd, or by fixing the problems outlined.  It's not my
+responsibility to personally spoon-feed people fixes for systemd's lack of
+integration - and particularly given that the poor state of integration is
+the major reason why I still believe systemd is a worse choice of default
+for Debian than upstart, I certainly have no intention of being silent about
+this subject.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 09 Feb 2014 23:09:24 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 09 Feb 2014 23:09:24 GMT) (full text, mbox, link).

+ +

Message #6606 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: Serge Kosyrev <skosyrev@ptsecurity.ru>, 727708@bugs.debian.org
+
Cc: Ondřej Surý <ondrej@sury.org>
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Mon, 10 Feb 2014 09:06:12 +1000
+
+
On 10 February 2014 06:41, Serge Kosyrev <skosyrev@ptsecurity.ru> wrote:
+> False.  Three messages on this list brought this conflict of interest
+> into light:
+> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2810 by Anthony Towns
+> [...]
+> There was no answer.
+
+So, fwiw, I thought the above was kind of mean on my behalf. Not
+/wrong/ per se, just mean.
+
+I haven't been able to think of a *good* "answer" for this concern,
+even in an arbitrary ideal world where the constraints are different.
+
+For instance, Steve could recuse himself from the discussion entirely
+-- that's what you'd expect in many cases where there are commercial
+conflicts of interest, eg. But that would be ridiculous here, because
+both his technical knowledge as upstart maintainer is nigh-on
+essential to the discussion, and his input as to how things have
+worked in Canonical is pretty useful too.
+
+He could recuse himself from voting, or perhaps the committee chair or
+committee as a whole could ask him to do so -- but at least at this
+point, that would be effectively equivalent to Steve directly voting
+systemd above upstart, and that would be a fairly unreasonable forced
+reversal of preferences for Steve to make, or it would involve a
+conflict of interest on behalf of the chair (who's indicated a
+preference for systemd), or the rest of the committee (which has
+indicated a 4:3 preference for systemd). Maybe one of these things
+would have been good to do earlier, before positions had coalesced,
+but I don't think they're reasonable things to do or expect now. (They
+might have been when I sent the mail, but if so, they only remained
+plausible for a pretty short window in my opinion; further, Steve
+mentions that the committee discussed this earlier and came to the
+conclusion that no action was needed)
+
+If the committee had the flexibility to do so, maybe a reasonable
+thing would have been to replace Steve for this vote with a less
+interested party early in the discussions; eg by letting Phil Kern
+step in to provide the 8th vote for this issue, so that Steve could
+simply act as an advocate and technical advisor to the committee on
+this issue. Alternatively, perhaps a reasonable thing might have been
+to give the primary systemd, sysvinit and upstart maintainers the
+ability to vote on this issue too. Neither were options open to the
+committee though.
+
+As it stands, though, Steve has to: consider the implications for
+Debian, consider the implications for upstart (as maintainer),
+consider the implications for Canonical and Ubuntu (as a Canonical
+employee and Ubuntu dev), mostly dismiss the implications for
+Canonical/Ubuntu (in order to prioritise the implications for Debian
+as a ctte member making a ctte decision), and deal with accusations of
+having a conflict of interest, despite not being able to do anything
+concrete to address them. Oh, and I gather Steve's trying to run a
+debconf in six months time or so too, which I understand could add
+some degree of stress on its own...
+
+So yeah, I stand by my description of that as "fairly challenging",
+and I'm really glad it's not me in that position.
+
+Cheers,
+aj
+
+-- 
+Anthony Towns <aj@erisian.com.au>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 10:09:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Didier 'OdyX' Raboud" <odyx@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 10:09:08 GMT) (full text, mbox, link).

+ +

Message #6611 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Didier 'OdyX' Raboud" <odyx@debian.org>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Mon, 10 Feb 2014 11:07 +0100
+
+
Le dimanche, 9 février 2014, 13.02:21 Steve Langasek a écrit :
+> On Sun, Feb 09, 2014 at 02:07:56PM +0100, Didier 'OdyX' Raboud wrote:
+> > Le vendredi, 7 février 2014, 14.27:25 Steve Langasek a écrit :
+> > > (…), what I've seen suggests that systemd integration is currently
+> > > in a state that would cause terrible regressions for many server
+> > > users.
+> > (…)
+> > 
+> > Could you please either refrain from blanket statements about the
+> > brokenness of systemd or back them with bugreports?
+
+Someone kindly pointed to me in private that I went off-bounds with this 
+attack on Steve. I agree and therefore apologize: it was unneededly 
+personal and wasn't helping the discussion, sorry for that.
+
+Cheers,
+OdyX
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 11:42:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Craig Bransworth <craigbransworth@aim.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 11:42:13 GMT) (full text, mbox, link).

+ +

Message #6616 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Craig Bransworth <craigbransworth@aim.com>
+
To: 727708@bugs.debian.org
+
Cc: debian-devel@lists.debian.org
+
Subject: Fsck SystemD and its developers and its users. GR to override this please.
+
Date: Mon, 10 Feb 2014 06:37:53 -0500 (EST)
+
+
[Message part 1 (text/plain, inline)]
+
Please a GR to override this bullshit.
+
+There are 100 people who have chosen to use systemd. Yet they override everyone else because they are in the right position.
+
+
+Fuck systemd from the bottom of my heart.
+Fuck it.
+Fuck it.
+
+FUCK SYSTEMD.
+
+I do not want to learn systemd.
+I do not want to deal with systemd.
+I hate the way it does things.
+I hate the way their community works.
+
+I hate that it does so much.
+I hate that it changes the system.
+I hate what it is: system Daemon.
+
+I want an init that does few things.
+An init that doesn't crash (not systemd!)
+An init that doesn't care that I have encrypted hdd, and _never_ did care.
+An init that's small and doesn't contain
+security errors (the larger the code the more there are,
+and nope C is not run directly on the iron, so whatever
+you think you're coding, guess again because you don't
+have as much control as you think once the real code
+is running on the machine)
+
+SystemD isn't it.
+I hate the attitude of it's fuck faced devs and fans.
+It's either them or us.
+They make that clear.
+
+Fuck them, Fuck their system. Fuck SystemD
+Fuck SystemD.
+
+We are "obsolete" and must obey their way.
+Our beliefs are superceded, says them.
+Fuck Systemd.
+
+Viva unix (please!).
+Fuck Systemd.
+
+
+http://images2.fanpop.com/image/polls/322000/322597_1257333380756_full.jpg
+Looking up to you unix of old and of now.
+Love you unix of old.
+You are rough but resolute.
+
+Not a new wonder kid BITCH, that thinks WE are it's bitch.
+FUCK SYSTEMD.
+
+
+>Systemd fanboys try to keep steve from voting
+
+Yea, and others in or around the tech-ctte are completly different.
+You know, being systemd fanboys that just want to foist a completely
+new order on us for what seems like religious reasons,
+rather than a possibly slightly monetary reasons.
+
+So _COMPLETELY_ different!
+
+So yea, No steve lan, and shove systemd straight down our
+throats, down our gullet, through our stomach, have it
+crash through our guts below, and then castrate us 
+while it powerbombs through our balls at the antepodal region
+from where it entered into the ground (perhaps crashing
+through a few floors below us and doing the same to
+some other poor sods).
+
+In the end there will be nothing but systemd.
+To make this possible steve lan needs to be moved out
+of the way for a clean victory for the new way(TM!).
+
+All Hail Lennart!
+(Lennart IS a german from Brazil, and it IS 
+his way or NO way, so it fits).
+
+
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 11:54:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to craigbr@hushmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 11:54:04 GMT) (full text, mbox, link).

+ +

Message #6621 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: craigbr@hushmail.com
+
To: 727708@bugs.debian.org, ijackson@chiark.greenend.org.uk
+
Cc: debian-devel@lists.debian.org, tg@mirbsd.de, markoran@eunet.rs
+
Subject: A general resolution is needed. The 100 systemd users shouldn't be able to take over debian linux. They're in the right place, but their decision to foist this on us should be overruled.
+
Date: Mon, 10 Feb 2014 06:50:40 -0500
+
+
[Message part 1 (text/plain, inline)]
+
A general resolution is needed. The 100 systemd users shouldn't be
+able to take over debian linux. They're in the right place at the
+right time
+(they always seem to be), but their decision to foist this on us
+should be overruled.
+
+The systemd developers and supporters seek to enforce their vision of
+what linux is to be on all of us. They are winning in that fight.
+Not because we all want them to, but because they know how to play the
+game. They zero in on key positions of authority
+and that is whom they either convince or aquire access into.
+
+Few people use system d in debian. Yet we must all use it by default
+for the next release.
+A system alien to any unix principals. A system that is not anything
+like what we knew.
+
+A system that has an asshole for a main dev that has no regards for
+anyone else's opinion or wishes.
+
+Fk systemd.
+
+I don't want systemd, wayland, gnome3, etc. I do want debian, but the
+new people are on a crusade.
+They can't let me have what I allready have, I have to switch to their
+"stack" (whatever the hell that means) in the future or eat their
+dust.
+
+They intentionally remove support for "enemy" ways of running a
+system. Fk them.
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 12:18:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Olav Vitters <ovitters@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 12:18:17 GMT) (full text, mbox, link).

+ +

Message #6626 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Olav Vitters <ovitters@gmail.com>
+
To: Craig Bransworth <craigbransworth@aim.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Fsck SystemD and its developers and its users. GR to + override this please.
+
Date: Mon, 10 Feb 2014 13:03:57 +0100
+
+
On Mon, Feb 10, 2014 at 12:37 PM, Craig Bransworth
+<craigbransworth@aim.com> wrote:
+> In the end there will be nothing but systemd.
+> To make this possible steve lan needs to be moved out
+> of the way for a clean victory for the new way(TM!).
+
+I'm one of the vocal and outspoken systemd advocates. Your assertion
+that "Ian needs to be moved out" is completely baseless and
+ridiculous. There are 4 people for consistently vote for systemd, 4
+who do this for Upstart. Before you wrote your message loads of people
+have pointed out that this call for Ian to be removed is inappropriate
+(see LWN, Phoronix, Google+).
+
+> All Hail Lennart!
+
+References to religion and second world war? Really? You expect people
+to listen to such bullshit?
+
+Fairly easy to assign everything to conspiracy and say systemd
+advocates are handling in bad faith. Now read LWN and Phoronix
+comments. Public proof you're totally off.
+
+Note that various ctte members have stated multiple times that
+messages such as yours are inappropriate, don't add any value (ranting
+is not very useful!) and too late. This makes it quite clear you
+didn't investigate.
+
+Regards,
+Olav
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 12:18:20 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Olav Vitters <ovitters@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 12:18:20 GMT) (full text, mbox, link).

+ +

Message #6631 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Olav Vitters <ovitters@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Fsck SystemD and its developers and its users. GR to + override this please.
+
Date: Mon, 10 Feb 2014 13:05:38 +0100
+
+
oops.. that was supposed to be a private message, sorry for the noise.
+Please remove this one and my previous one.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 12:18:23 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Joerg Jaspert <joerg@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 12:18:23 GMT) (full text, mbox, link).

+ +

Message #6636 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Joerg Jaspert <joerg@debian.org>
+
To: <owner@bugs.debian.org>
+
Cc: <727708@bugs.debian.org>
+
Subject: #727708
+
Date: Mon, 10 Feb 2014 13:00:20 +0100
+
+
Hi
+
+please consider ENTIRELY disallowing any mail to that bug, except for 
+the few
+CTTE members, no exceptions.
+Nothing there currently is of any help, nor providing any new 
+information.
+Should the CTTE want someone external to add, either you can manually 
+allow them
+- there shouldn't really be many to come - or they can just forward the 
+few
+pieces of useful information they still may need.
+
+If you don't want to do the manual work of adding new people on CTTE 
+request,
+(something I can understand entirely) I volunteer to do exactly that 
+work for
+the time until the issue is resolved, just enable me to do so.
+
+If you need this mail signed, I can only provide that this evening, 
+until which I'm
+sure there would be another three or four dozen waste mails around, so 
+if you could
+act earlier, that would be nice.
+
+-- 
+bye Joerg
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 12:24:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to craigbr@hushmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 12:24:10 GMT) (full text, mbox, link).

+ +

Message #6641 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: craigbr@hushmail.com
+
To: 727708@bugs.debian.org
+
Cc: debian-devel@lists.debian.org
+
Subject: Fsk SystemD and its developers and its users. GR to override this please.
+
Date: Mon, 10 Feb 2014 06:42:42 -0500
+
+
[Message part 1 (text/plain, inline)]
+
Please a GR to override this bullshit.
+
+There are 100 people who have chosen to use systemd. Yet they override
+everyone else because they are in the right position.
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 12:24:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 12:24:17 GMT) (full text, mbox, link).

+ +

Message #6646 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: 727708@bugs.debian.org
+
Cc: Craig Bransworth <craigbransworth@aim.com>
+
Subject: Re: Bug#727708: Fsck SystemD and its developers and its users. GR + to override this please.
+
Date: Mon, 10 Feb 2014 12:22:03 +0000 (UTC)
+
+
Olav Vitters dixit:
+
+>References to religion and second world war? Really? You expect people
+>to listen to such bullshit?
+
+Also, as a German, I’m affronted by Craig’s comment. After all,
+Hitler was Austrian, not even German.
+
+>Fairly easy to assign everything to conspiracy and say systemd
+>advocates are handling in bad faith. Now read LWN and Phoronix
+>comments. Public proof you're totally off.
+
+Actually, there’s more proof that systemd is not all roses, too.
+By dalias of musl fame, no less: http://ewontfix.com/14/
+
+bye,
+//mirabilos
+-- 
+13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good
+guy. But he's always right! In every fsckin' situation, he's right. Even
+with his deeply perverted taste in software and borked ambition towards
+broken OSes - in the end, he's damn right about it :(! […] works in mksh
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 12:33:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Matthias Klumpp <matthias@tenstral.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 12:33:08 GMT) (full text, mbox, link).

+ +

Message #6651 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Matthias Klumpp <matthias@tenstral.net>
+
To: Joerg Jaspert <joerg@debian.org>
+
Cc: owner@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: #727708
+
Date: Mon, 10 Feb 2014 13:31:45 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Am 10.02.2014 13:18 schrieb "Joerg Jaspert" <joerg@debian.org>:
+>
+> Hi
+>
+> please consider ENTIRELY disallowing any mail to that bug, except for the
+few
+> CTTE members, no exceptions.
+> Nothing there currently is of any help, nor providing any new information.
+I second that, at least for some time doing that will be a good thing.
+Cheers,
+   Matthias
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 12:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Dimitri John Ledkov <xnox@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 12:48:04 GMT) (full text, mbox, link).

+ +

Message #6656 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Dimitri John Ledkov <xnox@debian.org>
+
To: Craig Bransworth <craigbransworth@aim.com>, 727708@bugs.debian.org
+
Cc: "debian-devel@lists.debian.org" <debian-devel@lists.debian.org>
+
Subject: Re: Bug#727708: Fsck SystemD and its developers and its users. GR to + override this please.
+
Date: Mon, 10 Feb 2014 12:44:38 +0000
+
+
On 10 February 2014 11:37, Craig Bransworth <craigbransworth@aim.com> wrote:
+> Please a GR to override this ...
+>
+
+The Debian Project welcomes and encourages participation by everyone.
+
+No matter how you identify yourself or how others perceive you: we
+welcome you. We welcome contributions from everyone as long as they
+interact constructively with our community.
+
+However, the message you have posted is extremely offensive and thus
+cannot be considered as constructive interaction with us.
+
+Please refrain from using such language when interacting with us. If
+you can't refrain yourself, please stop interacting with us.
+
+-- 
+Regards,
+
+Dimitri.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 13:39:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Dmitry E. Oboukhov" <unera@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 13:39:07 GMT) (full text, mbox, link).

+ +

Message #6661 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Dmitry E. Oboukhov" <unera@debian.org>
+
To: debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Mon, 10 Feb 2014 17:08:21 +0400
+
+
[Message part 1 (text/plain, inline)]
+
+I vote: V U O
+
+:)
+
+-- 
+
+. ''`.                               Dmitry E. Oboukhov
+: :’  :   email: unera@debian.org jabber://UNera@uvw.ru
+`. `~’              GPGKey: 1024D / F8E26537 2006-11-21
+  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 16:21:33 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to crgibrw@hushmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 16:21:33 GMT) (full text, mbox, link).

+ +

Message #6666 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: crgibrw@hushmail.com
+
To: 727708@bugs.debian.org
+
Cc: debian-devel@lists.debian.org
+
Subject: Great article against systemd (note: you'll be banned if you respond to this mail, like my other acct was).
+
Date: Mon, 10 Feb 2014 10:44:11 -0500
+
+
That was a great article against systemd (note: you'll be banned if you respond to this mail, like my other acct was):
+(ewontfix.com/14/). Thanks for posting it.
+
+Note: do not respond to this email, you'll probably be banned. SystemD fanbois are rooted deep in every linux distro.
+They get their enemies banned. My other acct was banned for opposing their bullsht. For 4 weeks (who cares).
+
+
+
+"The crowd pushing systemd, possibly including its author, is notcontent to have systemd be one choice among many. By providing publicAPIs intended to be used by other applications, systemd has set itselfup to be difficult not to use once it achieves a certain adoptionthreshold."
+
+"None of the things systemd "does right" are at all revolutionary.They've been done many times before. DJB'sdaemontools,runit, andSupervisor, among others, have solved the"legacy init is broken" problem over and over again (though each withsome of their own flaws). Their failure to displace legacy sysvinit inmajor distributions had nothing to do with whether they solved theproblem, and everything to do with marketing. Said differently,there's nothing great and revolutionary about systemd. Its popularityis purely the result of an aggressive, dictatorial marketing strategyincluding elements such as:Engulfing other "essential" system components like udev and makingthem difficult or impossible to use without systemd (but seeeudev).Setting up for API lock-in (having the DBus interfaces provided bysystemd become a necessary API that user-level programs depend on).Dictating policy rather than being scoped such that the user,administrator, or systems integrator (distribution) has to 
+ provideglue. This eliminates bikesheds and therebyfast-tracks adoption at the expense of flexibility and diversity."
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 16:27:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Mikhail Krutov <nekoxmachina@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 16:27:09 GMT) (full text, mbox, link).

+ +

Message #6671 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Mikhail Krutov <nekoxmachina@gmail.com>
+
To: crgibrw@hushmail.com, 727708@bugs.debian.org
+
Cc: debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: Great article against systemd (note: you'll be banned + if you respond to this mail, like my other acct was).
+
Date: Mon, 10 Feb 2014 20:25:06 +0400
+
+
[Message part 1 (text/plain, inline)]
+
Even when I dislike systemd approach, you act as a spammer and you annoy
+people.
+This is the reason you are banned, not the paranoidal crap with "systemd
+fanboys blah blah blah".
+
+
+
+On Mon, Feb 10, 2014 at 7:44 PM, <crgibrw@hushmail.com> wrote:
+
+> That was a great article against systemd (note: you'll be banned if you
+> respond to this mail, like my other acct was):
+> (ewontfix.com/14/). Thanks for posting it.
+>
+> Note: do not respond to this email, you'll probably be banned. SystemD
+> fanbois are rooted deep in every linux distro.
+> They get their enemies banned. My other acct was banned for opposing their
+> bullsht. For 4 weeks (who cares).
+>
+>
+>
+> "The crowd pushing systemd, possibly including its author, is notcontent
+> to have systemd be one choice among many. By providing publicAPIs intended
+> to be used by other applications, systemd has set itselfup to be difficult
+> not to use once it achieves a certain adoptionthreshold."
+>
+> "None of the things systemd "does right" are at all revolutionary.They've
+> been done many times before. DJB'sdaemontools,runit, andSupervisor, among
+> others, have solved the"legacy init is broken" problem over and over again
+> (though each withsome of their own flaws). Their failure to displace legacy
+> sysvinit inmajor distributions had nothing to do with whether they solved
+> theproblem, and everything to do with marketing. Said differently,there's
+> nothing great and revolutionary about systemd. Its popularityis purely the
+> result of an aggressive, dictatorial marketing strategyincluding elements
+> such as:Engulfing other "essential" system components like udev and
+> makingthem difficult or impossible to use without systemd (but
+> seeeudev).Setting up for API lock-in (having the DBus interfaces provided
+> bysystemd become a necessary API that user-level programs depend
+> on).Dictating policy rather than being scoped such that the
+> user,administrator, or systems integrator (distribution) has to
+>  provideglue. This eliminates bikesheds and therebyfast-tracks adoption at
+> the expense of flexibility and diversity."
+>
+> --
+> To unsubscribe, send mail to 727708-unsubscribe@bugs.debian.org.
+>
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 16:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sam Hocevar <sam@hocevar.net>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 16:45:04 GMT) (full text, mbox, link).

+ +

Message #6676 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sam Hocevar <sam@hocevar.net>
+
To: Craig Bransworth <craigbransworth@aim.com>, 727708@bugs.debian.org
+
Cc: debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: Fsck SystemD and its developers and its users. GR to + override this please.
+
Date: Mon, 10 Feb 2014 17:33:32 +0100
+
+
On Mon, Feb 10, 2014, Craig Bransworth wrote:
+
+> Fuck systemd from the bottom of my heart.
+> Fuck it.
+> Fuck it.
+> 
+> FUCK SYSTEMD.
+> 
+> I do not want to learn systemd.
+> I do not want to deal with systemd.
+> I hate the way it does things.
+> I hate the way their community works.
+
+   Hi Craig. And thank you for your interest in Debian and its init
+system.
+
+   Have you heard of the OpenBSD project? (http://openbsd.org/) It's a
+free, functional and secure operating system. It looks exactly like the
+kind of project you'd enjoy, because it does not use systemd or upstart.
+It also has a friendly and very open community that I'm sure you'd find
+welcoming.
+
+Kind regards,
+-- 
+Sam.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 16:51:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zlatan Todoric <zlatan.todoric@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 16:51:10 GMT) (full text, mbox, link).

+ +

Message #6681 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zlatan Todoric <zlatan.todoric@gmail.com>
+
To: Mikhail Krutov <nekoxmachina@gmail.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Great article against systemd (note: you'll be banned + if you respond to this mail, like my other acct was).
+
Date: Mon, 10 Feb 2014 17:46:27 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Lets ban this crgibrw guy like *forever*. Thanks.
+
+
+On Mon, Feb 10, 2014 at 5:25 PM, Mikhail Krutov <nekoxmachina@gmail.com>wrote:
+
+> Even when I dislike systemd approach, you act as a spammer and you annoy
+> people.
+> This is the reason you are banned, not the paranoidal crap with "systemd
+> fanboys blah blah blah".
+>
+>
+>
+> On Mon, Feb 10, 2014 at 7:44 PM, <crgibrw@hushmail.com> wrote:
+>
+>> That was a great article against systemd (note: you'll be banned if you
+>> respond to this mail, like my other acct was):
+>> (ewontfix.com/14/). Thanks for posting it.
+>>
+>> Note: do not respond to this email, you'll probably be banned. SystemD
+>> fanbois are rooted deep in every linux distro.
+>> They get their enemies banned. My other acct was banned for opposing
+>> their bullsht. For 4 weeks (who cares).
+>>
+>>
+>>
+>> "The crowd pushing systemd, possibly including its author, is notcontent
+>> to have systemd be one choice among many. By providing publicAPIs intended
+>> to be used by other applications, systemd has set itselfup to be difficult
+>> not to use once it achieves a certain adoptionthreshold."
+>>
+>> "None of the things systemd "does right" are at all revolutionary.They've
+>> been done many times before. DJB'sdaemontools,runit, andSupervisor, among
+>> others, have solved the"legacy init is broken" problem over and over again
+>> (though each withsome of their own flaws). Their failure to displace legacy
+>> sysvinit inmajor distributions had nothing to do with whether they solved
+>> theproblem, and everything to do with marketing. Said differently,there's
+>> nothing great and revolutionary about systemd. Its popularityis purely the
+>> result of an aggressive, dictatorial marketing strategyincluding elements
+>> such as:Engulfing other "essential" system components like udev and
+>> makingthem difficult or impossible to use without systemd (but
+>> seeeudev).Setting up for API lock-in (having the DBus interfaces provided
+>> bysystemd become a necessary API that user-level programs depend
+>> on).Dictating policy rather than being scoped such that the
+>> user,administrator, or systems integrator (distribution) has to
+>>  provideglue. This eliminates bikesheds and therebyfast-tracks adoption
+>> at the expense of flexibility and diversity."
+>>
+>> --
+>> To unsubscribe, send mail to 727708-unsubscribe@bugs.debian.org.
+>>
+>
+>
+
+
+-- 
+Please while sending me text documents pay attention that they are by ISO
+standard that is in .odt format (For sending other types of documents
+please also refer to ISO/Open standars).
+Its not the COST, its the VALUE!
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 22:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bozhan Boiadzhiev <bozhan@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 22:57:04 GMT) (full text, mbox, link).

+ +

Message #6686 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bozhan Boiadzhiev <bozhan@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Strange
+
Date: Tue, 11 Feb 2014 00:56:22 +0200
+
+
[Message part 1 (text/plain, inline)]
+
Is it very strange to me that Debian developers and TC decide to choose
+for Debian GNU/Linux systemd, init system that is developed by developer
+who is notorious
+with his project specially Pulseaudio.
+What if we reach a state when our servers( of devoted debian users) won't
+start after upgrade and required by systemd reboot?
+
+Cheers
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 23:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Fklennart Pottering <fklennart.pottering@aol.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 23:00:05 GMT) (full text, mbox, link).

+ +

Message #6691 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Fklennart Pottering <fklennart.pottering@aol.com>
+
To: debian-devel@lists.debian.org
+
Cc: zigo@debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Fsck SystemD and its developers and its users. GR to + override this please.
+
Date: Mon, 10 Feb 2014 17:52:13 -0500 (EST)
+
+
[Message part 1 (text/plain, inline)]
+
>It is pretty ridiculous to me to consider the basic plumbing on the
+>system as replaceable as the thing that decides where on the screen my
+>shortcut to Google search for "lolcatz" goes.
+>
+>Perhaps that is just me though. ;)
+
+
+See, systemd pushers are always trying to make their thing the only thing.
+
+"We arre the space robots, we are here to protect you"
+"I am the shover robot, I push bread down their throats"
+"We are here to protect you"
+"Do not trust the pusher robot, he is malfunctioning"
+"Humans must be shoved, they must go down the stairs"
+"Please go stand by the stairs so I can protect"
+"I am better than the shover robot"
+
+--Shover and Pusher Robot
+::Wrong way to do things.
+
+"Oh. My. Money"
+'Don't you mean God?'
+"You worship your thing, I'll worship mine"
+--Seto Kaiba
+:: Correct way to do things.
+
+
+
+
+
+>Do we allow users to choose their FireWire stack, WiFi or Audio Driver
+>stack in the kernel? There were several alternative implementations
+>of these, yet we only provide one of each.
+
+>Adrian
+
+Adrian: Fuck you you cunt.
+You scumbags are forcing this thing on all of us.
+We're going to have to do something about that
+if you do not back the fuck down.
+
+Systemd people seem always to be fucking
+totalitarian PIECES OF SHIT like you.
+Fuck your SystemD, and FUCK
+your "MY WAY OR THE HIGHWAY" approach.
+
+
+"Oh. My. Money"
+'Don't you mean God?'
+"You worship your thing, I'll worship mine"
+--Seto Kaiba
+:: Correct way to do things.
+
+(Not forcing your fucking lennart pottering autistic fggt religion on us)
+
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 23:03:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "Paul R. Tagliamonte" <paultag@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 23:03:05 GMT) (full text, mbox, link).

+ +

Message #6696 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Paul R. Tagliamonte" <paultag@gmail.com>
+
To: Bozhan Boiadzhiev <bozhan@gmail.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Strange
+
Date: Mon, 10 Feb 2014 17:59:23 -0500
+
+
[Message part 1 (text/plain, inline)]
+
Since you're having trouble booting your system, can you please report a
+bug with your setup and how to reproduce?
+On Feb 10, 2014 5:57 PM, "Bozhan Boiadzhiev" <bozhan@gmail.com> wrote:
+
+> Is it very strange to me that Debian developers and TC decide to choose
+> for Debian GNU/Linux systemd, init system that is developed by developer
+> who is notorious
+> with his project specially Pulseaudio.
+> What if we reach a state when our servers( of devoted debian users) won't
+> start after upgrade and required by systemd reboot?
+>
+> Cheers
+>
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 10 Feb 2014 23:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to fklennartpottering@hushmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 10 Feb 2014 23:33:05 GMT) (full text, mbox, link).

+ +

Message #6701 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: fklennartpottering@hushmail.com
+
To: debian-devel@lists.debian.org
+
Cc: 727708@bugs.debian.org, jonathan@ubuntu.com, zigo@debian.org
+
Subject: PLEASE GR to override this forcing of Lennart Potterings BULLSHIT. Or Fork debian.
+
Date: Mon, 10 Feb 2014 17:49:16 -0500
+
+
[Message part 1 (text/plain, inline)]
+
>It is pretty ridiculous to me to consider the basic plumbing on the
+>system as replaceable as the thing that decides where on the screen
+my
+>shortcut to Google search for "lolcatz" goes.
+>
+>Perhaps that is just me though. ;)
+See, systemd pushers are always trying to make their thing the only
+thing.
+
+"We arre the space robots, we are here to protect you"
+"I am the shover robot, I push bread down their throats"
+"We are here to protect you"
+"Do not trust the pusher robot, he is malfunctioning"
+"Humans must be shoved, they must go down the stairs"
+"Please go stand by the stairs so I can protect"
+"I am better than the shover robot"
+
+--Shover and Pusher Robot
+::Wrong way to do things.
+
+"Oh. My. Money"
+'Don't you mean God?'
+"You worship your thing, I'll worship mine"
+--Seto Kaiba
+:: Correct way to do things.
+>Do we allow users to choose their FireWire stack, WiFi or Audio
+Driver
+>stack in the kernel? There were several alternative implementations
+>of these, yet we only provide one of each.
+
+>Adrian
+
+Adrian: Fuck you you cunt.
+You scumbags are forcing this thing on all of us.
+We're going to have to do something about that
+if you do not back the fuck down.
+
+Systemd people seem always to be fucking
+totalitarian PIECES OF SHIT like you.
+Fuck your SystemD, and FUCK
+your "MY WAY OR THE HIGHWAY" approach.
+"Oh. My. Money"
+'Don't you mean God?'
+"You worship your thing, I'll worship mine"
+--Seto Kaiba
+:: Correct way to do things.
+
+(Not forcing your fucking lennart pottering autistic faggot religion
+on us)
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 07:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Mikhail Krutov <nekoxmachina@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 07:18:04 GMT) (full text, mbox, link).

+ +

Message #6706 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Mikhail Krutov <nekoxmachina@gmail.com>
+
To: "Paul R. Tagliamonte" <paultag@gmail.com>, 727708@bugs.debian.org
+
Cc: Bozhan Boiadzhiev <bozhan@gmail.com>
+
Subject: Re: Bug#727708: Strange
+
Date: Tue, 11 Feb 2014 11:15:27 +0400
+
+
[Message part 1 (text/plain, inline)]
+
E.g., stable system (always-has-been-stable) debian proposes not to try to
+avoid problems (e.g. by not choosing stuff that needs to reboot your pc
+when upgrading non-kernel), but to wait for them and only then tell about
+them? Feels rather strange.
+
+
+On Tue, Feb 11, 2014 at 2:59 AM, Paul R. Tagliamonte <paultag@gmail.com>wrote:
+
+> Since you're having trouble booting your system, can you please report a
+> bug with your setup and how to reproduce?
+> On Feb 10, 2014 5:57 PM, "Bozhan Boiadzhiev" <bozhan@gmail.com> wrote:
+>
+>> Is it very strange to me that Debian developers and TC decide to choose
+>> for Debian GNU/Linux systemd, init system that is developed by developer
+>> who is notorious
+>> with his project specially Pulseaudio.
+>> What if we reach a state when our servers( of devoted debian users) won't
+>> start after upgrade and required by systemd reboot?
+>>
+>> Cheers
+>>
+>
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 08:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 08:09:04 GMT) (full text, mbox, link).

+ +

Message #6711 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Tue, 11 Feb 2014 09:07:11 +0100
+
+
* Bdale Garbee (bdale@gag.com) [140208 20:50]:
+> I expect that Debian can and should continue to support multiple init
+> systems for the foreseeable future.  I also believe that Debian can and
+> should take an active role working with upstream projects on software
+> that is important to us, such as init system projects. 
+
+[...]
+
+> - - - start ballot - - -
+> 
+> We exercise our power to decide in cases of overlapping jurisdiction
+> (6.1.2) by asserting that the default init system for Linux
+> architectures in jessie should be
+> 
+>   D    systemd 
+> 
+>   U    upstart
+> 
+>   O    openrc
+> 
+>   V    sysvinit (no change)
+> 
+>   F    requires further discussion
+> 
+> Should the project pass a General Resolution before the release of
+> "jessie" asserting a "position statement about issues of the day" on
+> init systems, that position replaces the outcome of this vote and is
+> adopted by the Technical Committee as its own decision.
+> 
+> - - - end ballot - - -
+
+I'm unhappy with this resolution; in fact, after the discussions I
+don't think it would be good to decide on an init system without
+explicitly stating that users should be able to continue to make
+different decisions on their own systems (and in hindsight it was an
+error that I voted FD on the previous call for votes to allow textual
+optimizations). This is especially true for systemd (I consider the
+probability of people to depend soley on upstart to be lower) - after
+some long thinking about this I came to the conclusion that I cannot
+vote systemd above further discussion in the current scenario. (Also I
+hope but don't expect that the discussions we had on our list are
+enough for maintainers to not try to force a specific init system on
+our users.)
+
+
+Thus voting U, F, D, O, V.
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 08:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 08:12:05 GMT) (full text, mbox, link).

+ +

Message #6716 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system coupling call for votes
+
Date: Tue, 11 Feb 2014 09:08:26 +0100
+
+
* Ian Jackson (ijackson@chiark.greenend.org.uk) [140209 20:51]:
+> I hereby call for votes on the following resolution:
+> 
+>    The init system decision is limited to selecting a default
+>    initsystem for jessie.  We expect that Debian will continue to
+>    support multiple init systems for the foreseeable future; we
+>    continue to welcome contributions of support for all init systems.
+> 
+>    Therefore, for jessie and later releases, we exercise our power to
+>    set technical policy (Constitution 6.1.1):
+> 
+>    Software outside of an init system's implementation may not require
+>    a specific init system to be pid 1, although degraded operation is
+>    tolerable.
+> 
+>    Maintainers are encouraged to accept technically sound patches
+>    to enable improved interoperation with various init systems.
+
+
+Voting in favour (i.e. Resolution, FD).
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 08:12:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 08:12:08 GMT) (full text, mbox, link).

+ +

Message #6721 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system GR override call for votes
+
Date: Tue, 11 Feb 2014 09:09:38 +0100
+
+
* Ian Jackson (ijackson@chiark.greenend.org.uk) [140209 20:57]:
+> I hereby call for votes on the following resolution
+> 
+>    If the project passes (before the release of jessie) by a General
+>    Resolution, a "position statement about issues of the day", on the
+>    subject of init systems, the views expressed in that position
+>    statement entirely replace the substance of any TC resolution (past
+>    or future) on the same topic; the TC hereby adopts any such
+>    position statement as its own decision.
+> 
+>    Such a position statement could, for example, use these words:
+> 
+>       The Project requests (as a position statement under s4.1.5 of the
+>       Constitution) that the TC reconsider, and requests that the TC
+>       would instead decide as follows:
+
+I think this is already covered by Bdales text, so unless there are
+reasons I missed I intend to vote no here (i.e. FD first).
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 08:33:04 GMT) (full text, mbox, link).

+ +

Message #6724 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: Andreas Barth <aba@ayous.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system coupling call for votes
+
Date: Tue, 11 Feb 2014 09:27:52 +0100
+
+
Hi,
+
+Andreas Barth <aba@ayous.org> writes:
+>> I hereby call for votes on the following resolution:
+>> 
+>>    The init system decision is limited to selecting a default
+>>    initsystem for jessie.  We expect that Debian will continue to
+>>    support multiple init systems for the foreseeable future; we
+>>    continue to welcome contributions of support for all init systems.
+>> 
+>>    Therefore, for jessie and later releases, we exercise our power to
+>>    set technical policy (Constitution 6.1.1):
+>> 
+>>    Software outside of an init system's implementation may not require
+>>    a specific init system to be pid 1, although degraded operation is
+>>    tolerable.
+>> 
+>>    Maintainers are encouraged to accept technically sound patches
+>>    to enable improved interoperation with various init systems.
+>
+> Voting in favour (i.e. Resolution, FD).
+
+I think it is a very bad idea to vote on a resolution proposed in
+anger, pretty much regardless of the contents.
+
+Ansgar
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 08:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Anthony Towns <aj@erisian.com.au>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 08:48:05 GMT) (full text, mbox, link).

+ +

Message #6729 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Anthony Towns <aj@erisian.com.au>
+
To: 727708@bugs.debian.org, Kurt Roeckx <kurt@roeckx.be>
+
Subject: Re: call for votes on default Linux init system for jessie
+
Date: Tue, 11 Feb 2014 08:45:17 +0000
+
+
On Sat, Feb 08, 2014 at 12:56:56PM -0700, Bdale Garbee wrote:
+> Bdale Garbee <bdale@gag.com> writes:
+> > - - - start ballot - - -
+> > We exercise our power to decide in cases of overlapping jurisdiction
+> > (6.1.2) by asserting that the default init system for Linux
+> > architectures in jessie should be
+> >   D    systemd 
+> >   U    upstart
+> >   O    openrc
+> >   V    sysvinit (no change)
+> >   F    requires further discussion
+> > Should the project pass a General Resolution before the release of
+> > "jessie" asserting a "position statement about issues of the day" on
+> > init systems, that position replaces the outcome of this vote and is
+> > adopted by the Technical Committee as its own decision.
+> > - - - end ballot - - -
+> I vote D U O V F.
+
+On Sat, Feb 08, 2014 at 12:16:51PM -0800, Russ Allbery wrote:
+> I vote:
+>     D U O V F
+
+On Sat, Feb 08, 2014 at 02:18:39PM -0800, Steve Langasek wrote:
+> I vote F U D O V
+
+On Sat, Feb 08, 2014 at 02:51:13PM -0800, Don Armstrong wrote:
+> I vote D > U > O > V > F.
+
+On Sat, Feb 08, 2014 at 02:57:52PM -0800, Keith Packard wrote:
+> I vote:
+>         1.      D
+>         2.      U
+>         3.      O
+>         4.      V
+>         5.      F
+
+On Sun, Feb 09, 2014 at 01:04:31PM +0000, Colin Watson wrote:
+> I vote UDOFV.
+
+On Sun, Feb 09, 2014 at 07:15:58PM +0000, Ian Jackson wrote:
+> I vote F, V, O, U, D.
+
+On Tue, Feb 11, 2014 at 09:07:11AM +0100, Andreas Barth wrote:
+> Thus voting U, F, D, O, V.
+
+So that's all the votes in, by my count. Summary is:
+
+  4x D U O V F (bdale, russ, keith, don)
+     F U D O V (steve)
+     U D O F V (colin)
+     F V O U D (ian)
+     U F D O V (andi)
+
+Pairwise defeats are:
+
+  D = U  (4:4)
+
+  U and D > O and V  
+         (7:1) (ian against)
+  O > V  (7:1) (ian against)
+
+  U > F  (6:2) (steve, ian against)
+  D > F  (5:3) (steve, ian, andi against)
+  O > F  (5:3) (steve, ian, andi against)
+  V = F  (4:4)
+
+A.6.2: Quorum is 2 (6.3.1), all options meet quorum.
+A.6.3: Option V does not strictly defeat default option F, so is eliminated
+A.6.5: Transitive defeats are:
+
+  D : O, F (directly)
+  U : O, F (directly)
+  O : F (directly)
+  F :
+
+A.6.6: Schwartz set is {D,U}
+A.6.8: There are no defeats in the Schwartz set, so the elector with
+       the casting vote chooses which of these options wins.
+
+Per 6.3.2, the casting vote is held by the Chairman, who is currently
+Bdale.
+
+Per 6.3.1, the voting period expires either Feb 15th, or when the outcome
+is no longer in doubt. Not clear to me if that's now, or only after Bdale
+specifies a casting vote. Per 7.3, if there's any dispute about that, the
+secretary adjudicates that dispute.
+
+Cheers,
+aj
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 14:39:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 14:39:15 GMT) (full text, mbox, link).

+ +

Message #6734 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Anthony Towns <aj@erisian.com.au>
+
Cc: 727708@bugs.debian.org, secretary@debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 11 Feb 2014 07:35:13 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Anthony Towns <aj@erisian.com.au> writes:
+
+> A.6.6: Schwartz set is {D,U}
+> A.6.8: There are no defeats in the Schwartz set, so the elector with
+>        the casting vote chooses which of these options wins.
+>
+> Per 6.3.2, the casting vote is held by the Chairman, who is currently
+> Bdale.
+
+Thank you, Anthony, for your analysis of the votes.
+
+Per 6.3.2, I use my casting vote to choose D as the winner.
+
+Therefore, the resolution reads:
+
+  We exercise our power to decide in cases of overlapping jurisdiction
+  (6.1.2) by asserting that the default init system for Linux
+  architectures in jessie should be systemd.
+
+  Should the project pass a General Resolution before the release of
+  "jessie" asserting a "position statement about issues of the day" on
+  init systems, that position replaces the outcome of this vote and is
+  adopted by the Technical Committee as its own decision.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 15:12:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to svante.signell@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 15:12:05 GMT) (full text, mbox, link).

+ +

Message #6739 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Svante Signell <svante.signell@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: [Fwd: Re: Bug#727708: call for votes on default Linux init system + for jessie]
+
Date: Tue, 11 Feb 2014 16:09:19 +0100
+
+
[Message part 1 (text/plain, inline)]
+
+
+
[Message part 2 (message/rfc822, inline)]
+
+
+ +
From: Svante Signell <svante.signell@gmail.com>
+
To: debian-ctte@lists.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 11 Feb 2014 16:05:55 +0100
+
+
+> Anthony Towns <aj@erisian.com.au> writes:
+> 
+> > A.6.6: Schwartz set is {D,U}
+> > A.6.8: There are no defeats in the Schwartz set, so the elector with
+> >        the casting vote chooses which of these options wins.
+> >
+> > Per 6.3.2, the casting vote is held by the Chairman, who is currently
+> > Bdale.
+> 
+> Thank you, Anthony, for your analysis of the votes.
+> 
+> Per 6.3.2, I use my casting vote to choose D as the winner.
+> 
+> Therefore, the resolution reads:
+> 
+>   We exercise our power to decide in cases of overlapping jurisdiction
+>   (6.1.2) by asserting that the default init system for Linux
+>   architectures in jessie should be systemd.
+> 
+>   Should the project pass a General Resolution before the release of
+>   "jessie" asserting a "position statement about issues of the day" on
+>   init systems, that position replaces the outcome of this vote and is
+>   adopted by the Technical Committee as its own decision.
+> 
+> Bdale
+
+How can you make this statement when the voting period is not over?
+What if some CTTE members decide to change their vote? Andreas Barth
+changed his vote today!
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 15:39:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Emilio Pozuelo Monfort <pochu@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 15:39:15 GMT) (full text, mbox, link).

+ +

Message #6744 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Emilio Pozuelo Monfort <pochu@debian.org>
+
To: svante.signell@gmail.com, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: [Fwd: Re: Bug#727708: call for votes on default Linux + init system for jessie]
+
Date: Tue, 11 Feb 2014 16:38:05 +0100
+
+
On 11/02/14 16:09, Svante Signell wrote:
+> How can you make this statement when the voting period is not over?
+> What if some CTTE members decide to change their vote?
+
+Debian Constitution 6.3.1:
+
+"the voting period lasts for up to one week, or until the outcome is no longer
+in doubt."
+
+Given that all eight committee members have voted and the outcome is no longer
+in doubt, the voting period is over and the chairman of the committee can use
+his casting vote.
+
+> Andreas Barth changed his vote today!
+
+No, he hasn't changed his vote. He has voted today but he hasn't changed his
+vote as he hadn't voted before on this resolution. That is why the outcome was
+still "in doubt", as Andreas could have ranked D above U, making the outcome
+different (just D in the Schwartz set and no need for the casting vote).
+
+Emilio
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 16:39:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 16:39:09 GMT) (full text, mbox, link).

+ +

Message #6749 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system coupling call for votes
+
Date: Tue, 11 Feb 2014 09:34:35 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I hereby call for votes on the following resolution:
+>
+>    The init system decision is limited to selecting a default
+>    initsystem for jessie.  We expect that Debian will continue to
+>    support multiple init systems for the foreseeable future; we
+>    continue to welcome contributions of support for all init systems.
+>
+>    Therefore, for jessie and later releases, we exercise our power to
+>    set technical policy (Constitution 6.1.1):
+>
+>    Software outside of an init system's implementation may not require
+>    a specific init system to be pid 1, although degraded operation is
+>    tolerable.
+>
+>    Maintainers are encouraged to accept technically sound patches
+>    to enable improved interoperation with various init systems.
+
+I vote FD.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 16:39:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 16:39:13 GMT) (full text, mbox, link).

+ +

Message #6754 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system GR override call for votes
+
Date: Tue, 11 Feb 2014 09:36:26 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I hereby call for votes on the following resolution
+>
+>    If the project passes (before the release of jessie) by a General
+>    Resolution, a "position statement about issues of the day", on the
+>    subject of init systems, the views expressed in that position
+>    statement entirely replace the substance of any TC resolution (past
+>    or future) on the same topic; the TC hereby adopts any such
+>    position statement as its own decision.
+>
+>    Such a position statement could, for example, use these words:
+>
+>       The Project requests (as a position statement under s4.1.5 of the
+>       Constitution) that the TC reconsider, and requests that the TC
+>       would instead decide as follows:
+
+Substantially similar language reviewed by the project secretary was
+already approved by the TC in the ballot just concluded, so I feel this
+is redundant.
+
+I vote FD.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 17:03:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 17:03:09 GMT) (full text, mbox, link).

+ +

Message #6759 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Bdale Garbee <bdale@gag.com>, 727708@bugs.debian.org
+
Cc: Anthony Towns <aj@erisian.com.au>, secretary@debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 11 Feb 2014 08:59:53 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Feb 11, 2014 at 07:35:13AM -0700, Bdale Garbee wrote:
+> Anthony Towns <aj@erisian.com.au> writes:
+
+> > A.6.6: Schwartz set is {D,U}
+> > A.6.8: There are no defeats in the Schwartz set, so the elector with
+> >        the casting vote chooses which of these options wins.
+
+> > Per 6.3.2, the casting vote is held by the Chairman, who is currently
+> > Bdale.
+
+> Thank you, Anthony, for your analysis of the votes.
+
+> Per 6.3.2, I use my casting vote to choose D as the winner.
+
+FWIW I have always assumed that the casting vote is implicit in the chair's
+ballot.  To require the chair to explicitly exercise their casting vote, as
+opposed to the chair's preferences as expressed on the ballot being applied
+automatically, opens up another set of vote gaming strategies that we really
+shouldn't get into.
+
+(Obviously there's no gaming here, as Bdale's casting vote is consistent
+with his ballot; but let's not set a bad precedent...)
+
+Thanks,
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 17:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 17:09:04 GMT) (full text, mbox, link).

+ +

Message #6764 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Cc: Anthony Towns <aj@erisian.com.au>, secretary@debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 11 Feb 2014 10:07:40 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Steve Langasek <vorlon@debian.org> writes:
+
+> FWIW I have always assumed that the casting vote is implicit in the chair's
+> ballot.  To require the chair to explicitly exercise their casting vote, as
+> opposed to the chair's preferences as expressed on the ballot being applied
+> automatically, opens up another set of vote gaming strategies that we really
+> shouldn't get into.
+
+I would have assumed that, too, but since others did not share the
+assumption, it seemed prudent to be explicit about it.  
+
+I suppose it's always possible that the chair might change their mind
+after seeing how votes are cast and the comments associated with those
+votes.  Should the project choose to try and amend the constitution at
+some point to address corner cases in the voting process or TC rules of
+engagement exposed through this process, this might be a detail worth
+addressing explicitly.
+
+On the other hand, we have never needed the TC casting vote before, and
+I sincerely hope we never do again.  
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 17:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sam Hartman <hartmans@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 17:21:04 GMT) (full text, mbox, link).

+ +

Message #6769 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sam Hartman <hartmans@debian.org>
+
To: Bdale Garbee <bdale@gag.com>
+
Cc: 727708@bugs.debian.org, Steve Langasek <vorlon@debian.org>, Anthony Towns <aj@erisian.com.au>, secretary@debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 11 Feb 2014 12:18:41 -0500
+
+
>>>>> "Bdale" == Bdale Garbee <bdale@gag.com> writes:
+
+    Bdale> Steve Langasek <vorlon@debian.org> writes:
+    >> FWIW I have always assumed that the casting vote is implicit in
+    >> the chair's ballot.  To require the chair to explicitly exercise
+    >> their casting vote, as opposed to the chair's preferences as
+    >> expressed on the ballot being applied automatically, opens up
+    >> another set of vote gaming strategies that we really shouldn't
+    >> get into.
+
+    Bdale> I would have assumed that, too, but since others did not
+    Bdale> share the assumption, it seemed prudent to be explicit about
+    Bdale> it.
+
+This assumption does not make sense to me in the following cases:
+
+* Chair ranks multiple options equilly
+
+* All of the options that the chair is choosing between were ranked by
+  the chair below FD
+
+* At least one of the options was not ranked by the chair.
+
+* I don't know if casting votes can come up in DPL elections or if there
+are any other circumstances with secret ballots.
+
+I think you're safer just casting an explicit casting vote.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 17:42:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 17:42:14 GMT) (full text, mbox, link).

+ +

Message #6774 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system coupling call for votes
+
Date: Tue, 11 Feb 2014 09:39:45 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I hereby call for votes on the following resolution:
+
+>    The init system decision is limited to selecting a default
+>    initsystem for jessie.  We expect that Debian will continue to
+>    support multiple init systems for the foreseeable future; we
+>    continue to welcome contributions of support for all init systems.
+
+>    Therefore, for jessie and later releases, we exercise our power to
+>    set technical policy (Constitution 6.1.1):
+
+>    Software outside of an init system's implementation may not require
+>    a specific init system to be pid 1, although degraded operation is
+>    tolerable.
+
+>    Maintainers are encouraged to accept technically sound patches
+>    to enable improved interoperation with various init systems.
+
+I vote FD (by which I really mean FD, not no).
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 19:03:18 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 19:03:18 GMT) (full text, mbox, link).

+ +

Message #6779 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Sam Hartman <hartmans@debian.org>, 727708@bugs.debian.org
+
Cc: Bdale Garbee <bdale@gag.com>, Anthony Towns <aj@erisian.com.au>, + secretary@debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 11 Feb 2014 10:59:34 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Feb 11, 2014 at 12:18:41PM -0500, Sam Hartman wrote:
+> >>>>> "Bdale" == Bdale Garbee <bdale@gag.com> writes:
+
+>     Bdale> Steve Langasek <vorlon@debian.org> writes:
+>     >> FWIW I have always assumed that the casting vote is implicit in
+>     >> the chair's ballot.  To require the chair to explicitly exercise
+>     >> their casting vote, as opposed to the chair's preferences as
+>     >> expressed on the ballot being applied automatically, opens up
+>     >> another set of vote gaming strategies that we really shouldn't
+>     >> get into.
+
+>     Bdale> I would have assumed that, too, but since others did not
+>     Bdale> share the assumption, it seemed prudent to be explicit about
+>     Bdale> it.
+
+> This assumption does not make sense to me in the following cases:
+
+> * Chair ranks multiple options equilly
+
+If the chair ranked them equally in his ballot, why should he express a
+different preference when it comes to the casting vote?  Or, put
+differently: if the chair comes to a decision about which of the
+equally-ranked options should win, why should that decision not be reflected
+in his main vote (with the effect that the "casting" vote will not be used
+at all)?
+
+> * All of the options that the chair is choosing between were ranked by
+>   the chair below FD
+
+Being below FD does not imply that no preference is being expressed between
+the options.  Rankings between such options are taken into account at every
+other stage of the vote, there's no reason it should be different for the
+casting vote.
+
+> * At least one of the options was not ranked by the chair.
+
+Unranked options are treated as ranked last, so whichever option is *not*
+unranked gets the vote.
+
+> * I don't know if casting votes can come up in DPL elections or if there
+> are any other circumstances with secret ballots.
+
+If they are, why should the casting vote be less secret than the normal
+ballot?
+
+> I think you're safer just casting an explicit casting vote.
+
+The only case in which it makes a difference to have an explicit casting
+vote is when the preferences expressed in the casting vote do not match the
+preferences expressed in the standard vote.  If that ever happened, it would
+be an act of strategic voting.  When all other aspects of our voting system
+are designed to minimize the rewards of strategic voting, this seems an
+unnecessary bug.  It's a low-impact bug, because it requires both three
+nearly-balanced ballot options, and a TC chair willing to engage in
+strategic voting for all the world to see; but it's still a bug.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 19:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 19:09:04 GMT) (full text, mbox, link).

+ +

Message #6784 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system coupling call for votes
+
Date: Tue, 11 Feb 2014 11:06:59 -0800
+
+
On Sun, 09 Feb 2014, Ian Jackson wrote:
+> I hereby call for votes on the following resolution:
+> 
+>    The init system decision is limited to selecting a default
+>    initsystem for jessie.  We expect that Debian will continue to
+>    support multiple init systems for the foreseeable future; we
+>    continue to welcome contributions of support for all init systems.
+> 
+>    Therefore, for jessie and later releases, we exercise our power to
+>    set technical policy (Constitution 6.1.1):
+> 
+>    Software outside of an init system's implementation may not require
+>    a specific init system to be pid 1, although degraded operation is
+>    tolerable.
+> 
+>    Maintainers are encouraged to accept technically sound patches
+>    to enable improved interoperation with various init systems.
+
+I vote FD. I think something along these lines should be done, but (as
+stated previously), I believe that the third paragraph places work on
+the maintainer which does not need to be there, and additionally does
+not limit this restriction to the release of jessie.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+I cannot find rest
+Because I am powerless
+To amend a broken world.
+ -- Guy Gavriel Kay _Under Heaven_ p295
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 19:09:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 19:09:07 GMT) (full text, mbox, link).

+ +

Message #6789 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system GR override call for votes
+
Date: Tue, 11 Feb 2014 11:08:06 -0800
+
+
On Sun, 09 Feb 2014, Ian Jackson wrote:
+
+> I hereby call for votes on the following resolution
+> 
+>    If the project passes (before the release of jessie) by a General
+>    Resolution, a "position statement about issues of the day", on the
+>    subject of init systems, the views expressed in that position
+>    statement entirely replace the substance of any TC resolution (past
+>    or future) on the same topic; the TC hereby adopts any such
+>    position statement as its own decision.
+> 
+>    Such a position statement could, for example, use these words:
+> 
+>       The Project requests (as a position statement under s4.1.5 of the
+>       Constitution) that the TC reconsider, and requests that the TC
+>       would instead decide as follows:
+
+I vote FD. The current proposal already handles this case.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+The terrorist's job is to terrorize the people, to interfere with
+freedom in such a way that disrupts ordinary life and commerce. With
+due respect, it is clear that the above referenced governmental
+agencies are aiding the terrorists' objective.
+ -- Gary Fielder in Gary Fielder vs Janet Napolitano et al.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 19:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 19:18:04 GMT) (full text, mbox, link).

+ +

Message #6794 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: 727708@bugs.debian.org, secretary@debian.org
+
Subject: Re: Bug#727708: Init system Call for Votes, Ian's drafts
+
Date: Tue, 11 Feb 2014 12:14:17 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I hereby propose the L versions from git:
+>
+>   == dependencies rider version L (Loose coupling) ==
+>
+>      Software outside of an init system's implementation may not require
+>      a specific init system to be pid 1, although degraded operation is
+>      tolerable.
+>
+>      Maintainers are encouraged to accept technically sound patches
+>      to enable improved interoperation with various init systems.
+>
+> as amendments to my own formal proposal, and do not accept them.
+>
+> I hereby call for votes on my own formal proposal.
+
+I vote FD.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 19:24:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 19:24:07 GMT) (full text, mbox, link).

+ +

Message #6799 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Cc: Sam Hartman <hartmans@debian.org>, Bdale Garbee <bdale@gag.com>, + Anthony Towns <aj@erisian.com.au>, secretary@debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 11 Feb 2014 20:22:19 +0100
+
+
On Tue, Feb 11, 2014 at 10:59:34AM -0800, Steve Langasek wrote:
+> On Tue, Feb 11, 2014 at 12:18:41PM -0500, Sam Hartman wrote:
+> > >>>>> "Bdale" == Bdale Garbee <bdale@gag.com> writes:
+> 
+> >     Bdale> Steve Langasek <vorlon@debian.org> writes:
+> >     >> FWIW I have always assumed that the casting vote is implicit in
+> >     >> the chair's ballot.  To require the chair to explicitly exercise
+> >     >> their casting vote, as opposed to the chair's preferences as
+> >     >> expressed on the ballot being applied automatically, opens up
+> >     >> another set of vote gaming strategies that we really shouldn't
+> >     >> get into.
+> 
+> >     Bdale> I would have assumed that, too, but since others did not
+> >     Bdale> share the assumption, it seemed prudent to be explicit about
+> >     Bdale> it.
+> 
+> > This assumption does not make sense to me in the following cases:
+> 
+> > * Chair ranks multiple options equilly
+> 
+> If the chair ranked them equally in his ballot, why should he express a
+> different preference when it comes to the casting vote?
+
+I think the vote should always result in something, and as such
+the person having the casting vote needs to pick one of the
+options that are left in the Schwartz set.  If there was no
+preference between them, a choise will still need to be made.
+
+I've actually been wondering about this issue myself the past few
+days, and this seems to me the only good reason why the casting
+vote should be a different vote than the earlier vote.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 19:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 19:33:05 GMT) (full text, mbox, link).

+ +

Message #6804 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, 727708@bugs.debian.org, secretary@debian.org
+
Subject: Re: Bug#727708: Init system Call for Votes, Ian's drafts
+
Date: Tue, 11 Feb 2014 11:29:25 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+>> I hereby call for votes on my own formal proposal.
+
+I vote FD above all other options.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 19:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 19:36:04 GMT) (full text, mbox, link).

+ +

Message #6809 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system coupling call for votes
+
Date: Tue, 11 Feb 2014 11:32:25 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I hereby call for votes on the following resolution:
+>
+>    The init system decision is limited to selecting a default
+>    initsystem for jessie.  We expect that Debian will continue to
+>    support multiple init systems for the foreseeable future; we
+>    continue to welcome contributions of support for all init systems.
+>
+>    Therefore, for jessie and later releases, we exercise our power to
+>    set technical policy (Constitution 6.1.1):
+>
+>    Software outside of an init system's implementation may not require
+>    a specific init system to be pid 1, although degraded operation is
+>    tolerable.
+>
+>    Maintainers are encouraged to accept technically sound patches
+>    to enable improved interoperation with various init systems.
+
+I vote FD above all other options.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 19:45:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 19:45:10 GMT) (full text, mbox, link).

+ +

Message #6814 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system GR override call for votes
+
Date: Tue, 11 Feb 2014 11:40:04 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I hereby call for votes on the following resolution
+>
+>    If the project passes (before the release of jessie) by a General
+>    Resolution, a "position statement about issues of the day", on the
+>    subject of init systems, the views expressed in that position
+>    statement entirely replace the substance of any TC resolution (past
+>    or future) on the same topic; the TC hereby adopts any such
+>    position statement as its own decision.
+>
+>    Such a position statement could, for example, use these words:
+>
+>       The Project requests (as a position statement under s4.1.5 of the
+>       Constitution) that the TC reconsider, and requests that the TC
+>       would instead decide as follows:
+
+I vote FD above all other options.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 19:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 19:57:04 GMT) (full text, mbox, link).

+ +

Message #6819 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org, Sam Hartman <hartmans@debian.org>, 727708@bugs.debian.org
+
Cc: Bdale Garbee <bdale@gag.com>, Anthony Towns <aj@erisian.com.au>, secretary@debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 11 Feb 2014 11:54:50 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Steve Langasek <vorlon@debian.org> writes:
+
+> If the chair ranked them equally in his ballot, why should he express a
+> different preference when it comes to the casting vote?
+
+Oh, the obvious answer -- if the chair's preference didn't end up in the
+tie, he'd have to explicitly vote from the remaining options.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 19:57:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Maas Verri <maas.verri@aim.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 19:57:07 GMT) (full text, mbox, link).

+ +

Message #6824 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Maas Verri <maas.verri@aim.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Fsck SystemD and its developers and its users. GR to + override this please.
+
Date: Tue, 11 Feb 2014 14:55:00 -0500 (EST)
+
+
[Message part 1 (text/plain, inline)]
+
SYSTEMV WORKS RIGHT FUCKING NOW YOU FUCKING PIECE OF SHIT.
+Debian needs to be forked, or the systemd pushers
+like John Paul Adrian Glaubitz need to be thrown 
+out of debian.
+
+This is their fucking computer religion and they
+are forcing it on us. They will NOT accept 
+everyone being able to actually choose their
+init system, (like SYSV which WORKS! NOW),
+we MUST be FORCED to use THEIR religion.
+
+FUCK THEM.
+
+Honestly, if I met Adrian I would beat the shit
+out of him. Maybe something like that needs to
+happen to these fucks.
+
+If they are physically incapacitated they
+cannot force systemd on us, they can only
+play with it in their minds while they
+are in their coma.
+
+>Adrian Wrote:
+>On 02/11/2014 09:13 AM, Thomas Goirand wrote:
+>>> It seems that in case of systemd it may end being forced, doesn't Gnome
+>>> 3 depend on it?
+>> .
+>> We have between 40 and 50 window managers in Debian. Nobody forces you
+>> to use Gnome. How about switching to TWM! :)
+>
+>Window managers are leaf packages, at least they should be. If "awesome"
+>or "fvwm" are broken, other window managers or desktops won't be
+>affected at all.
+>
+>If you are running into problems with your init system, you are risking
+>to affect hundreds of other packages. Core components like init should
+>be carefully chosen and maintained to be able to guarantee a stable
+>environment.
+>..
+>Adrian
+>
+>-- 
+> .''`.  John Paul Adrian Glaubitz
+>: :' :  Debian Developer - glaubitz@debian.org
+>`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
+>  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
+
+
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 20:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Antti-Juhani Kaijanaho <antti-juhani@kaijanaho.fi>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 20:00:05 GMT) (full text, mbox, link).

+ +

Message #6829 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Antti-Juhani Kaijanaho <antti-juhani@kaijanaho.fi>
+
To: Kurt Roeckx <kurt@roeckx.be>, 727708@bugs.debian.org
+
Cc: secretary@debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 11 Feb 2014 21:57:26 +0200
+
+
On Tue, Feb 11, 2014 at 08:22:19PM +0100, Kurt Roeckx wrote:
+> I think the vote should always result in something, and as such
+> the person having the casting vote needs to pick one of the
+> options that are left in the Schwartz set.  If there was no
+> preference between them, a choise will still need to be made.
+
+I have, when serving as a chair of an association meeting, voted blank in many
+occasions, and in the one case where it resulted in a tie, I used my casting
+vote to resolve it.  In those cases, it was not important for me to choose
+between the options during the regular vote, hence the blank vote.  However,
+when the vote resulted in a tie, I had an obligation, imposed by law, custom
+and the association's constitution, to choose; and I did.
+
+However, in any vote where I as a chair have already voted non-blank, I feel it
+would be wrong for me to choose another option for my casting vote.
+
+Of course, the rules of order for a Finnish association are rather different
+from those used by Debian's TC, so there's no direct relevance to this case.
+
+-- 
+Antti-Juhani Kaijanaho, Jyväskylä, Finland
+http://antti-juhani.kaijanaho.fi/newblog/
+http://www.flickr.com/photos/antti-juhani/
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 20:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 20:12:05 GMT) (full text, mbox, link).

+ +

Message #6834 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Keith Packard <keithp@keithp.com>, 727708@bugs.debian.org
+
Cc: Sam Hartman <hartmans@debian.org>, Bdale Garbee <bdale@gag.com>, + Anthony Towns <aj@erisian.com.au>, secretary@debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 11 Feb 2014 12:09:04 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Tue, Feb 11, 2014 at 11:54:50AM -0800, Keith Packard wrote:
+> Steve Langasek <vorlon@debian.org> writes:
+
+> > If the chair ranked them equally in his ballot, why should he express a
+> > different preference when it comes to the casting vote?
+
+> Oh, the obvious answer -- if the chair's preference didn't end up in the
+> tie, he'd have to explicitly vote from the remaining options.
+
+"Obvious", but wrong.  We use Condorcet to enable fully expressing our
+preferences among all the ballot options, not just our first-choice
+preference.  The chair using a casting vote between two tied options (or
+three, which is the problematic case) is expressing a preference for one
+over the other; if such a preference exists, the non-strategic vote is to
+express this same preference in the original ballot.
+
+The *only* use of a casting vote that is different from the original ballot
+is a strategic one, and we should never allow this.  In the case described,
+the chair should just express the preference between the remaining options
+(perhaps by amending their vote, which is allowed so long as "the outcome
+is in doubt"), in which case the casting vote clause doesn't come into play
+at all.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 20:33:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 20:33:08 GMT) (full text, mbox, link).

+ +

Message #6839 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 11 Feb 2014 21:31:11 +0100
+
+
]] Steve Langasek 
+
+> The *only* use of a casting vote that is different from the original ballot
+> is a strategic one, and we should never allow this.  In the case described,
+> the chair should just express the preference between the remaining options
+> (perhaps by amending their vote, which is allowed so long as "the outcome
+> is in doubt"), in which case the casting vote clause doesn't come into play
+> at all.
+
+The vote might have ran out of time, in which case I believe it's too
+late to change any votes, but not to use the casting vote.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 20:48:03 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Matthias Urlichs <smurf@smurf.noris.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 20:48:04 GMT) (full text, mbox, link).

+ +

Message #6844 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Matthias Urlichs <smurf@smurf.noris.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 11 Feb 2014 21:43:37 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Hi,
+
+Steve Langasek:
+> "Obvious", but wrong.  We use Condorcet to enable fully expressing our
+> preferences among all the ballot options, not just our first-choice
+> preference.  The chair using a casting vote between two tied options (or
+> three, which is the problematic case) is expressing a preference for one
+> over the other; if such a preference exists, the non-strategic vote is to
+> express this same preference in the original ballot.
+> 
+The chair might desire to use their casting vote to select the more popular |
+less controversial | more- (or less-)vocally-supported option, as opposed
+to their personal opinion | preference.
+
+> The *only* use of a casting vote that is different from the original ballot
+> is a strategic one, and we should never allow this.
+
+I disagree.
+
+-- 
+-- Matthias Urlichs
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 21:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 21:06:04 GMT) (full text, mbox, link).

+ +

Message #6849 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 11 Feb 2014 13:03:49 -0800
+
+
Matthias Urlichs <smurf@smurf.noris.de> writes:
+> Steve Langasek:
+
+>> "Obvious", but wrong.  We use Condorcet to enable fully expressing our
+>> preferences among all the ballot options, not just our first-choice
+>> preference.  The chair using a casting vote between two tied options
+>> (or three, which is the problematic case) is expressing a preference
+>> for one over the other; if such a preference exists, the non-strategic
+>> vote is to express this same preference in the original ballot.
+
+> The chair might desire to use their casting vote to select the more
+> popular | less controversial | more- (or less-)vocally-supported option,
+> as opposed to their personal opinion | preference.
+
+Can I suggest that this discussion may be better placed in debian-project?
+The procedural issue is really a concern for the project as a whole, and
+any changes would be constitutional changes and would have to go through
+the project as a whole.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 11 Feb 2014 21:12:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 11 Feb 2014 21:12:10 GMT) (full text, mbox, link).

+ +

Message #6854 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Kurt Roeckx <kurt@roeckx.be>, 727708@bugs.debian.org
+
Cc: Steve Langasek <vorlon@debian.org>, Sam Hartman <hartmans@debian.org>, + Bdale Garbee <bdale@gag.com>, Anthony Towns <aj@erisian.com.au>, + secretary@debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for + jessie
+
Date: Tue, 11 Feb 2014 23:09:18 +0200
+
+
On Tue, Feb 11, 2014 at 08:22:19PM +0100, Kurt Roeckx wrote:
+> On Tue, Feb 11, 2014 at 10:59:34AM -0800, Steve Langasek wrote:
+> > On Tue, Feb 11, 2014 at 12:18:41PM -0500, Sam Hartman wrote:
+> > > >>>>> "Bdale" == Bdale Garbee <bdale@gag.com> writes:
+> > 
+> > >     Bdale> Steve Langasek <vorlon@debian.org> writes:
+> > >     >> FWIW I have always assumed that the casting vote is implicit in
+> > >     >> the chair's ballot.  To require the chair to explicitly exercise
+> > >     >> their casting vote, as opposed to the chair's preferences as
+> > >     >> expressed on the ballot being applied automatically, opens up
+> > >     >> another set of vote gaming strategies that we really shouldn't
+> > >     >> get into.
+> > 
+> > >     Bdale> I would have assumed that, too, but since others did not
+> > >     Bdale> share the assumption, it seemed prudent to be explicit about
+> > >     Bdale> it.
+> > 
+> > > This assumption does not make sense to me in the following cases:
+> > 
+> > > * Chair ranks multiple options equilly
+> > 
+> > If the chair ranked them equally in his ballot, why should he express a
+> > different preference when it comes to the casting vote?
+> 
+> I think the vote should always result in something, and as such
+> the person having the casting vote needs to pick one of the
+> options that are left in the Schwartz set.  If there was no
+> preference between them, a choise will still need to be made.
+> 
+> I've actually been wondering about this issue myself the past few
+> days, and this seems to me the only good reason why the casting
+> vote should be a different vote than the earlier vote.
+
+Somewhere buried in this huge thread I had a discussion with Anthony 
+regarding it, and in my opinion there is another possible good reason:
+
+Assume in Ian's previous combined ballot where voting was aborted the 
+two remaining members would have voted, and both had voted DT > DL > FD.
+
+The result would have been:
+
+DT > FD (5:3)
+DL > FD (8:0)
+DT = DL (4:4)
+
+One can argue that the the chairman should simply pick whatever he 
+personally prefers.
+
+My point here is that the chairman should IMHO at least consider the 
+fact that there is one option that is acceptable for all members, while 
+the other option is vehemently opposed by 3 TC members.
+
+And choosing a generally acceptable option over his personal preference 
+would be a good reason for voting different in the casting vote.[1]
+
+> Kurt
+
+cu
+Adrian
+
+[1] The chairman has no obligation to change his vote in such a case,
+    but if he would there would be a good reason and not just random
+    erratic behaviour.
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 01:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 01:09:04 GMT) (full text, mbox, link).

+ +

Message #6859 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, + 727708@bugs.debian.org, Russ Allbery <rra@debian.org>, + debian-policy@lists.debian.org, + Didier 'OdyX' Raboud <odyx@debian.org>, secretary@debian.org, + leader@debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Wed, 12 Feb 2014 02:05:23 +0100
+
+
On Sat, Feb 08, 2014 at 03:13:36PM -0800, Steve Langasek wrote:
+> 
+> package maintenance is not
+> something that I believe it's in the purview of the DPL to delegate.
+
+I have to agree with this part.  I think this is a power that
+belongs to the developers.
+
+I think that in such delegation the policy editors should be seen
+as upstream, but they might happen to be the same group that does
+the packaging.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 14:09:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 14:09:09 GMT) (full text, mbox, link).

+ +

Message #6864 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Both T and L are wrong, plea for something simpler
+
Date: Wed, 12 Feb 2014 14:05:50 +0000
+
+
On Fri, Feb 07, 2014 at 10:14:23AM -0800, Steve Langasek wrote:
+> On Fri, Feb 07, 2014 at 05:46:15PM +0100, Ansgar Burchardt wrote:
+> > So you suggest to just ignore "In each case the usual maintainer of the
+> > relevant software or documentation makes decisions initially"?
+> 
+> The TC has the authority to set technical policy.  The maintainers are
+> empowered to interpret how that technical policy applies to their particular
+> packages.  And the TC has the power to overrule the maintainers and tell
+> them that their interpretation is incorrect.
+> 
+> But the TC does not have to wait for a maintainer to take a decision they
+> disagree with before they decide the technical policy in the abstract which
+> may affect a maintainer's package.
+> 
+> > If you decide on the init system question first, you could just file a
+> > bug against debian-policy and things could go their usual way.
+> > Alternatively, the Policy maintainers could defer this decision to the
+> > technical committee under 6.1.3.
+> 
+> The Policy maintainers are the maintainers of the policy document, they are
+> not "maintainers of the relevant software" in this context.
+
+I don't interpret "relevant software" to mean the general mass of
+packages in the archive.  In context it follows a list which includes
+"the behaviour of non-experimental package building tools", and the only
+plain reading of that text I can see is:
+
+  relevant software => non-experimental package building tools
+  relevant documentation => technical policy manuals, developers'
+    reference materials, example packages
+
+So I think 6.1.1 requires the policy maintainers to decide or defer
+first.  (But regardless, Russ' statement on this that the policy
+maintainers cannot decide on this given their current process seems
+sufficient to me.)
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 14:09:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 14:09:12 GMT) (full text, mbox, link).

+ +

Message #6869 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: init system coupling etc.
+
Date: Wed, 12 Feb 2014 14:08:16 +0000
+
+
I see that the resolutions I proposed on Sunday have been voted down
+(or are likely to be voted down).  Without the wider scope of the GR
+separately rider (which looks unlikely to pass), my T-vs-L individual
+resolution is actively harmful because it's not GR-overrideable in
+itself so:
+
+FORMAL ACTION: I hereby change my vote on "Init system coupling call
+for votes" to FD.
+
+I still want to vote on L.  If we're not having a separate wide scope
+GR override, we need to add the GR rider to all relevant resolutions.
+
+FORMAL ACTION: I therefore hereby formally propose the following
+resolution ("init system coupling v2"), but do not yet call for votes.
+
+[rationale]
+
+   The default init system decision is limited to selecting a default
+   initsystem for jessie.  We expect that Debian will continue to
+   support multiple init systems for the foreseeable future; we
+   continue to welcome contributions of support for all init systems.
+
+[rubric]
+
+   Therefore, for jessie and later releases, we exercise our power to
+   set technical policy (Constitution 6.1.1):
+
+[loose coupling]
+
+   Software outside of an init system's implementation may not require
+   a specific init system to be pid 1, although degraded operation is
+   tolerable.
+
+   Maintainers are encouraged to accept technically sound patches
+   to enable improved interoperation with various init systems.
+
+[GR rider]
+
+   If the project passes (before the release of jessie) by a General
+   Resolution, a "position statement about issues of the day", on the
+   subject of init systems, the views expressed in that position
+   statement entirely replace the substance of this TC resolution; the
+   TC hereby adopts any such position statement as its own decision.
+
+   Such a position statement could, for example, use these words:
+
+      The Project requests (as a position statement under s4.1.5 of the
+      Constitution) that the TC reconsider, and requests that the TC
+      would instead decide as follows:
+
+I intend to call for votes on this (with whatever amendments anyone
+chooses to propose) at 14:30 UTC on Friday (around 48h from now).  IMO
+there has been plenty of time to try to develop a better wording.
+
+If no-one from the T side has proposed an amendment along the lines of
+T, then I will put the exact wording of the T as currently found in
+git on the ballot too.
+
+As might be expected, I am contemplating proposing and/or sponsoring a
+GR.  Now that the default resolution has passed, a simple majority GR
+has the power to decide init system questions using the TC's powers.
+
+At the moment I think I will definitely do this if:
+
+ * The vote on the proposal above results in FD.  (I think it is
+   important to make a decision on this quickly before "facts on the
+   ground" are established to make this more difficult; the passage of
+   the default resolution makes that urgent.)
+
+ * Anyone in the TC Calls for Votes on a proposal I consider related
+   to the coupling question without giving me an opportunity to
+   propose an alternative text as an amendment.  In this case I would
+   propose a GR immediately.
+
+ * Anyone in the TC Calls for Votes on any proposal related to init
+   systems, without giving me an opportunity to propose an alternative
+   text as an amendment, in a manner I consider prejudicial.
+
+If the TC's conclusion on the coupling question is IMO not
+sufficiently robust I will probably canvass opinions before deciding
+whether to propose a GR.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 16:45:16 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 16:45:16 GMT) (full text, mbox, link).

+ +

Message #6874 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Init system Call for Votes, Ian's drafts
+
Date: Wed, 12 Feb 2014 08:42:53 -0800
+
+
On Sun, 09 Feb 2014, Ian Jackson wrote:
+> I hereby propose the L versions from git:
+> 
+>   == dependencies rider version L (Loose coupling) ==
+> 
+>      Software outside of an init system's implementation may not require
+>      a specific init system to be pid 1, although degraded operation is
+>      tolerable.
+> 
+>      Maintainers are encouraged to accept technically sound patches
+>      to enable improved interoperation with various init systems.
+> 
+> as amendments to my own formal proposal, and do not accept them.
+> 
+> I hereby call for votes on my own formal proposal.
+
+I vote FD over all other options in this CFV.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+We have to face the fact that either all of us are going to die
+together or we are going to learn to live together and if we are to
+live together we have to talk. 
+ -- Eleanor Roosevelt
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 17:12:26 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Lucas Nussbaum <lucas@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 17:12:26 GMT) (full text, mbox, link).

+ +

Message #6879 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Lucas Nussbaum <lucas@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 12 Feb 2014 18:09:38 +0100
+
+
Hi,
+
+I must admit that I only followed this part of the discussion from a
+distance.
+
+However, one thing really strikes me:
+
+On 12/02/14 at 14:08 +0000, Ian Jackson wrote:
+> [loose coupling]
+> 
+>    Software outside of an init system's implementation may not require
+>    a specific init system to be pid 1, although degraded operation is
+>    tolerable.
+
+This is super vague. What does being "outside of an init system's
+implementation" mean? What does "degraded operation" mean?
+
+If you really want to have that discussion now, rather than wait for
+actual, concrete problems to discuss, I'd suggest that you build a few
+hypothetical scenarios, and discuss them. And then build a resolution
+that represents the aggregated opinions on those few hypothetical
+scenarios.
+
+But I also don't really understand why there's a particular urgency
+for the TC to rule on that. Are there packages with tight coupling
+already in the archive?
+
+Lucas
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 17:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 17:27:04 GMT) (full text, mbox, link).

+ +

Message #6884 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 12 Feb 2014 09:24:30 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> [loose coupling]
+>
+>    Software outside of an init system's implementation may not require
+>    a specific init system to be pid 1, although degraded operation is
+>    tolerable.
+>
+>    Maintainers are encouraged to accept technically sound patches
+>    to enable improved interoperation with various init systems.
+
+I agree with you that this is an important issue which needs to be
+resolved within the Debian project. I also want to make it clear that I
+support the goal of having the project provide a clear policy statement
+about this issue in the short term.
+
+The discussions held within the context of the default init bug were
+fruitful, and without rancor, which makes me hopeful that the project
+membership can drive this issue to consensus in the near future through
+the usual policy editing process. As such I'd like to amend this
+proposed ballot with an additional option:
+
+ * The TC chooses to not pass a resolution on this issue at the current time.
+
+This is different from FD as it says the TC will not continue
+discussions on this issue, although it could well restart them if the
+people involved in the policy editing process come to an impasse. It's
+also different from 'T' in that it will allow us to revisit this in the
+future without needing to overturn a previous decision.
+
+I understand your desire to forestall potential future conflict by
+proactively voting this issue, but given the progress already made, I
+don't feel like the TC needs to step in now.
+
+Thank you for your consideration.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 18:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 18:00:04 GMT) (full text, mbox, link).

+ +

Message #6889 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 12 Feb 2014 09:56:42 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> FORMAL ACTION: I therefore hereby formally propose the following
+> resolution ("init system coupling v2"), but do not yet call for votes.
+
+> [rationale]
+
+>    The default init system decision is limited to selecting a default
+>    initsystem for jessie.  We expect that Debian will continue to
+>    support multiple init systems for the foreseeable future; we
+>    continue to welcome contributions of support for all init systems.
+
+> [rubric]
+
+>    Therefore, for jessie and later releases, we exercise our power to
+>    set technical policy (Constitution 6.1.1):
+
+> [loose coupling]
+
+>    Software outside of an init system's implementation may not require
+>    a specific init system to be pid 1, although degraded operation is
+>    tolerable.
+
+>    Maintainers are encouraged to accept technically sound patches
+>    to enable improved interoperation with various init systems.
+
+> [GR rider]
+
+>    If the project passes (before the release of jessie) by a General
+>    Resolution, a "position statement about issues of the day", on the
+>    subject of init systems, the views expressed in that position
+>    statement entirely replace the substance of this TC resolution; the
+>    TC hereby adopts any such position statement as its own decision.
+
+>    Such a position statement could, for example, use these words:
+
+>       The Project requests (as a position statement under s4.1.5 of the
+>       Constitution) that the TC reconsider, and requests that the TC
+>       would instead decide as follows:
+
+I propose the following text as an amendment to this option.  It would
+replace this text in its entirety, including the [GR rider] section.  (I
+don't see any need for or purpose served by cancelling technical advice to
+the project based on a GR outcome.  All the members of the project are, I
+think, capable of using their own judgement to resolve technical advice
+with the substance of a GR, and technical advice is by definition not
+binding.  Plus, I think this is a basically sensible thing to say
+regardless of the chosen init system.)
+
+Please note that I personally am currently leaning towards voting Keith's
+proposal above the one that I'm proposing in this message for the reasons
+that he states in that message.  But I think it's useful to have a
+statement on the ballot so that it can be ranked, since it may be a
+compromise position between deferring to the Policy process and Ian's
+proposal.
+
+    The following is technical advice offered to the project by the
+    Technical Committee under section 6.1.5 of the constitution.  It does
+    not constitute an override of maintainer decisions past or future:
+
+    Packages should normally support the default Linux init system.  There
+    are some exceptional cases where lack of support for the default init
+    system may be appropriate, such as alternative init system
+    implementations, special-use packages such as managers for non-default
+    init systems, and cooperating groups of packages intended for use with
+    non-default init systems.  However, package maintainers should be
+    aware that a requirement for a non-default init system will mean the
+    package will be unusable for most Debian users and should normally be
+    avoided.
+
+    Package maintainers are strongly encouraged to merge any contributions
+    for support of init systems other than the Linux default, and to add
+    that support themselves if they're willing and capable of doing so.
+    In particular, package maintainers should put a high priority on
+    merging changes to support any init system which is the default on one
+    of Debian's non-Linux ports.
+
+    For the jessie release, all packages that currently support being run
+    under sysvinit should continue to support sysvinit unless there is no
+    technically feasible way to do so.  Reasonable changes to preserve or
+    improve sysvinit support should be accepted through the jessie
+    release.  There may be some loss of functionality under sysvinit if
+    that loss is considered acceptable by the package maintainer and the
+    package is still basically functional.  All packages should support
+    smooth upgrades from wheezy to jessie, including upgrades done on a
+    system booted with sysvinit.
+
+    The Technical Committee offers no advice at this time on requirements
+    or package dependencies on specific init systems after the jessie
+    release.  There are too many variables at this point to know what the
+    correct course of action will be.
+
+I'm also happy to consider amendments to this text along the lines of
+Steve's proposed language elsewhere in the thread.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 19:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 19:03:04 GMT) (full text, mbox, link).

+ +

Message #6894 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 12 Feb 2014 11:00:29 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Russ Allbery <rra@debian.org> writes:
+
+>     The following is technical advice offered to the project by the
+>     Technical Committee under section 6.1.5 of the constitution.  It does
+>     not constitute an override of maintainer decisions past or future:
+
+Thanks for making this clear -- operating under §6.1.5 means that this
+doesn't conflict with §6.3.6 as it is not a decision.
+
+I remain unsure about how §6.3.5 should inform this process; there's a
+fuzzy line between 'advice' and 'design', and I just don't know where
+this particular text falls.
+
+I do like the sentiments expressed in the text though, and I hope we'll
+see broad consensus form around something akin to it.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 19:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 19:33:04 GMT) (full text, mbox, link).

+ +

Message #6899 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 12 Feb 2014 21:29:48 +0200
+
+
On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote:
+>...
+>     All packages should support
+>     smooth upgrades from wheezy to jessie, including upgrades done on a
+>     system booted with sysvinit.
+>...
+
+This sounds like a statement by the TC that smooth upgrades from wheezy 
+to jessie will only be optional and that it is OK[1] for a package to
+not support that.
+
+Debian has a pretty good reputation for smooth upgrades, so any
+statement that weakens this default is a pretty strong message.
+
+cu
+Adrian
+
+[1] at least not RC-buggy, which would otherwise be the default
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 19:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 19:36:04 GMT) (full text, mbox, link).

+ +

Message #6904 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 12 Feb 2014 11:35:11 -0800
+
+
Adrian Bunk <bunk@stusta.de> writes:
+> On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote:
+
+>>...
+>>     All packages should support
+>>     smooth upgrades from wheezy to jessie, including upgrades done on a
+>>     system booted with sysvinit.
+>>...
+
+> This sounds like a statement by the TC that smooth upgrades from wheezy
+> to jessie will only be optional and that it is OK[1] for a package to
+> not support that.
+
+Three observations to that:
+
+* This is technical advice.  I think it is inappropriate to use wording
+  stronger than "should" in technical advice.
+
+* This is explicitly not a maintainer override of anyone, which obviously
+  includes the release team (even assuming that the TC could override the
+  release team, which I don't believe it can given that the release team's
+  authority flows from the DPL via delegation).  The release team sets the
+  policy for RC bugs, not the TC.
+
+* This is technical advice, not technical policy, and therefore obviously
+  does not override what Policy already says.
+
+If there is an alternative wording that fits those constraints that people
+would prefer, I'm certainly happy to consider it for incorporation into my
+proposed amendment.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 19:45:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sam Hartman <hartmans@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 19:45:07 GMT) (full text, mbox, link).

+ +

Message #6909 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sam Hartman <hartmans@debian.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 12 Feb 2014 14:40:40 -0500
+
+
When I've found myself trying to avoid normative language  in situations
+like this I end up with statements like:
+
+It is important that all packages support smoothe upgrades from Wheezy
+to Jessie , even when the system is booted with sysvinit.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 19:45:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Brandon <raisonbran648@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 19:45:11 GMT) (full text, mbox, link).

+ +

Message #6914 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Brandon <raisonbran648@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: SystemD
+
Date: Wed, 12 Feb 2014 14:43:08 -0500
+
+
[Message part 1 (text/plain, inline)]
+
I have been a long time debian user. Please do not implement systemd. I
+don't want to switch to another OS but I will.
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 19:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Matthias Urlichs <matthias@urlichs.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 19:51:04 GMT) (full text, mbox, link).

+ +

Message #6919 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Matthias Urlichs <matthias@urlichs.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 12 Feb 2014 20:47:33 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Hi,
+
+> >>...
+> >>     All packages should support
+> >>     smooth upgrades from wheezy to jessie, including upgrades done on a
+> >>     system booted with sysvinit.
+> >>...
+> 
+> If there is an alternative wording that fits those constraints that people
+> would prefer, I'm certainly happy to consider it for incorporation into my
+> proposed amendment.
+> 
+How about 
+
+Policy (cite §§?) mandates that all packages support smooth upgrades from
+wheezy to jessie. This should apply regardless of which init system is
+running at the time of upgrade.
+
+> 
+-- 
+-- Matthias Urlichs
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 19:57:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Matthias Urlichs <matthias@urlichs.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 19:57:05 GMT) (full text, mbox, link).

+ +

Message #6924 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Matthias Urlichs <matthias@urlichs.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: SystemD
+
Date: Wed, 12 Feb 2014 20:52:37 +0100
+
+
[Message part 1 (text/plain, inline)]
+
Hi,
+
+Brandon:
+> I have been a long time debian user. Please do not implement systemd. I
+> don't want to switch to another OS but I will.
+
+So?
+
+*I* will switch to another OS if Debian decides _not_ to switch to systemd.
+
+:-P
+
+Can we move on please? Anybody who does not like this choice has had ample
+opportunity to voice their opinion. So did everybody who does, for that
+matter. Jessie is less than a year from release and, now that this one is
+decided, there are higher-priority bugs to work on.
+
+-- 
+-- Matthias Urlichs
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 20:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steven Chamberlain <steven@pyro.eu.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 20:15:04 GMT) (full text, mbox, link).

+ +

Message #6929 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steven Chamberlain <steven@pyro.eu.org>
+
To: Brandon <raisonbran648@gmail.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: SystemD
+
Date: Wed, 12 Feb 2014 20:11:22 +0000
+
+
On 12/02/14 19:43, Brandon wrote:
+> I have been a long time debian user. Please do not implement systemd. I
+> don't want to switch to another OS but I will.
+
+For the jessie release, it should be possible to uninstall systemd on
+GNU/Linux and still have most functionality.  The non-Linux ports are
+likely going to work that way, which means the init scripts will have
+been already tested for this.
+
+Regards,
+-- 
+Steven Chamberlain
+steven@pyro.eu.org
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 20:57:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 20:57:05 GMT) (full text, mbox, link).

+ +

Message #6934 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 12 Feb 2014 22:52:46 +0200
+
+
On Wed, Feb 12, 2014 at 11:35:11AM -0800, Russ Allbery wrote:
+> Adrian Bunk <bunk@stusta.de> writes:
+> > On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote:
+> 
+> >>...
+> >>     All packages should support
+> >>     smooth upgrades from wheezy to jessie, including upgrades done on a
+> >>     system booted with sysvinit.
+> >>...
+> 
+> > This sounds like a statement by the TC that smooth upgrades from wheezy
+> > to jessie will only be optional and that it is OK[1] for a package to
+> > not support that.
+> 
+> Three observations to that:
+> 
+> * This is technical advice.  I think it is inappropriate to use wording
+>   stronger than "should" in technical advice.
+> 
+> * This is explicitly not a maintainer override of anyone, which obviously
+>   includes the release team (even assuming that the TC could override the
+>   release team, which I don't believe it can given that the release team's
+>   authority flows from the DPL via delegation).  The release team sets the
+>   policy for RC bugs, not the TC.
+> 
+> * This is technical advice, not technical policy, and therefore obviously
+>   does not override what Policy already says.
+> 
+> If there is an alternative wording that fits those constraints that people
+> would prefer, I'm certainly happy to consider it for incorporation into my
+> proposed amendment.
+
+  The general rule that all packages have to support upgrades from 
+  the previous stable release should not be changed. Neither should
+  it be amended to make exceptions depending on which init system was
+  booted at the time of the upgrade.
+
+
+cu
+Adrian
+
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 21:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Adrian Bunk <bunk@stusta.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 21:33:04 GMT) (full text, mbox, link).

+ +

Message #6939 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Adrian Bunk <bunk@stusta.de>
+
To: Lucas Nussbaum <lucas@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 12 Feb 2014 23:30:42 +0200
+
+
On Wed, Feb 12, 2014 at 06:09:38PM +0100, Lucas Nussbaum wrote:
+> Hi,
+> 
+> I must admit that I only followed this part of the discussion from a
+> distance.
+> 
+> However, one thing really strikes me:
+> 
+> On 12/02/14 at 14:08 +0000, Ian Jackson wrote:
+> > [loose coupling]
+> > 
+> >    Software outside of an init system's implementation may not require
+> >    a specific init system to be pid 1, although degraded operation is
+> >    tolerable.
+> 
+> This is super vague. What does being "outside of an init system's
+> implementation" mean? What does "degraded operation" mean?
+> 
+> If you really want to have that discussion now, rather than wait for
+> actual, concrete problems to discuss, I'd suggest that you build a few
+> hypothetical scenarios, and discuss them. And then build a resolution
+> that represents the aggregated opinions on those few hypothetical
+> scenarios.
+> 
+> But I also don't really understand why there's a particular urgency
+> for the TC to rule on that. Are there packages with tight coupling
+> already in the archive?
+
+One of the Debian GNOME maintainers has stated in this discussion[1]:
+
+  But there are no realistic solutions for having GNOME support multiple 
+  init systems in jessie.
+
+Whether that's actually true is another question, but a maintainer 
+speaking like this clearly shows that it is not only a theoretical
+question.
+
+
+Another reason for urgency is that there was actually consensus
+in the TC that Debian should multiple init systems.[2] That was
+completely lost in all the "Debian chooses systemd" headlines that
+followed a widely published resolution that was only about the default 
+and didn't cover that aspect.
+
+Or perhaps that's no longer urgent, since the "Debian chooses systemd"
+headlines are already in everyone's head, and a later statement
+"but we also support other init systems" would anyway not make it
+into the news.
+
+
+> Lucas
+
+cu
+Adrian
+
+[1] https://lists.debian.org/debian-ctte/2014/01/msg00550.html
+[2] the dispute in the TC was about whether depedencies on a specific 
+    init system should be allowed - that in general multiple init 
+    systems should be supported was consensus among TC members
+
+-- 
+
+       "Is there not promise of rain?" Ling Tan asked suddenly out
+        of the darkness. There had been need of rain for many days.
+       "Only a promise," Lao Er said.
+                                       Pearl S. Buck - Dragon Seed
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 22:39:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 22:39:08 GMT) (full text, mbox, link).

+ +

Message #6944 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 12 Feb 2014 22:35:12 +0000
+
+
Lucas Nussbaum writes ("Bug#727708: init system coupling etc."):
+> I must admit that I only followed this part of the discussion from a
+> distance.
+
+Fair enough.
+
+> On 12/02/14 at 14:08 +0000, Ian Jackson wrote:
+> > [loose coupling]
+> > 
+> >    Software outside of an init system's implementation may not require
+> >    a specific init system to be pid 1, although degraded operation is
+> >    tolerable.
+> 
+> This is super vague. What does being "outside of an init system's
+> implementation" mean? What does "degraded operation" mean?
+
+Yes.  I agree that it's vague.  I'm open to better and clearer
+suggestions.  When I wrote this I was hoping that the policy process
+would be able to refine the details but perhaps that's overoptimistic.
+
+I'm also open to suggestions that we should extend the discussion
+period to facilitate improvements to this and other options.  How long
+do people think we need ?
+
+(I'll deal with the rest of your mail later.)
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 23:27:34 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Sjoerd Simons <sjoerd@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 23:27:34 GMT) (full text, mbox, link).

+ +

Message #6949 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Sjoerd Simons <sjoerd@debian.org>
+
To: Adrian Bunk <bunk@stusta.de>, 727708@bugs.debian.org
+
Cc: Lucas Nussbaum <lucas@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 00:16:01 +0100
+
+
On Wed, 2014-02-12 at 23:30 +0200, Adrian Bunk wrote:
+> On Wed, Feb 12, 2014 at 06:09:38PM +0100, Lucas Nussbaum wrote:
+> > Hi,
+> > 
+> > I must admit that I only followed this part of the discussion from a
+> > distance.
+> > 
+> > However, one thing really strikes me:
+> > 
+> > On 12/02/14 at 14:08 +0000, Ian Jackson wrote:
+> > > [loose coupling]
+> > > 
+> > >    Software outside of an init system's implementation may not require
+> > >    a specific init system to be pid 1, although degraded operation is
+> > >    tolerable.
+> > 
+> > This is super vague. What does being "outside of an init system's
+> > implementation" mean? What does "degraded operation" mean?
+> > 
+> > If you really want to have that discussion now, rather than wait for
+> > actual, concrete problems to discuss, I'd suggest that you build a few
+> > hypothetical scenarios, and discuss them. And then build a resolution
+> > that represents the aggregated opinions on those few hypothetical
+> > scenarios.
+> > 
+> > But I also don't really understand why there's a particular urgency
+> > for the TC to rule on that. Are there packages with tight coupling
+> > already in the archive?
+> 
+> One of the Debian GNOME maintainers has stated in this discussion[1]:
+> 
+>   But there are no realistic solutions for having GNOME support multiple 
+>   init systems in jessie.
+> 
+> Whether that's actually true is another question, but a maintainer 
+> speaking like this clearly shows that it is not only a theoretical
+> question.
+
+Please don't quote people out of context. The problem with quoting lines
+like that is that "support" means different things to different people.
+
+The definition of "support" has two extremes:
+  * Fully functional, all features work as they should etc.
+  * Degraded but functional, It's usable but some functionality might
+    not work, errors may show up in some places etc.
+
+Re-reading Joss' mail i can only assume with support he means the former
+option. However lets not make this about rehashing the mail of one of my
+fellow GNOME maintainers.
+
+So for some less hypothetical, more practical considerations:
+
+As long as there is a logind implementations available in Debian which
+works with non-systemd, Gnome can depend on that as an alternative to
+the systemd provided version and it should be possible to at least
+support degraded mode for other init system for the foreseeable future.
+
+As things stand, there seems to be more then enough motivation to ensure
+an implementation of the logind interfaces is available for use on
+non-systemd even when the systemd package get moved to a newer version
+and it's own implementation does not support that anymore. In which case
+we can add an alternate dependency on an alternate logind implementation
+for gnome.
+
+Ofcourse the more complete the alternative implementations are of the
+systemd services are, the better the Gnome experience can be for those
+choosing gnome but not systemd. For example systemd-shim seems to be an
+effort in this direction.
+
+
+None of this is rocket science and none of this requires a pre-emptive
+resolution on the TC side to decide what dependencies are generally
+allowed (which probably would do more harm then good). Advise, is
+ofcourse always welcome, but lets try and solve technical problems with
+technical solutions rather then politics as in the end that's what we
+tend to do best.
+
+> Another reason for urgency is that there was actually consensus
+> in the TC that Debian should multiple init systems.[2] That was
+> completely lost in all the "Debian chooses systemd" headlines that
+> followed a widely published resolution that was only about the default 
+> and didn't cover that aspect.
+> 
+> Or perhaps that's no longer urgent, since the "Debian chooses systemd"
+> headlines are already in everyone's head, and a later statement
+> "but we also support other init systems" would anyway not make it
+> into the news.
+
+I think for all of us that actually had a stake in this discussion, it
+has been more then painful enough so I doubt we'll forget that aspect.
+If you're aiming for headlines, i doubt re-affirming support for
+multiple systems will make much of a dent there.
+
+
+-- 
+Sjoerd Simons <sjoerd@debian.org>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 12 Feb 2014 23:33:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Richard Hartmann <richih.mailinglist@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 12 Feb 2014 23:33:08 GMT) (full text, mbox, link).

+ +

Message #6954 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Richard Hartmann <richih.mailinglist@gmail.com>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 00:27:40 +0100
+
+
On Wed, Feb 12, 2014 at 6:56 PM, Russ Allbery <rra@debian.org> wrote:
+
+> Please note that I personally am currently leaning towards voting Keith's
+> proposal above the one that I'm proposing in this message for the reasons
+> that he states in that message.
+
+Given the overall heat in the prior debate, I can see value in basic
+guidance without forcing anybody's hand. As Ian notes, these are
+exceptional times.
+
+
+> I'm also happy to consider amendments to this text along the lines of
+> Steve's proposed language elsewhere in the thread.
+
+I think Sam had a worthwhile idea: Avoid normative language in
+preference of observative language. To quote Debian's favorite card
+game: "It has been observed that..."
+
+
+  Under section 6.1.5 of the Debian Constitution, the Technical Committee
+  observes the following:
+
+  Having a default init system means that all normal packages support
+  it. Packages with a very specific purpose can deviate from this.
+  Examples include alternative init system implementations,
+  special-use packages such as managers for non-default init systems,
+  and cooperating groups of packages intended for use with non-default
+  init systems.
+  Packages lacking support for the default init system may be unusable
+  on most Debian systems, thus limiting their adoption.
+
+  Debian tries to offer choice whenever possible. Choice can be increased
+  by adding or maintaining support for alternate init systems. Two
+  possible ways for package maintainers to achieve this goal are to
+  implement support themselves, or to apply patches provided to them.
+  It is important that platform-independent packages support all default
+  init systems on all Debian platforms.
+
+  Smooth upgrades from stable to stable+1 are rightfully expected by
+  Debian users. For upgrading from wheezy to jessie in particular,
+  upgrades with both the old and new default init system running need
+  to work. One good way to ensure smooth upgrades is to maintain and
+  improve sysvinit support over the jessie lifecycle.
+  sysvinit may not support all features of the default init system.
+  This could result in degraded operation of some packages. Working
+  around or fixing this degradation provides a benefit to Debian users.
+
+  jessie+1 is too far into the future to make useful observations about
+  future requirements or package dependencies on specific init systems
+  today.
+
+
+Notes:
+* I am unhappy with the tautology in the beginning; it reads very much
+like "the default is the default"
+* Russ' text reads generally smoother, my version is more cumbersome
+* I deliberately avoided calling the default system by name, same as Russ
+* You are more than welcome to use, re-use, or discard all of this; if
+it's useful: good. If not, please simply ignore to keep S/N ratio high
+
+
+Thanks,
+Richard
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 01:27:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to "John Mist" <johndebian@secure-mail.cc>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 01:27:12 GMT) (full text, mbox, link).

+ +

Message #6959 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "John Mist" <johndebian@secure-mail.cc>
+
To: <727708@bugs.debian.org>
+
Subject: Bug#727708: non-technical reasons
+
Date: Thu, 13 Feb 2014 01:10:58 +0000
+
+
Obviously, then making technical decision one must realize the field
+we must work in near future. So we need to make at least
+draft analysis of the current situation.
+
+Strongest aspects of Debian that outperforms every other distro:
+
+1) It's universal operating system. In minimal installation it is stays
+really small in both disk and memory requirements.
+
+2) It's really fast and effective.
+
+3) It fully controllable by moderate specialist. It does exactly and
+only what you want and then you want.
+
+4) Debian core is perfect at its stability. Non-core packet is quite
+stable too.
+
+5) Therefore, it is a best base to build effective, robust and
+really secure systems on it.
+
+6) It's clearly the best system for small-sized
+systems such as web-servers:
+http://w3techs.com/technologies/details/os-linux/all/all
+
+6) I believe Debian and its huge and thoroughly tested packet base is the
+best starting point for complicated non-standard setups attuned for
+individual customer needs.
+
+7) It is rather conservative in tools of managing of the system. This
+helps to teach new things and to move further than study how to do the
+same things in new system every couple of years.
+
+8) It's best of all distros in freedom of choices how you want things
+to be done. At least for skilled people.
+
+The weaknesses of Debian:
+
+1) Lack of full-time developers of distro itself.
+We cannot change big things fast. We cannot change things frequently.
+
+2) We don't have much major upstream developers of core Linux components.
+We cannot influence driving path of Linux itself much.
+
+3) Lack of paid "official" commonly-trusted technical support with
+close connection with major Debian developers.
+Customers don't have a telephone number which they can call and all
+things magically "start to work".
+
+What happens in Linux world today:
+
+Red Hat is commercial company. They are making money. To make money
+they must have high prices. To have prices much higher than real cost
+of service a company must be alone on the market segment.
+But last years we see trends as Red Hat is have been slowly but
+continuously squeezed out from the leader in Linux support and
+distribution.
+
+I think it happens due to 2 tendencies:
+
+1) Aggressive marketing of Ubuntu. Many new Linux-people familiar with
+Ubuntu, but not Red Hat family of distros.
+
+2) Steady growing of number of high-class Linux specialists. It's easy now
+to find really good professional to build custom system with almost any
+degree of complexity. And these specialists mostly prefer Debian as it
+more transparent, simple, flexible and small-component-driven than
+Red Hat and family.
+At the same time it's robust and fast at least as Red Hat if not more.
+
+That powers have Red Hat to change the situation:
+
+1) They have strong reputation as leader of Open Source. Many years they
+helped to make Linux to become best operating system ever.
+
+2) They have great influence on many key developers of Linux ecosystem.
+
+3) They have outstanding respectfulness and trust credit from
+Open Source community.
+
+What Red Had can do:
+
+1) They can change Linux kernel developing scheme so that Red Hat kernel
+will somehow has features that not so fast spread to other distros.
+In fact they did so in limited form, but Linux kernel already so feature
+rich that bleeding-edge kernel features not any critical to most of
+users.
+
+2) They can circumvent the GNU/Linux infrastructure so they can fully
+control it and any concurrent must be in the wake of Red Had innovations.
+Automatically, every distro become either Red Had clone in many aspects or
+become geek-only. - I believe this is that happening now.
+
+They developing and hard pushing a product that changes all the way the
+system works. The product absorbs more and more system services from
+booting and starting services to even user authorization and logging.
+Clearly, it makes the system less robust and less secure:
+http://ewontfix.com/14/
+
+This is really bad for everybody except Red Hat. They have all systemd
+specialists in the company. If you have RH support - you welcome, all you
+problems with systemd will be solved fast. If you have non-supported
+configuration - just pay more.
+
+If you have some other distro and even non-standard configuration,
+you're on your own. I mean all of Debian users.
+We are always welcome to patch systemd and send patches to a company,
+that created trouble for us.
+
+Yes, probably 95% will never face the problems that somebody already
+not solved. But I'm talking about specialists that making complicated
+non-standard systems out of Debian.
+
+Even on small and simple web-servers systemd and it additional services
+will cause growing of memory footprint of the system, kicking Debian
+out of low-end VPS'es exactly as CentOS now. Yes, providers will offer
+VPS'es with more memory, but Debian will lose one of its big advantages
+over Red Had family.
+
+At any rate, if systemd continues to absorb system level tasks,
+diversity between distributives become only cosmetic. But why need
+other distributives with minor differencies if we already have the
+leader among them: Red Hat?
+
+In such a situation Debian probably will cease to exist.
+Or it will try to make really different distro almost from scratch.
+But it will be much harder to make it from scratch instead of
+trying to not loose control over ecosystem now.
+
+I believe, choice systemd as default init system will slowly make
+Debian one of many and eventually destroy it.
+
+Regards,
+J
+
+
+______________________________________________________
+powered by Secure-Mail.biz - anonymous and secure e-mail accounts.
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 01:48:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 01:48:05 GMT) (full text, mbox, link).

+ +

Message #6964 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: non-technical reasons
+
Date: Wed, 12 Feb 2014 17:43:59 -0800
+
+
Yes, that would be the Red Hat conspiracy theory that I was referring to
+as toxic when I was arguing against the similar Canonical conspiracy.
+
+Incidentally, you may want to know that the supposedly awful stability
+regression involving re-exec on upgrade mentioned in that blog post about
+systemd is how sysvinit works today.  That would be one of the lesser
+inaccuracies of that essay.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 09:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Christian Seiler <christian@iwakd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 09:27:04 GMT) (full text, mbox, link).

+ +

Message #6969 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Christian Seiler <christian@iwakd.de>
+
To: 727708@bugs.debian.org
+
Cc: ijackson@chiark.greenend.org.uk
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 10:20:19 +0100
+
+
Hi there,
+
+Preface: I'm not involved with the Debian project directly other than as
+a user. So while I personally have strong opinions when it comes to the
+init system, so far I have just followed the debate because I didn't
+feel it would be helpful to spam this bug with useless comments. That
+said, I have thought about the coupling issue for quite a while now and
+I firmly believe that the original L and T options are BOTH explicitly
+harmful (in different ways). For this reason, I feel the need to express
+my opinion on this subject. But after I have said my piece, unless there
+is a need for clarification on my side, I will walk back to the
+sidelines and continue to watch.
+
+
+
+First of all, I do think there are legitimate concerns that lead to both
+the T and L options. On the one hand, the L text is clearly motivated by
+the worry that if a huge part of the Debian ecosystem (*cough* GNOME
+*cough*) suddenly depends on a specific init system (*cough* systemd
+*cough*) then the commitment to multiple init systems gets reduced to a
+farce. People might disagree about whether this is in reality going to
+become a problem, but I think the concern is legitimate. On the other
+hand, the T text seems to be motivated by the wish to not hamper
+progress when it comes to software, that the Debian project should not
+hold software back because of some ideological reasons.
+
+
+That said, I think both texts are problematic: L being far to extreme in
+its scope and T being far too toothless in the side sentence about
+"encouragement" when it comes to support for other init systems.
+
+
+The problem I have in this discussion is that only a few cases have been
+picked apart in detail, but the wider implications of these options have
+been mentioned in passing at best. So for this reason, I'd like to
+propose several different scenarios where the coupling question applies,
+so that the consequences of language used in the coupling question
+becomes clear. So let me draw up a couple of scenarios:
+
+
+
+(A) Someone writes a GUI for managing systemd that has the goal of
+providing access to as many features as possible, so that it really is
+tightly coupled to systemd in that sense. There is no way this could
+realistically be ported to other init systems. (Although a different
+software for e.g. upstart could be affected in the same way.)
+
+
+(B) Someone writes a GUI for accessing journald files on the hard drive.
+
+
+(C) Someone writes some kind of framework that depends on advanced
+systemd features, such as systemd-nspawn, to provide a novel technical
+solution. This software is new and not yet widely adopted. (Somewhere in
+the original discussion before all of the ballots, somebody mentioned
+something akin to this, I just don't feel it makes sense to invest the
+time to dig that up.)
+
+
+(D) Someone writes a daemon that currently only works with systemd, but
+a patch for including sysvinit and upstrart support is literally only 5
+lines of code.
+
+
+(E) GNOME depends on logind interfaces and there is not working
+alternative logind (>=205) implementation available.
+
+
+(F) GNOME depends on logind interfaces and somebody stepped up and
+created a logind implementation for other init systems.
+
+
+(G) GNOME starts to depend on systemd as pid1 irrespective of logind.
+
+
+(H) Some software part of the default install set (which currently does
+not include GNOME but might again in the future) depends on systemd as
+PID1, either directly (see G) or indirectly via logind with no
+alternative implementation (see E).
+
+
+
+I think that both "L" and "T" options have undesirable consequences. (To
+clarify: I consider some of these to be undesirable for Jessie, not
+necessarily for later releases.)
+
+Let me start with "T":
+
+ - Most serious case (H): If any software in the default install set
+   depends on systemd, then this IMHO creates the de-facto situation
+   that there really only is systemd support. Because if you can't
+   switch the init system if you have a default set of software
+   installed, saying that you support multiple init systems is a farce.
+
+   Therefore, I definitely think that any resolution by the TC should
+   include language that says that any software in the default install
+   set should work with ALL supported init systems (with degraded
+   operation being possible).
+
+   So in the case of GNOME, if it continues to depend on logind (likely)
+   and there doesn't happen to be a logind implementation that works
+   with all the other init systems (unknown), then that should
+   definitely disqualify GNOME from being made default desktop again.
+   (OTOH, if there IS an alternative logind implementation at the point
+   where this is decided, this doesn't stand in the way of GNOME
+   becoming the default desktop again, but obviously it will also not
+   make GNOME automatically the default desktop, that will depend on
+   other things. ;-))
+
+ - Case (G): I don't think this is likely to happen for Jessie, but I
+   do think this should be addressed. Since GNOME is one of the major
+   desktops used by Debian users, I do see its position different from
+   new, unadopted software. GNOME has a certain "market power", so if
+   it starts depending on a specific init system (and by that I DON'T
+   mean logind-type dependencies, I really mean explicit ones), I can
+   understand why people feel that things are "forced upon" them. So I
+   think this case should be avoided, at least for Jessie. Consider
+   this akin to some kind of "antitrust law", i.e. if Debian is serious
+   about commitment to multiple init systems for Jessie, a piece of
+   software as major as GNOME should not depend *directly* on a single
+   init system. (Transitive dependencies aka logind are a different
+   story IMHO.)
+
+ - Case (D): The "T" text encourages maintainers to include support for
+   other init systems, but you could imagine a stubborn maintainer that
+   refuses to even include a patch as trivial as described in that
+   scenario. For this reason, I think the language could be made
+   stronger at this point. But read my critique of "L" first, why I
+   don't consider myself a supporter of "L" here, I just think that
+   for this specific case, where support really is absolutely trivial,
+   I think that stronger language might be needed. OTOH, you could argue
+   that for these cases, the TC could override stubborn maintainers, so
+   the encouragement might be enough to set a general policy.
+
+ - Case (B): In that specific case, I actually think this is the same as
+   case (D). Just because it reads journal files and has a nice GUI, I
+   don't see any technical reason for the software to require systemd as
+   PID1 (just that there won't be any new journal files generated in
+   that case), and actually having something that reads journal files
+   even on systems booted with another init might really be useful. [1]
+
+
+Now to the things I don't like about "L":
+
+
+ - Case (A): This is one of the cases where I see "L" as the most
+   harmful: Somebody writes a tool that improves upon a given init
+   system, but is not part of it (as such, not falling under the
+   exception made in "L"), and that can't be included in Debian.
+   You might argue that it does indeed fall under the exception,
+   but I don't see how you could think that, unless it is officially
+   adopted by the systemd devs. This could actually lead to the really
+   perverse situation that systemd is the default init, but the TC
+   decides to forbid the inclusion of tools that make life with the
+   default init easier for system administrators.
+
+ - Case (C): Again, here I think "L" is actively harmful. Somebody
+   writing a NEW piece of software that makes use of systemd's
+   facilities to provide a new, awesome (in the author's eyes at least
+   ;-)) technical solution to some problem, and then Debian saying that
+   it's policy forbids to include it, because it might force people
+   into using systemd, seems absurd to me. As I said above, when it
+   came it to the GNOME issue, I would like to make a distinction
+   between software with a certain "market share" that is already
+   established, and software that is new (or for that matter, software
+   that isn't new but in the past hasn't had that much of an install
+   base).
+
+
+
+Now to the meat of the matter: logind, or transitive dependencies on
+interfaces provided by systemd, but at least in principle not
+necessarily tied to systemd. I think there is consensus in the TC about:
+
+ - logind being a dependency is not a problem if there are multiple
+   implementations of it, so that it works an all init systems.
+
+I think the difference in opinion boils down to:
+
+ - who should have the onus to make logind work for !systemd?
+
+      - Either the maintainers/devs of other init systems
+        (This also means that if those people don't step up, GNOME will
+        be allowed to indirectly depend on systemd because of this.)
+
+        All the "T" people appear to take this position, but also
+        Steve Langasek [2]
+
+      - Or the GNOME maintainers
+        (or whoever else wants to use logind)
+
+        Ian Jackson sems to take that position [3], if I read his email
+        correctly)
+
+      - Or the systemd maintainers
+
+Personally, I think it's ridiculous that the systemd maintainers should
+do that (and I'm not sure anybody has really argued for that, even
+though Steve Langasek seems to think [2] that that is Ian Jackson's
+position in [3]).
+
+So you have the realistic choices of logind-using-software-maintainers
+vs. other-init-maintainers. I think I personally would go in the
+direction of other-init-maintainers. I don't see a violation of the
+"antitrust law" analogy I made above, simply because I think that in
+case of logind, other init systems are given the appropriate chance, and
+it is their problem if they decide not to take it. But I see that people
+can reasonably disagree here.
+
+
+
+
+To summarize: I think both "L" and "T" are both actively harmful. I have
+provided a list of scenarios (obviously not exhaustive, but probably
+good enough) which I think capture the different situations that might
+be affected by a decision on the coupling issue and given my opinion on
+those issues. What I think should be in any resolution is:
+
+ - Default install set should NOT include anything that depends on a
+   single init system (other than the tools coming with the default
+   init system, obviously).
+
+ - On the one hand, software packages with a wide install base should
+   have a bit of an extra onus in that direct dependencies on a
+   specific PID1 should be disallowed (indirect dependencies such as
+   logind should be part of the vote), i.e. my "antitrust" analogy.
+
+ - On the other hand, depending on systemd (or upstart or OpenRC, for
+   that matter) should be allowed for software that is new or has
+   never been "big" in the ecosystem. Otherwise, I think this will
+   severely retard progress. See my discussion of cases (A) and (C).
+   (Also, I don't think this should be restricted to default init,
+   if somebody wants to write an awesome new solution that depends
+   entirely on upstart or OpenRC, I think they should be free to do
+   so.)
+
+ - But if adding support for other init systems is trivial for a
+   package (missing startup script etc.), there should be some kind
+   of clear statement about that.
+
+ - To summarize as a short sentence: allow dependencies when necessary,
+   forbid them when possible.
+
+ - The ballot itself should then be about the disagreement of who
+   has the onus when it comes to transitive dependencies.
+
+
+
+
+
+
+Also, generally speaking (but I think there is already a rough consensus
+in the TC on that), I don't think it's wise to set policy for beyond
+Jessie NOW, since Jessie+1 will be released at least 3 years from now,
+and systemd itself is for example less than 4 years old (Lennart's
+"rethinking PID1" blog post is from April 2010), so a lot can happen in
+that time.
+
+
+
+Finally, there is the aspect of whether the TC should actually make a
+policy decision the coupling issue, I've heard claims that the question
+was not put before the TC and therefore the TC should only give advice,
+because it's not in its power to do otherwise. Correct my if I'm wrong,
+but wasn't bug #726763 [4] the straw that broke the camel's proverbial
+back that led to this discussion? I have to admit that all I know about
+Debian politics has come from reading the init system discussion (which
+is probably not the best introduction to it ;-)), but it appears to me
+that the coupling question is definitely something that the TC is
+allowed to address and probably actually SHOULD address. #727708
+currently blocks the resolution of #726763 - so if you say that you are
+not going to rule on the coupling question, what is going to be TC's
+answer to #726763? With the current decision, which just affects the
+default init system, I don't see a clear unambiguous response to that
+bug from the TC. Just to give my 2¢ on that topic.
+
+
+
+
+Anyway, I hope that my thoughts on this matter were helpful and I do
+apologize for the length of this email, but since I have now said
+everything I wanted to say about this topic, I can now step back and
+stay out of it.
+
+Regards,
+Christian
+
+[1] Btw, I think systemd's own journalctl doesn't require
+systemd-as-PID1, so it might be a good idea to split the journalctl into
+a different package, so that people using other init systems could
+install it to read journal files generated on different systems. But
+this is just a tangent, so please don't focus on this... ;)
+
+[2] https://lists.debian.org/debian-ctte/2014/02/msg00308.html
+
+[3] https://lists.debian.org/debian-ctte/2014/02/msg00207.html
+
+[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726763
+
+PS: Also note that this email represents my opinion given the
+constraints of the current Debian project and/or ecosystem, this does
+not represent my opinion of how I would design a Linux distribution from
+scratch if I had the time.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 11:42:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 11:42:05 GMT) (full text, mbox, link).

+ +

Message #6974 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Lucas Nussbaum <lucas@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 11:39:35 +0000
+
+
Lucas Nussbaum writes ("Bug#727708: init system coupling etc."):
+> If you really want to have that discussion now, rather than wait for
+> actual, concrete problems to discuss, I'd suggest that you build a few
+> hypothetical scenarios, and discuss them. And then build a resolution
+> that represents the aggregated opinions on those few hypothetical
+> scenarios.
+
+I think there is one key hypothetical scenario, and it is the one
+alluded to in Adrian Bunk's recent message:
+
+] One of the Debian GNOME maintainers has stated in this discussion[1]:
+]
+]>  But there are no realistic solutions for having GNOME support multiple 
+]>   init systems in jessie.
+]
+] Whether that's actually true is another question, but a maintainer 
+] speaking like this clearly shows that it is not only a theoretical
+] question.
+
+I don't find Sjoerd Simons's comments very reassuring.  In the context
+of the whole discussion I think Adrian's interpretation is much more
+likely to reflect the true sentiment.
+
+The question in that context is this: if GNOME upstream say that GNOME
+will only work with systemd, or the Debian GNOME maintainers say that
+Debian's GNOME packages will only work with systemd, is that
+acceptable ?
+
+Do you think it would be better to deal with that hypothetical case
+explicitly ?
+
+> But I also don't really understand why there's a particular urgency
+> for the TC to rule on that. Are there packages with tight coupling
+> already in the archive?
+
+AIUI GNOME in sid right now can't lock the screen unless you're using
+systemd.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 11:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 11:45:04 GMT) (full text, mbox, link).

+ +

Message #6979 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 11:41:43 +0000
+
+
Keith Packard writes ("Bug#727708: init system coupling etc."):
+> I agree with you that this is an important issue which needs to be
+> resolved within the Debian project. I also want to make it clear that I
+> support the goal of having the project provide a clear policy statement
+> about this issue in the short term.
+> 
+> The discussions held within the context of the default init bug were
+> fruitful, and without rancor, which makes me hopeful that the project
+> membership can drive this issue to consensus in the near future through
+> the usual policy editing process. As such I'd like to amend this
+> proposed ballot with an additional option:
+
+I don't think this is likely but I can see why you would want to try
+that.
+
+>  * The TC chooses to not pass a resolution on this issue at the current time.
+> 
+> This is different from FD as it says the TC will not continue
+> discussions on this issue, although it could well restart them if the
+> people involved in the policy editing process come to an impasse. It's
+> also different from 'T' in that it will allow us to revisit this in the
+> future without needing to overturn a previous decision.
+
+And it is different from FD in that if enough people outside the TC
+feel that the issue needs to be decided now, it signals that the time
+for them to propose a GR has come.
+
+> Thank you for your consideration.
+
+And thanks for engaging with the process in a constructive way.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 11:45:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 11:45:08 GMT) (full text, mbox, link).

+ +

Message #6984 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 11:42:00 +0000
+
+
Russ Allbery writes ("Bug#727708: init system coupling etc."):
+> I propose the following text as an amendment to this option.  [...]
+
+Thanks for your constructive contribution.  (As I'm sure you'll
+understand, I don't agree with it but it is right that you propose
+something you feel reflects your views.)
+
+>  It would replace this text in its entirety, including the [GR
+> rider] section.  (I don't see any need for or purpose served by
+> cancelling technical advice to the project based on a GR outcome.
+
+I agree.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 13:42:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Eugene Zhukov <jevgeni.zh@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 13:42:11 GMT) (full text, mbox, link).

+ +

Message #6989 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Eugene Zhukov <jevgeni.zh@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 15:36:04 +0200
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+[...]
+> I don't find Sjoerd Simons's comments very reassuring. In the context
+> of the whole discussion I think Adrian's interpretation is much more
+> likely to reflect the true sentiment.
+
+I wouldn't give Adrian too much credit. Please read some other emails
+between him and fellow developers in this bug. Especially [0].
+
+[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#4652
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 16:48:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Petr Baudis <pasky@ucw.cz>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 16:48:13 GMT) (full text, mbox, link).

+ +

Message #6994 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Petr Baudis <pasky@ucw.cz>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 17:47:13 +0100
+
+
  Hi!
+
+> AIUI GNOME in sid right now can't lock the screen unless you're using
+> systemd.
+
+  When I asked about this [0], I got one reply (by Bdale) saying that
+a missing functionality like this is fine as long as there is no hard
+dependency on systemd and things somehow load.  If your opinion is
+different, that seems to underline that the resolution would have to
+get quite concrete if useful.
+
+  [0] https://lists.debian.org/debian-ctte/2014/01/msg00609.html
+
+
+> The question in that context is this: if GNOME upstream say that GNOME
+> will only work with systemd, or the Debian GNOME maintainers say that
+> Debian's GNOME packages will only work with systemd, is that
+> acceptable ?
+
+  I'm a little confused about exactly what happens if that is "not
+acceptable".  The only *effective* manifestation of "not acceptable"
+I can think of is:
+
+	GNOME packages will be reverted to last version working without
+	systemd and GNOME maintainers prohibited from tracking upstream
+	until it works on systemd-less systems without major bugs.
+
+Obviously(?), that doesn't seem to be too reasonable; based on my
+observations, this doesn't seem to be in the general spirit of CTTE
+resolutions.
+
+  Instead, if CTTE is overriding a maintainer, the resolutions often
+allow a NMU to fix the issue.  That would be reasonable here, but this
+seems only sensible when there is actually something to upload to
+resolve the issue.  Apparently, the work to make GNOME work without
+systemd is not done yet, and is there a reason to believe NMU would
+have to be done if/when there is a patch?
+
+
+  In short, if you would like to ask the GNOME maintainers to do some
+work, what is their incentive, what happens if they don't find time /
+energy to do it?
+
+  Thanks for clarifications,
+
+				Petr "Pasky" Baudis
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 17:00:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Noah Meyerhans <noahm@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 17:00:05 GMT) (full text, mbox, link).

+ +

Message #6999 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Noah Meyerhans <noahm@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 11:56:23 -0500
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Feb 12, 2014 at 10:35:12PM +0000, Ian Jackson wrote:
+> > >    Software outside of an init system's implementation may not require
+> > >    a specific init system to be pid 1, although degraded operation is
+> > >    tolerable.
+> > 
+> > This is super vague. What does being "outside of an init system's
+> > implementation" mean? What does "degraded operation" mean?
+> 
+> Yes.  I agree that it's vague.  I'm open to better and clearer
+> suggestions.  When I wrote this I was hoping that the policy process
+> would be able to refine the details but perhaps that's overoptimistic.
+
+Might we be able define "degraded operation" in terms of BTS severities?
+Packages MUST NOT experience Severity:important or greater buggy
+behavior with alternate inits as pid 1, for example.
+
+There's still a certain amount of subjectivity in identifying bug
+severities, but we've got a lot of experience with them and generally
+manage to agree on them. Defining such coupling in terms of BTS
+severities is also nice because it makes it easy for us to use our
+existing infrastructure to track, over time, how tightly coupled we
+become with a particular init system.
+
+noah
+
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 18:06:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 18:06:05 GMT) (full text, mbox, link).

+ +

Message #7004 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Noah Meyerhans <noahm@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 18:01:56 +0000
+
+
Noah Meyerhans writes ("Bug#727708: init system coupling etc."):
+> On Wed, Feb 12, 2014 at 10:35:12PM +0000, Ian Jackson wrote:
+> > Yes.  I agree that it's vague.  I'm open to better and clearer
+> > suggestions.  When I wrote this I was hoping that the policy process
+> > would be able to refine the details but perhaps that's overoptimistic.
+> 
+> Might we be able define "degraded operation" in terms of BTS severities?
+> Packages MUST NOT experience Severity:important or greater buggy
+> behavior with alternate inits as pid 1, for example.
+
+I suppose what I mean is that a problem which occurs due to "wrong"
+init system is a real problem and should not be reduced in severity or
+excused on the grounds that the particular init system is defined as
+"required" (whether via a dependency or otherwise).
+
+So if the degraded operation amounts to a missing feature (a bug of
+wishlist severity), then that's a bug of wishlist severity (and might
+be closed or tagged "wontfix").
+
+If the degraded operation amounts to a plain bug (ie bug of normal
+severity), then that's a bug of normal severity.  Packages with bugs,
+even regressions, are of course routinely uploaded and released.
+Whether to do so is a tradeoff which we leave the maintainer to
+consider.
+
+If the degraded operation amounts to a bug of RC severity, then that's
+a bug of RC severity and the new version of the requiring package
+should be blocked from transitioning to testing, or being released,
+until the problem is fixed, or at least worked around so that it is no
+longer RC.
+
+Is this a suitable approach ?  If so then perhaps I should clarify my
+proposed wording.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 18:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 18:09:04 GMT) (full text, mbox, link).

+ +

Message #7009 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 18:08:25 +0000
+
+
On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote:
+> I propose the following text as an amendment to this option.  It would
+> replace this text in its entirety, including the [GR rider] section.  (I
+> don't see any need for or purpose served by cancelling technical advice to
+> the project based on a GR outcome.  All the members of the project are, I
+> think, capable of using their own judgement to resolve technical advice
+> with the substance of a GR, and technical advice is by definition not
+> binding.  Plus, I think this is a basically sensible thing to say
+> regardless of the chosen init system.)
+> 
+> Please note that I personally am currently leaning towards voting Keith's
+> proposal above the one that I'm proposing in this message for the reasons
+> that he states in that message.  But I think it's useful to have a
+> statement on the ballot so that it can be ranked, since it may be a
+> compromise position between deferring to the Policy process and Ian's
+> proposal.
+
+I think the detail of this option is a good approach; I'd like to see it
+on the ballot, and I would currently be inclined to rank something like
+this first.
+
+I'm currently undecided about whether I prefer the approach of setting
+technical policy under 6.1.1 or offering advice under 6.1.5.  Bearing in
+mind all the process discussions we've had, I can see that it might be
+better to take the approach of offering technical advice rather than
+getting (re-)embroiled in a distracting procedural dispute about whether
+the Constitution entitles us to rule in advance on a subject that hasn't
+clearly been asked of us by some other first-responding maintainer.  If
+we can establish an advice position that has strong consensus in the
+committee (even if not necessarily at first place on this ballot, given
+that some committee members would prefer to set technical policy in
+advance), then we can always come back to it for reference later if we
+should find it necessary to overrule maintainers.
+
+Ian, you said that you don't agree with this amendment.  I am guessing
+based on your previous statements that you mainly disagree with the
+force of it, rather than the substance, but I'm cautious of making
+unwarranted inferences or putting words in your mouth.  Is this
+accurate?  I think it would be helpful if we had as much substantive
+common ground between the ballot options as possible.
+
+>     Packages should normally support the default Linux init system.  There
+>     are some exceptional cases where lack of support for the default init
+>     system may be appropriate, such as alternative init system
+>     implementations, special-use packages such as managers for non-default
+>     init systems, and cooperating groups of packages intended for use with
+>     non-default init systems.  However, package maintainers should be
+>     aware that a requirement for a non-default init system will mean the
+>     package will be unusable for most Debian users and should normally be
+>     avoided.
+
+Some of the details found here would be helpful in L too, and I think
+they should be common ground.  In particular, several people have noted
+the case of something like separate management utilities for a
+particular init system which make use of advanced details of its
+implementation.  I personally have no quarrel with these as long as
+users of other init systems are not required to install them in order to
+(say) use their desktop environment and keep it updated in a reasonable
+way.  But it's not clear that these are part of the init system's
+implementation, and I would probably argue that they aren't, especially
+if (as they might well be) they are maintained by entirely different
+people.
+
+To start with, I therefore propose the following amendment to L.  I
+think it is no weaker except in ways that we would agree were in fact OK
+if we found ourselves needing to rule on them specifically, and this
+addresses points that people have raised here.  The first paragraph of
+the "loose coupling" section is replaced by the following:
+
+  In general, software may not require a specific init system to be pid
+  1, although degraded operation is tolerable.  The exceptions to this
+  are as follows:
+
+   * alternative init system implementations
+   * special-use packages such as managers for init systems
+   * cooperating groups of packages intended for use with specific init
+     systems
+
+  provided that these are not themselves required by other software
+  whose main purpose is not the operation of a specific init system.
+
+  Maintainers are encouraged to accept technically sound patches
+  to enable improved interoperation with various init systems.
+
+(It took me three goes to draft this in a way I was happy with, so
+perhaps more wordsmithing is needed.)
+
+>     For the jessie release, all packages that currently support being run
+>     under sysvinit should continue to support sysvinit unless there is no
+>     technically feasible way to do so.
+
+"Technically feasible" is so dependent on interpretation that I'm not
+sure whether it has enough real meaning.  My instinct is to borrow some
+of the "exceptional cases" language from an earlier paragraph.  On the
+other hand, "all packages that currently support being run under
+sysvinit" seems to mostly cover this well enough - it just takes me a
+couple of readings to get to it.  Does this sentence bother anyone else?
+Russ, can you give an example of a package that currently supports
+sysvinit where you would be happy that it might stop supporting it for
+jessie due to a lack of technical feasibility?
+
+
+I do expect to have some more thoughts on this, and I'd like to ask that
+we not rush to a vote while we're still actively throwing around
+interesting amendments.  I've had a cluster of complicated customer bugs
+to deal with at work and have been generally busy in the evenings as
+well, so I've not been able to get all the way through my thinking on
+this.  I would rather not have to vote FD again if it can be avoided in
+the discussion period.  On the other hand I can understand Ian's wish to
+put a time limit on this rather than it dragging on forever.  Would an
+extra week work for everyone?  I don't think too much in the way of
+irreversible changes will happen in unstable in that time.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 18:30:12 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 18:30:12 GMT) (full text, mbox, link).

+ +

Message #7014 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 18:26:15 +0000
+
+
Colin Watson writes ("Bug#727708: init system coupling etc."):
+> Ian, you said that you don't agree with this amendment.  I am guessing
+> based on your previous statements that you mainly disagree with the
+> force of it, rather than the substance, but I'm cautious of making
+> unwarranted inferences or putting words in your mouth.  Is this
+> accurate?  I think it would be helpful if we had as much substantive
+> common ground between the ballot options as possible.
+
+OK.  I will review it in more detail.
+
+> To start with, I therefore propose the following amendment to L.  I
+> think it is no weaker except in ways that we would agree were in fact OK
+> if we found ourselves needing to rule on them specifically, and this
+> addresses points that people have raised here.  The first paragraph of
+> the "loose coupling" section is replaced by the following:
+> 
+>   In general, software may not require a specific init system to be pid
+>   1, although degraded operation is tolerable.  The exceptions to this
+>   are as follows:
+> 
+>    * alternative init system implementations
+>    * special-use packages such as managers for init systems
+>    * cooperating groups of packages intended for use with specific init
+>      systems
+> 
+>   provided that these are not themselves required by other software
+>   whose main purpose is not the operation of a specific init system.
+
+I think this is a good approach.  I accept this amendment.  Thank you.
+
+> (It took me three goes to draft this in a way I was happy with, so
+> perhaps more wordsmithing is needed.)
+
+I'll have a go at that but I don't want to break it.
+
+> I do expect to have some more thoughts on this, and I'd like to ask that
+> we not rush to a vote while we're still actively throwing around
+> interesting amendments.  I've had a cluster of complicated customer bugs
+> to deal with at work and have been generally busy in the evenings as
+> well, so I've not been able to get all the way through my thinking on
+> this.  I would rather not have to vote FD again if it can be avoided in
+> the discussion period.  On the other hand I can understand Ian's wish to
+> put a time limit on this rather than it dragging on forever.  Would an
+> extra week work for everyone?  I don't think too much in the way of
+> irreversible changes will happen in unstable in that time.
+
+I'm more worried about irreversible changes in the wider world, but
+perhaps anything we do now is too late to overcome the "systemd wins
+everywhere" headlines.
+
+I do see that we are making progress, which I felt we weren't before.
+I'm willing to wait.  So for the avoidance of any doubt, I'm going to
+set a new planned-CFV of 2014-02-20 18:30 UTC.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 18:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Hedderly <paul@mjr.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 18:33:04 GMT) (full text, mbox, link).

+ +

Message #7019 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Hedderly <paul@mjr.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Cc: Noah Meyerhans <noahm@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 18:24:27 +0000
+
+
On Thu, Feb 13, 2014 at 06:01:56PM +0000, Ian Jackson wrote:
+> I suppose what I mean is that a problem which occurs due to "wrong"
+> init system is a real problem and should not be reduced in severity or
+> excused on the grounds that the particular init system is defined as
+> "required" (whether via a dependency or otherwise).
+> 
+> So if the degraded operation amounts to a missing feature (a bug of
+> wishlist severity), then that's a bug of wishlist severity (and might
+> be closed or tagged "wontfix").
+> 
+> If the degraded operation amounts to a plain bug (ie bug of normal
+> severity), then that's a bug of normal severity.  Packages with bugs,
+> even regressions, are of course routinely uploaded and released.
+> Whether to do so is a tradeoff which we leave the maintainer to
+> consider.
+
+If you consider a dependancy as a bug... then the next question might have to
+be - who's is the bug. Is it the fault of the package or group of packages
+such as GNOME needing a feature/api - or is it the fault of alternative
+feature providers that they do not provide the facilities required - ie
+the fault of the init system. 
+
+Is innovation and progress a bug?
+Or is stagnation a bug?
+Surely the "bug" is with packages that do not provide what is needed (yet).
+
+So in this case I would feel then that it could be considered a bug that OpenRC,
+Upstart etc do not provide (yet) the features that GNOME need/want to depend
+on. But there is hope for technical solutions to be found for those problems
+as they arise - as systemd-shim shows. (Personally I think that package has an
+exceedingly misleading name! Am I alone?)
+
+> If the degraded operation amounts to a bug of RC severity, then that's
+> a bug of RC severity and the new version of the requiring package
+> should be blocked from transitioning to testing, or being released,
+> until the problem is fixed, or at least worked around so that it is no
+> longer RC.
+
+So we should start raising bugs against sysvinit,openrc,upstart etc for any
+features that systemd has that might be useful, but which are missing in
+those respective packages?
+
+There being more than one way to see this problem, I hope we can go the way
+Keith has proposed: Now that the issue is clearly in focus for project
+maintainers I would be very surprised if amicable technical resolutions
+cannot be found as they are required.
+
+IMHO the big issue for the project really was/is which is the default init
+system for Jessie which for Jessie, and against which all packages must
+fully work. Potential GR aside, happily the work to focus on that target
+can now commence in earnest.
+
+Regards
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 18:33:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Uwe Storbeck <uwe@ibr.ch>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 18:33:08 GMT) (full text, mbox, link).

+ +

Message #7024 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Uwe Storbeck <uwe@ibr.ch>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 19:25:54 +0100
+
+
On Feb 12, Russ Allbery wrote:
+>     Packages should normally support the default Linux init system.
+[..]
+>     Package maintainers are strongly encouraged to merge any contributions
+>     for support of init systems other than the Linux default, and to add
+>     that support themselves if they're willing and capable of doing so.
+
+Assumed a package has (only) start scripts for sysvinit. This
+satisfies "Packages should normally support the default Linux
+init system" (using sysvinit compatibility mode).
+Someone provides patches to add native support for upstart and
+systemd, maybe to use advanced features like socket activation.
+Following the above proposal the package maintainer is encouraged
+to apply the patch for upstart (as an init system "other than the
+Linux default"), but not the patch for systemd.
+
+Wouldn't it be better to change that to something like "for
+support of any init system"?
+
+Uwe
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 18:54:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 18:54:07 GMT) (full text, mbox, link).

+ +

Message #7029 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 18:51:13 +0000
+
+
Colin Watson writes ("Bug#727708: init system coupling etc."):
+> To start with, I therefore propose the following amendment to L.  I
+> think it is no weaker except in ways that we would agree were in fact OK
+> if we found ourselves needing to rule on them specifically, and this
+> addresses points that people have raised here.  The first paragraph of
+> the "loose coupling" section is replaced by the following:
+> 
+>   In general, software may not require a specific init system to be pid
+>   1, although degraded operation is tolerable.  The exceptions to this
+>   are as follows:
+> 
+>    * alternative init system implementations
+>    * special-use packages such as managers for init systems
+>    * cooperating groups of packages intended for use with specific init
+>      systems
+> 
+>   provided that these are not themselves required by other software
+>   whose main purpose is not the operation of a specific init system.
+> 
+>   Maintainers are encouraged to accept technically sound patches
+>   to enable improved interoperation with various init systems.
+> 
+> (It took me three goes to draft this in a way I was happy with, so
+> perhaps more wordsmithing is needed.)
+
+In the spirit of my response to Noah Meyerhans:
+
+    In general, software may not require a specific init system to be
+    pid 1.  The exceptions to this are as follows:
+      * alternative init system implementations
+      * special-use packages such as managers for init systems
+      * cooperating groups of packages intended for use with specific init
+	systems
+   provided that these are not themselves required by other software
+   whose main purpose is not the operation of a specific init system.
+
+   Degraded operation with some init systems is tolerable, so long as
+   the degradation is no worse than a tolerable bug.  So the lack of
+   a particular init system does not excuse a bug nor reduce its
+   severity; but conversely, nor is a bug more serious simply because
+   it is an incompatibility of some software with some init
+   system(s).
+
+Is this a clearer line to draw ?
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 20:00:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 20:00:05 GMT) (full text, mbox, link).

+ +

Message #7034 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 20:56:44 +0100
+
+
* Colin Watson (cjwatson@debian.org) [140213 19:09]:
+> To start with, I therefore propose the following amendment to L.  I
+> think it is no weaker except in ways that we would agree were in fact OK
+> if we found ourselves needing to rule on them specifically, and this
+> addresses points that people have raised here.  The first paragraph of
+> the "loose coupling" section is replaced by the following:
+> 
+>   In general, software may not require a specific init system to be pid
+>   1, although degraded operation is tolerable.  The exceptions to this
+>   are as follows:
+> 
+>    * alternative init system implementations
+>    * special-use packages such as managers for init systems
+>    * cooperating groups of packages intended for use with specific init
+>      systems
+I'm not sure if this already covers the case of glue-packages, or if
+we need to cover them (i.e. for a package foo, it's ok, if foo depends
+on foo-sysv | foo-systemd | foo-upstart | foo-openrc, and each of
+those four depends on a specific init system).
+
+
+>   provided that these are not themselves required by other software
+>   whose main purpose is not the operation of a specific init system.
+
+I think we agree that "required" doesn't involve cases where such a
+package is just one of a different set of packages which fulfils that
+requirement (via virtual packages or alternatives).
+
+
+> Russ, can you give an example of a package that currently supports
+> sysvinit where you would be happy that it might stop supporting it for
+> jessie due to a lack of technical feasibility?
+
+If this is advice, I think we can drop that part (for a decision that
+might be different, and an indication that it might be possible that
+there are exceptions might be appropriate).
+
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 20:27:21 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 20:27:21 GMT) (full text, mbox, link).

+ +

Message #7039 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 20:25:18 +0000
+
+
On Thu, Feb 13, 2014 at 08:56:44PM +0100, Andreas Barth wrote:
+> * Colin Watson (cjwatson@debian.org) [140213 19:09]:
+> > To start with, I therefore propose the following amendment to L.  I
+> > think it is no weaker except in ways that we would agree were in fact OK
+> > if we found ourselves needing to rule on them specifically, and this
+> > addresses points that people have raised here.  The first paragraph of
+> > the "loose coupling" section is replaced by the following:
+> > 
+> >   In general, software may not require a specific init system to be pid
+> >   1, although degraded operation is tolerable.  The exceptions to this
+> >   are as follows:
+> > 
+> >    * alternative init system implementations
+> >    * special-use packages such as managers for init systems
+> >    * cooperating groups of packages intended for use with specific init
+> >      systems
+> 
+> I'm not sure if this already covers the case of glue-packages, or if
+> we need to cover them (i.e. for a package foo, it's ok, if foo depends
+> on foo-sysv | foo-systemd | foo-upstart | foo-openrc, and each of
+> those four depends on a specific init system).
+
+I think this class of problem is handled by saying "software" rather
+than "packages", much as we're saying "requires" rather than "depends
+on"; I generally like Ian's approach of not trying to overspecify here.
+If people feel this is unclear then maybe we need some kind of
+for-avoidance-of-doubt rubric though.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 13 Feb 2014 22:36:18 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 13 Feb 2014 22:36:18 GMT) (full text, mbox, link).

+ +

Message #7044 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 14:35:42 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I don't think this is likely but I can see why you would want to try
+> that.
+
+Thanks. Being new to the TC, I may feel more reluctant to exercise it's
+process than people more familiar to the role.
+
+> And it is different from FD in that if enough people outside the TC
+> feel that the issue needs to be decided now, it signals that the time
+> for them to propose a GR has come.
+
+While I would lean towards not supporting a GR at this time, I agree
+that having one not occur in parallel with a matching TC discussion
+would probably work out better.
+
+> And thanks for engaging with the process in a constructive way.
+
+We'll make it work somehow.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 03:57:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 03:57:05 GMT) (full text, mbox, link).

+ +

Message #7049 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Colin Watson <cjwatson@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 19:55:25 -0800
+
+
Colin Watson <cjwatson@debian.org> writes:
+
+> I'm currently undecided about whether I prefer the approach of setting
+> technical policy under 6.1.1 or offering advice under 6.1.5.  Bearing in
+> mind all the process discussions we've had, I can see that it might be
+> better to take the approach of offering technical advice rather than
+> getting (re-)embroiled in a distracting procedural dispute about whether
+> the Constitution entitles us to rule in advance on a subject that hasn't
+> clearly been asked of us by some other first-responding maintainer.
+
+I also think Keith's point that the normal process for setting Policy can
+probably handle this is entirely correct.  Certainly, I don't think there
+will be substantial difficulties hammering out a Policy change given
+advice from the TC.  If there is, we can always deal with it at that
+point.
+
+> To start with, I therefore propose the following amendment to L.  I
+> think it is no weaker except in ways that we would agree were in fact OK
+> if we found ourselves needing to rule on them specifically, and this
+> addresses points that people have raised here.  The first paragraph of
+> the "loose coupling" section is replaced by the following:
+
+>   In general, software may not require a specific init system to be pid
+>   1, although degraded operation is tolerable.  The exceptions to this
+>   are as follows:
+
+>    * alternative init system implementations
+>    * special-use packages such as managers for init systems
+>    * cooperating groups of packages intended for use with specific init
+>      systems
+
+>   provided that these are not themselves required by other software
+>   whose main purpose is not the operation of a specific init system.
+
+>   Maintainers are encouraged to accept technically sound patches
+>   to enable improved interoperation with various init systems.
+
+There's probably no chance that I will vote any version of L above FD, so
+feel free to disregard this.  But I think this is begging for some sort of
+definition of "specific."
+
+As written, it seems like it either requires all packages in the archive
+add runit configuration, since otherwise they're not supporting all init
+systems available in Debian, or alternately that any package that provides
+a runit configuration and an OpenRC configuration and depends on runit |
+openrc is fine, since it doesn't depend on "a" specific init system (it
+depends on one of two specific init systems).
+
+I don't think either of those are what you intend here.  But I'm at a loss
+as to what you *do* intend.  Explain it to me like I'm five?  :)
+
+>>     For the jessie release, all packages that currently support being run
+>>     under sysvinit should continue to support sysvinit unless there is no
+>>     technically feasible way to do so.
+
+"packages" here should probably actually be "software" for all the reasons
+discussed elsewhere.
+
+> "Technically feasible" is so dependent on interpretation that I'm not
+> sure whether it has enough real meaning.  My instinct is to borrow some
+> of the "exceptional cases" language from an earlier paragraph.  On the
+> other hand, "all packages that currently support being run under
+> sysvinit" seems to mostly cover this well enough - it just takes me a
+> couple of readings to get to it.  Does this sentence bother anyone else?
+> Russ, can you give an example of a package that currently supports
+> sysvinit where you would be happy that it might stop supporting it for
+> jessie due to a lack of technical feasibility?
+
+Yes: logind.  I think it should be fine to package a current version of
+logind for Debian (meaning one that requires cgroups).  I don't think
+logind is part of the init system implementation; it's just another
+program, like udev, that's built from the systemd source package.  I don't
+think it falls into any of the other exception cases.  I think it's quite
+reasonable to package a current logind for those who want to use it, even
+though, by requiring cgroups, it currently only works with a corresponding
+version of systemd as init.  (Note that packaging it and having other
+packages depend on it are distinct acts with separate implications.)
+
+My understanding of the expected situation for jessie is that either
+another cgroups implementation that works under sysvinit will be available
+or someone will package logind 204 in a way that works with sysvinit.
+Given that, it will be technically feasible for GNOME to depend on a
+logind solution that doesn't require systemd.  Therefore, this advice says
+that GNOME should not depend on systemd as init.  (This is all totally
+obvious, of course, and I'm quite confident that the GNOME maintainers
+don't need this advice to do the right thing, which is exactly why I will
+probably be voting Keith's proposal first.)
+
+But suppose that the alternative cgroups implementation doesn't
+materialize.  That specific logind implementation then *would* depend on
+systemd as init.  Does that mean that a logind that uses systemd cgroups
+management is not permitted in Debian for the jessie release even if
+another version of logind is also available?
+
+Without the technically feasible qualification, this would be against our
+advice since the current packaged logind doesn't require systemd as the
+init system, and I see no reason for it to be.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 04:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 04:09:04 GMT) (full text, mbox, link).

+ +

Message #7054 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Uwe Storbeck <uwe@ibr.ch>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 20:04:29 -0800
+
+
Uwe Storbeck <uwe@ibr.ch> writes:
+> On Feb 12, Russ Allbery wrote:
+
+>>     Packages should normally support the default Linux init system.
+> [..]
+>>     Package maintainers are strongly encouraged to merge any contributions
+>>     for support of init systems other than the Linux default, and to add
+>>     that support themselves if they're willing and capable of doing so.
+
+> Assumed a package has (only) start scripts for sysvinit. This satisfies
+> "Packages should normally support the default Linux init system" (using
+> sysvinit compatibility mode).  Someone provides patches to add native
+> support for upstart and systemd, maybe to use advanced features like
+> socket activation.  Following the above proposal the package maintainer
+> is encouraged to apply the patch for upstart (as an init system "other
+> than the Linux default"), but not the patch for systemd.
+
+> Wouldn't it be better to change that to something like "for support of
+> any init system"?
+
+Yes, that's much better.  Thanks!
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 07:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 07:51:05 GMT) (full text, mbox, link).

+ +

Message #7059 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Christian Seiler <christian@iwakd.de>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 13 Feb 2014 23:47:42 -0800
+
+
Christian Seiler <christian@iwakd.de> writes:
+
+> On the other hand, the T text seems to be motivated by the wish to not
+> hamper progress when it comes to software, that the Debian project
+> should not hold software back because of some ideological reasons.
+
+Well, the T language wasn't written by me, but I should clarify that's not
+what I'm trying to say in my proposals.  I think Debian should do lots of
+things for ideological reasons.  One of the pieces of Debian ideology that
+matters a great deal to me is that we should trust our package maintainers
+to choose how to package the software they maintain, and trust their
+judgement about the approach that provides the best, most high-quality,
+and most integrated experience for our users.
+
+In other words, what I want to do is defer to package maintainers, who
+are, after all, experts in the packaging of their software, to make good
+decisions.  The TC should only get involved where there are irreconcilable
+conflicts about how to do this, or when the project asks us for guidance
+on how to achieve distribution-wide integration.
+
+I feel like an argument could be made that the project has asked us for
+advice on this (although I think a good argument could be made that the
+project has *not*, which is Keith's point).  I'm trying to express that
+advice while continuing to recognize and respect the fact that Debian
+defers, in nearly every case, to the informed technical judgement of the
+packager or packaging team, and generally tries to address most conflicts
+by enabling the parallel packaging of software with different approaches
+rather than choosing a single winner and rejecting all other "competing"
+packages.  I'm also trying to respect the core foundational value of
+Debian that volunteers get to work on what they choose to work on, and no
+body in Debian has the authority to order people around.
+
+I found your specific cases a useful clarifying exercise to lay out how I
+think about this, so let me respond to each of them:
+
+> (A) Someone writes a GUI for managing systemd that has the goal of
+> providing access to as many features as possible, so that it really is
+> tightly coupled to systemd in that sense. There is no way this could
+> realistically be ported to other init systems. (Although a different
+> software for e.g. upstart could be affected in the same way.)
+
+This clearly should depend on systemd and should be allowed.
+
+> (B) Someone writes a GUI for accessing journald files on the hard drive.
+
+Depending on how this is written, it may depend on the package providing
+journalctl or it may depend on some shared library that implements the
+journal reading code, or it might even have no dependencies at all if it
+implements the journal reading code itself.
+
+> (C) Someone writes some kind of framework that depends on advanced
+> systemd features, such as systemd-nspawn, to provide a novel technical
+> solution. This software is new and not yet widely adopted. (Somewhere in
+> the original discussion before all of the ballots, somebody mentioned
+> something akin to this, I just don't feel it makes sense to invest the
+> time to dig that up.)
+
+This clearly should depend on systemd and should be allowed.
+
+> (D) Someone writes a daemon that currently only works with systemd, but
+> a patch for including sysvinit and upstrart support is literally only 5
+> lines of code.
+
+Assuming that this is a new package not previously in Debian, and after
+systemd has become the default init system, I think it should be fine to
+introduce this package with a dependency on systemd until such time as
+someone actually writes and tests that patch.  Once that patch is written
+and tested and submitted, the maintainer should incorporate it and drop
+the dependency.  (Constitutionally, I don't think the TC should require
+maintainers to do this in advance, but if this actually got escalated all
+the way to the TC as a maintainer override, something that I really hope
+would never happen and I see no reason to believe would happen, I would be
+baffled by why the maintainer wouldn't include such support.)
+
+> (E) GNOME depends on logind interfaces and there is not working
+> alternative logind (>=205) implementation available.
+
+(I don't know of any reason why GNOME would specifically need to depend on
+a post-205 logind at this point, so I'm replying to this without the
+parenthetical.)
+
+I think this should be fine.  But this is a controversial case that we
+have strong reasons to believe won't actually arise, so it's not clear
+whether there's any need to argue about my position on it.
+
+> (F) GNOME depends on logind interfaces and somebody stepped up and
+> created a logind implementation for other init systems.
+
+In this case, I think GNOME should allow either implementation to satisfy
+its dependency.  I think that's uncontroversial across the board,
+including with the GNOME maintainers.
+
+> (G) GNOME starts to depend on systemd as pid1 irrespective of logind.
+
+There doesn't seem to be any technical reason why this would be necessary,
+so I think this is inappropriate.  I believe that's also the opinion of
+the GNOME maintainers; in other words, they have no intention of doing
+this.
+
+> (H) Some software part of the default install set (which currently does
+> not include GNOME but might again in the future) depends on systemd as
+> PID1, either directly (see G) or indirectly via logind with no
+> alternative implementation (see E).
+
+There don't appear to be any technical reasons why this would be
+necessary, so I think this would be inappropriate for the same reason.
+
+> Let me start with "T":
+
+>  - Most serious case (H): If any software in the default install set
+>    depends on systemd, then this IMHO creates the de-facto situation
+>    that there really only is systemd support. Because if you can't
+>    switch the init system if you have a default set of software
+>    installed, saying that you support multiple init systems is a farce.
+
+>    Therefore, I definitely think that any resolution by the TC should
+>    include language that says that any software in the default install
+>    set should work with ALL supported init systems (with degraded
+>    operation being possible).
+
+>    So in the case of GNOME, if it continues to depend on logind (likely)
+>    and there doesn't happen to be a logind implementation that works
+>    with all the other init systems (unknown), then that should
+>    definitely disqualify GNOME from being made default desktop again.
+>    (OTOH, if there IS an alternative logind implementation at the point
+>    where this is decided, this doesn't stand in the way of GNOME
+>    becoming the default desktop again, but obviously it will also not
+>    make GNOME automatically the default desktop, that will depend on
+>    other things. ;-))
+
+The GNOME part has been discussed at length here.  I'm fairly sure that
+the situation we'll end up with is that GNOME will depend on the
+disjunction of the available logind implementations, and Steve is
+extremely confident that logind will be available under sysvinit for
+jessie.
+
+It's possible that, in the long, long run, GNOME will want to depend on
+systemd to use systemd for session management, but it's already been clear
+on this thread that this won't happen for jessie, and it's not at all
+clear whether this will ever be necessary or whether there will always be
+a fallback available.  It is obvious, at least as I understand it, that
+this won't be necessary or something anyone is considering for jessie.
+
+>  - Case (G): I don't think this is likely to happen for Jessie, but I
+>    do think this should be addressed.
+
+In general, I part company with you at this point.  If something isn't
+likely to happen, I *don't* think it should be addressed.  In fact, I
+think it *should not* be addressed.  We have enough immediate issues;
+let's not borrow trouble by both addressing things that are unlikely and
+then lecturing our developers about how to handle cases that they're
+probably quite capable of handling themselves.
+
+>  - Case (D): The "T" text encourages maintainers to include support for
+>    other init systems, but you could imagine a stubborn maintainer that
+>    refuses to even include a patch as trivial as described in that
+>    scenario. For this reason, I think the language could be made
+>    stronger at this point.
+
+In general, my feeling is that Debian maintainers do not have to be
+carefully programmed to do exactly what the Technical Committee thinks
+they should do.  The default should be to allow maintainers to use their
+own technical judgement.
+
+If maintainers do something particularly bad or contrary to overall
+project goals, we can deal with that when it happens and we have
+mechanisms to do so, but treating maintainers like they will do that
+proactively is paternalistic and unnecessary.
+
+I'm going to skip through more of the analysis here, and just walk through
+your list of things that you think should be in any resolution:
+
+> To summarize: I think both "L" and "T" are both actively harmful. I have
+> provided a list of scenarios (obviously not exhaustive, but probably
+> good enough) which I think capture the different situations that might
+> be affected by a decision on the coupling issue and given my opinion on
+> those issues. What I think should be in any resolution is:
+
+>  - Default install set should NOT include anything that depends on a
+>    single init system (other than the tools coming with the default
+>    init system, obviously).
+
+The default install set is determined by the installer team.  I don't
+currently see any need for the TC to get involved in their work, and I
+don't think the d-i team has asked us to do so.  I think they are quite
+capable of weighing these issues and making appropriate decisions about
+the default install set, or expressing their concerns to other package
+maintainers.
+
+>  - On the one hand, software packages with a wide install base should
+>    have a bit of an extra onus in that direct dependencies on a
+>    specific PID1 should be disallowed (indirect dependencies such as
+>    logind should be part of the vote), i.e. my "antitrust" analogy.
+
+In general, I agree with this, and I also think that the maintainers of
+such packages would generally agree with this, because of the impact that
+they have on the distribution.  However, they have to balance this concern
+against the fact that some of those software packages (such as desktop
+environments in general) also have the most need and demand for advanced
+facilities.  These packages often stress the limits of the capabilities of
+the system in ways that the "average" software package does not.
+
+That balance is difficult and tricky, and I think our DE maintainers by
+and large do an excellent job at this.  I have a strong preference to
+letting them go about their work.
+
+We have one specific issue around logind that is likely to affect GNOME
+and KDE and possibly others, and we've talked about the solutions in
+detail and Steve is confident that we can solve this issue for sysvinit
+for jessie.  If there are other issues like this, I think the DE
+maintainers and the init system maintainers and possibly the porters
+should talk it over, and if they need us to get involved, we'll always be
+here.  But most of these issues can be worked out amicably without any
+need for TC involvement.
+
+>  - On the other hand, depending on systemd (or upstart or OpenRC, for
+>    that matter) should be allowed for software that is new or has
+>    never been "big" in the ecosystem. Otherwise, I think this will
+>    severely retard progress. See my discussion of cases (A) and (C).
+>    (Also, I don't think this should be restricted to default init,
+>    if somebody wants to write an awesome new solution that depends
+>    entirely on upstart or OpenRC, I think they should be free to do
+>    so.)
+
+I agree with this.
+
+>  - But if adding support for other init systems is trivial for a
+>    package (missing startup script etc.), there should be some kind
+>    of clear statement about that.
+
+I agree with this as well.
+
+>  - To summarize as a short sentence: allow dependencies when necessary,
+>    forbid them when possible.
+
+I don't like the idea of the TC forbidding things at this point, but I
+think that's a good summary of what I think maintainers should do (and I
+think what maintainers will do).
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 09:15:20 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 09:15:20 GMT) (full text, mbox, link).

+ +

Message #7064 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 10:12:36 +0100
+
+
Le jeudi 13 février 2014 à 23:47 -0800, Russ Allbery a écrit : 
+> > (B) Someone writes a GUI for accessing journald files on the hard drive.
+> 
+> Depending on how this is written, it may depend on the package providing
+> journalctl or it may depend on some shared library that implements the
+> journal reading code, or it might even have no dependencies at all if it
+> implements the journal reading code itself.
+
+This is not a hypothetical case. It exists, and it uses journald
+directly. The software will not start if systemd is not PID 1. Note that
+this is part of what we’d like to put in the gnome metapackage, so
+forbidding this has real impact on real packages for jessie.
+
+> > (E) GNOME depends on logind interfaces and there is not working
+> > alternative logind (>=205) implementation available.
+> 
+> (I don't know of any reason why GNOME would specifically need to depend on
+> a post-205 logind at this point, so I'm replying to this without the
+> parenthetical.)
+
+This will certainly happen one day or another, but probably not for
+jessie.
+
+This (not isolated) case raises the point of package-level management of
+non-library interfaces, with versions. We might need to set a policy on
+this kind of cases. For example, should we generalize situations such
+as:
+* systemd-sysv Provides: systemd204, systemd207, … 
+* foo Depends: systemd-sysv (>= 204) | systemd204
+
+> > (F) GNOME depends on logind interfaces and somebody stepped up and
+> > created a logind implementation for other init systems.
+> 
+> In this case, I think GNOME should allow either implementation to satisfy
+> its dependency.  I think that's uncontroversial across the board,
+> including with the GNOME maintainers.
+
+This is indeed uncontroversial, except for the part that the non-systemd
+case would be unsupported from the GNOME side.
+
+I’m just not seeing this happening (see at the bottom).
+
+> It's possible that, in the long, long run, GNOME will want to depend on
+> systemd to use systemd for session management, but it's already been clear
+> on this thread that this won't happen for jessie, and it's not at all
+> clear whether this will ever be necessary or whether there will always be
+> a fallback available.  It is obvious, at least as I understand it, that
+> this won't be necessary or something anyone is considering for jessie.
+
+It has already been made clear that this WILL happen for jessie, but
+that a fallback (either in the same package or another one) can be made
+available.
+
+> We have one specific issue around logind that is likely to affect GNOME
+> and KDE and possibly others, and we've talked about the solutions in
+> detail and Steve is confident that we can solve this issue for sysvinit
+> for jessie.
+
+The only available solution so far involves keeping a systemd 204
+package, which will not happen. With systemd as the default init system,
+the systemd maintainers will try to have the latest version integrated.
+
+So either Steve and his cronies commit to maintain a separate systemd204
+package (with all the switching issues that scenario involves), or they
+deliver their so-far vaporware to work over systemd >= 205. Or it just
+doesn’t work, which is what will probably happen.
+
+In all cases, it is unacceptable to put the burden of implementing
+logind on non-systemd systems on maintainers of packages that just need
+the logind interfaces. If it is not available, software such as gdm3
+will depend, directly or indirectly, on systemd as PID 1, and that will
+be all.
+
+(For non-Linux ports, the old ConsoleKit code will be enabled instead,
+but users should not expect this to work at all.)
+
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 13:51:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 13:51:08 GMT) (full text, mbox, link).

+ +

Message #7069 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 13:50:20 +0000
+
+
Josselin Mouette writes ("Bug#727708: init system coupling etc."):
+> In all cases, it is unacceptable to put the burden of implementing
+> logind on non-systemd systems on maintainers of packages that just need
+> the logind interfaces. If it is not available, software such as gdm3
+> will depend, directly or indirectly, on systemd as PID 1, and that will
+> be all.
+
+Firstly, I think the scenario where the required integration work is
+not done is unlikely.  But in that scenario, we have two choices:
+ (a) Effectively, drop all init systems other than systemd
+ (b) Effectively, drop GNOME
+
+Of these, (b) is IMO clearly preferable.  Our downstreams can
+straightforwardly provide a more specific Debian derivative which runs
+GNOME and (only) systemd.  Asking our downstreams to reintroduce
+support for a non-systemd init system is not feasible.
+
+With (a) the only option for people who didn't want systemd would be
+to either fork the whole of the Debian project and declare themselves
+a new upstream for all of what Debian now does, or to abandon Debian
+and its derivatives altogether.
+
+With (b) people who want GNOME and systemd can do that work as a
+Debian derivative; it is not necessary to fork the whole project.
+
+The doomsday scenario of choosing between (a) and (b) becomes less
+likely if we make it clear how bad it would be.  We need to provide
+appropriate backpressure to encourage upstream decisions that support
+the continued freedom of our users.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 14:12:11 GMT) (full text, mbox, link).

+ +

Message #7072 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 14:55:20 +0100
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Firstly, I think the scenario where the required integration work is
+> not done is unlikely.  But in that scenario, we have two choices:
+>  (a) Effectively, drop all init systems other than systemd
+>  (b) Effectively, drop GNOME
+>
+> Of these, (b) is IMO clearly preferable.
+
+Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
+plans to depend on logind... And it sounds like a really brillant idea
+to drop all of them to keep ChaosEsque Team happy with Debian.
+
+Ansgar
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 14:33:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josselin Mouette <joss@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 14:33:15 GMT) (full text, mbox, link).

+ +

Message #7077 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josselin Mouette <joss@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 15:31:41 +0100
+
+
Le vendredi 14 février 2014 à 13:50 +0000, Ian Jackson a écrit : 
+> Josselin Mouette writes ("Bug#727708: init system coupling etc."):
+> > In all cases, it is unacceptable to put the burden of implementing
+> > logind on non-systemd systems on maintainers of packages that just need
+> > the logind interfaces. If it is not available, software such as gdm3
+> > will depend, directly or indirectly, on systemd as PID 1, and that will
+> > be all.
+> 
+> Firstly, I think the scenario where the required integration work is
+> not done is unlikely.  But in that scenario, we have two choices:
+>  (a) Effectively, drop all init systems other than systemd
+>  (b) Effectively, drop GNOME
+
+This looks very much like a false dichotomy to me.
+
+You can have (c) GNOME depends on systemd.
+Same for KDE and Xfce, BTW, since they are going in the same direction.
+
+Desktop environments are not the only pieces of software in Debian.
+Having them depend on systemd doesn’t prevent you from using other init
+systems on machines that don’t have them installed.
+
+> The doomsday scenario of choosing between (a) and (b) becomes less
+> likely if we make it clear how bad it would be.  We need to provide
+> appropriate backpressure to encourage upstream decisions that support
+> the continued freedom of our users.
+
+I don’t see how (c) looks bad. What’s the problem of limiting the scope
+of non-default init systems? It’s not as if we will want the same level
+of support for them than we want for the default init system.
+
+In all cases, this situation happening or not is the result of the work
+of people not interested in logind nor in desktop environments. Having
+the decision to keep packages in Debian depend on the work of unrelated
+people is preposterous.
+
+Cheers,
+-- 
+ .''`.        Josselin Mouette
+: :' :
+`. `'
+  `-
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 15:24:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andres Freund <andres@anarazel.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 15:24:04 GMT) (full text, mbox, link).

+ +

Message #7082 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andres Freund <andres@anarazel.de>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 16:21:53 +0100
+
+
On 2014-02-14 13:50:20 +0000, Ian Jackson wrote:
+> Josselin Mouette writes ("Bug#727708: init system coupling etc."):
+> > In all cases, it is unacceptable to put the burden of implementing
+> > logind on non-systemd systems on maintainers of packages that just need
+> > the logind interfaces. If it is not available, software such as gdm3
+> > will depend, directly or indirectly, on systemd as PID 1, and that will
+> > be all.
+> 
+> Firstly, I think the scenario where the required integration work is
+> not done is unlikely.  But in that scenario, we have two choices:
+>  (a) Effectively, drop all init systems other than systemd
+>  (b) Effectively, drop GNOME
+> 
+> Of these, (b) is IMO clearly preferable.  Our downstreams can
+> straightforwardly provide a more specific Debian derivative which runs
+> GNOME and (only) systemd.  Asking our downstreams to reintroduce
+> support for a non-systemd init system is not feasible.
+
+> With (b) people who want GNOME and systemd can do that work as a
+> Debian derivative; it is not necessary to fork the whole project.
+
+I don't think b) would have any upsides, even if it's only happening for
+a short time:
+
+a) Debian users would loose because the DE (gnome and some others) the
+   use vanishes. We've seen how happy changes around that makes them,
+   and how vocal they can get. Surely entirely removing a DE entirely
+   makes them even more unhappy than substantive change.
+b) Debian would loose users.
+c) downstreams would suffer, because they now would need to package
+   $software independently from debian. Collaboration without a common
+   upstream is hard.
+d) Parties wanting to port/test a piece of software to work without
+   systemd, suddenly need to care about packaging, before their real
+   work can start. Individual developers maybe can get by using source
+   code checkouts and compiling everything themselves, but testers
+   surely not.
+e) Parties wanting to implement alternatives to systemd's logind, cgroup
+   manager have less software to test.
+
+Given those points the only value in suggesting that route is in being a
+threat gesture against some unspecified party. I think such a gesture is
+of questionable morality, but even worse, I think it runs counter to
+your goals of having most software run independently of the init
+system.
+I don't see this helping the freedom of debian's users, rather the
+contrary.
+
+I think it makes much more sense to generate policy or a TC statement,
+that suggests that packagers should apply reasonable patches to help
+portability (just like they are already asked for porting software to
+some different linux or other supported architecture). And, quite
+importantly, try to streamline the process of dealing with escalations
+to the TC to determine whether a patch is reasonable. If that takes half
+a year every now and then most people will just give up.
+
+Regards,
+
+Andres Freund
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 15:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 15:51:04 GMT) (full text, mbox, link).

+ +

Message #7087 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Ansgar Burchardt <ansgar@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 15:46:18 +0000
+
+
Ansgar Burchardt writes ("Bug#727708: init system coupling etc."):
+> Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
+> plans to depend on logind...
+
+logind is a red herring because AIUI we already have a technical
+solution to that.  The problem is other things that might be in the
+pipeline.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 15:51:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Josh Triplett <josh@joshtriplett.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 15:51:07 GMT) (full text, mbox, link).

+ +

Message #7092 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Josh Triplett <josh@joshtriplett.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 07:46:17 -0800
+
+
Ian Jackson wrote:
+> I suppose what I mean is that a problem which occurs due to "wrong"
+> init system is a real problem and should not be reduced in severity or
+> excused on the grounds that the particular init system is defined as
+> "required" (whether via a dependency or otherwise).
+> 
+> So if the degraded operation amounts to a missing feature (a bug of
+> wishlist severity), then that's a bug of wishlist severity (and might
+> be closed or tagged "wontfix").
+> 
+> If the degraded operation amounts to a plain bug (ie bug of normal
+> severity), then that's a bug of normal severity.  Packages with bugs,
+> even regressions, are of course routinely uploaded and released.
+> Whether to do so is a tradeoff which we leave the maintainer to
+> consider.
+> 
+> If the degraded operation amounts to a bug of RC severity, then that's
+> a bug of RC severity and the new version of the requiring package
+> should be blocked from transitioning to testing, or being released,
+> until the problem is fixed, or at least worked around so that it is no
+> longer RC.
+> 
+> Is this a suitable approach ?  If so then perhaps I should clarify my
+> proposed wording.
+
+This approach does solve one problem present in previous proposals, by
+clarifying that a bug does not become any *more* severe just because it
+involves init systems.  However, there are still two notable problems
+this doesn't address.
+
+First, on which init systems?.  Everything in Debian that provides
+/sbin/init, no matter its capabilities or lack thereof?  Or some subset
+of those implementations, in which case what are the selection criteria
+for that subset?
+
+Second, what makes init systems so wildly different from anything else
+in Debian that the usual principles don't apply?  For any other package,
+"doesn't work when its dependencies are replaced" is a wishlist bug.
+Such bugs are often fixed, especially when a patch is supplied, but that
+doesn't make them any more than wishlist, even though "doesn't work"
+would be RC if the package's dependencies are satisfied.  That's true
+even when the dependencies and their alternatives are packages that
+can't coexist on the same running system.
+
+As far as I can tell, the only difference is one of scale: systemd is
+poised to provide functionality that far more packages want and might
+benefit from depending on, and thus the fear that it will become
+irreplaceable is higher.  Nonetheless, this still seems like something
+that can be handled naturally.  People who want to support alternative
+init systems can continue to do so; absolutely nothing is stopping them.
+As long as that work remains tractable and people want to do it, it'll
+find a way to happen; Debian developers are too good at cooperating with
+each other for that not to work out.  If the work to support any
+particular init system across all packages in the archive ever becomes
+overwhelming and insurmountable, *that means something*.
+
+It makes sense to ensure that developers or supporters of alternate init
+systems can expect a reasonable reception for work they've done to make
+packages work with their init system.  (I don't see any obvious reason
+to expect that won't already happen, but it's certainly reasonable to
+debate how best to achieve *that* goal.)  However, this proposal instead
+suggests that if that work hasn't been done yet by anyone, something has
+gone horribly wrong and must be fixed, rather than that a wishlist bug
+exists and a patch would sure be nice.
+
+Does a proposal phrasing exist that would satisfy the concerns
+motivating this one, addressing the goal of supporting contribution of
+support for alternate init systems, without making it a bug for the
+maintainer of every package to do the work themselves?  Or is it the
+intentional aim of this proposal to force package maintainers to do the
+work of supporting all init systems themselves or face an RC bug?
+
+(As an aside, while it wouldn't necessarily do everything you want out
+of this proposal, I wouldn't be surprised if there's support from the TC
+for a proposal of "maintain sysvinit compatibility through jessie, and
+support smooth upgrades", which ought to address the concerns that are
+motivating your urgency in addressing this issue.  Passing such a
+resolution would then allow for a more prolonged consideration of how to
+handle things post-jessie, as well as consideration of whether existing
+cooperative processes in Debian might be able to handle this isue given
+the time.  Any particular reason *not* to do that?)
+
+- Josh Triplett
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 15:51:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 15:51:10 GMT) (full text, mbox, link).

+ +

Message #7097 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 15:46:46 +0000
+
+
Josselin Mouette writes ("Bug#727708: init system coupling etc."):
+> Le jeudi 13 février 2014 à 23:47 -0800, Russ Allbery a écrit : 
+> > Depending on how this is written, it may depend on the package providing
+> > journalctl or it may depend on some shared library that implements the
+> > journal reading code, or it might even have no dependencies at all if it
+> > implements the journal reading code itself.
+> 
+> This is not a hypothetical case. It exists, and it uses journald
+> directly. The software will not start if systemd is not PID 1.
+
+This is covered by the exception that Colin drafted:
+
+  In general, software may not require a specific init system to be pid
+  1, although degraded operation is tolerable.  The exceptions to this
+  are as follows:
+
+   * alternative init system implementations
+   * special-use packages such as managers for init systems
+   * cooperating groups of packages intended for use with specific init
+     systems
+
+  provided that these are not themselves required by other software
+  whose main purpose is not the operation of a specific init system.
+
+>   Note that
+> this is part of what we’d like to put in the gnome metapackage, so
+> forbidding this has real impact on real packages for jessie.
+
+What is pulled in by the gnome metapackage is a different issue.  My
+draft talks about "software", not "packages", quite deliberately.
+There isn't any distinct sofware in the gnome metapackage.  Indeed the
+whole purpose of talking about "software" is so that metapackages,
+glue packages ("foobar-runit"), and so forth, aren't caught by this
+restriction.
+
+Rather, the purpose of a metapackage is to arrange that the right
+combination of software is installed.  So I don't think my proposed
+wording prevents the gnome metapackage from pulling in systemd in this
+way.
+
+Whether the gnome metapackage should pull in systemd like this is
+rather a different question.  It is more related to detailed questions
+of the desirable behaviour during upgrades etc.  We discussed these in
+some detail in the case of gnome -> network-manager.  I don't think we
+need to address the metapackage point at this stage although I imagine
+the TC may be asked about it.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 15:51:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 15:51:14 GMT) (full text, mbox, link).

+ +

Message #7102 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 15:49:19 +0000
+
+
Ian Jackson writes ("Bug#727708: init system coupling etc."):
+> In the spirit of my response to Noah Meyerhans:
+> 
+>     In general, software may not require a specific init system to be
+>     pid 1.  The exceptions to this are as follows:
+>       * alternative init system implementations
+>       * special-use packages such as managers for init systems
+>       * cooperating groups of packages intended for use with specific init
+> 	systems
+>    provided that these are not themselves required by other software
+>    whose main purpose is not the operation of a specific init system.
+> 
+>    Degraded operation with some init systems is tolerable, so long as
+>    the degradation is no worse than a tolerable bug.  So the lack of
+>    a particular init system does not excuse a bug nor reduce its
+>    severity; but conversely, nor is a bug more serious simply because
+>    it is an incompatibility of some software with some init
+>    system(s).
+> 
+> Is this a clearer line to draw ?
+
+I'd appreciate feedback from other TC members on this wording.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 16:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to James Hogarth <james.hogarth@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 16:03:04 GMT) (full text, mbox, link).

+ +

Message #7107 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: James Hogarth <james.hogarth@gmail.com>
+
To: debian-ctte@lists.debian.org, 727708@bugs.debian.org
+
Subject: How much of L vs T is still relevant in light of the Ubuntu + announcement?
+
Date: Fri, 14 Feb 2014 15:58:33 +0000
+
+
Hi guys,
+
+So in light of the new announcement[1] how much of L vs T is still
+relevant?
+
+Upstart is obviously going to be pretty much dead in the water now given
+this - after who is going to seriously contribute to a deprecated
+project CLA or no?
+
+It would seem to this outside observer at any rate this has an impact on
+certain discussions at any rate...
+
+Regards,
+
+James
+
+[1] http://www.markshuttleworth.com/archives/1316
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 16:03:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andres Freund <andres@anarazel.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 16:03:07 GMT) (full text, mbox, link).

+ +

Message #7112 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andres Freund <andres@anarazel.de>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Cc: Ansgar Burchardt <ansgar@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 16:59:34 +0100
+
+
On 2014-02-14 15:46:18 +0000, Ian Jackson wrote:
+> Ansgar Burchardt writes ("Bug#727708: init system coupling etc."):
+> > Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
+> > plans to depend on logind...
+> 
+> logind is a red herring because AIUI we already have a technical
+> solution to that.  The problem is other things that might be in the
+> pipeline.
+
+I am not so sure it's there. The current version runs without systemd
+but doesn't support everything and more up2date versions don't run at
+all. There's promise of more work in that direction, but that might be
+influenced by Ubuntu seemingly also switching in the not too far away
+future: http://www.markshuttleworth.com/archives/1316
+
+Greetings,
+
+Andres Freund
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 16:15:04 GMT) (full text, mbox, link).

+ +

Message #7115 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ansgar Burchardt <ansgar@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 17:07:23 +0100
+
+
Hi,
+
+Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> Ansgar Burchardt writes ("Bug#727708: init system coupling etc."):
+>> Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
+>> plans to depend on logind...
+>
+> logind is a red herring because AIUI we already have a technical
+> solution to that.  The problem is other things that might be in the
+> pipeline.
+
+But even the suggested (and not yet existing) solution is very likely
+not a long-term solution given Canonical switches to systemd[1]. It
+might still work for Jessie, but I expect it to be abandoned later (and
+do we really want to use it for Jessie in this case?).
+
+I wouldn't expect someone else to take up maintaince either: this hasn't
+happened for ConsoleKit after all. It is probably even less likely to
+happen here as the suggested solution involves using parts of systemd
+and people vehemently opposed to it are unlikely to work on it.
+
+Ansgar
+
+  [1] <http://www.markshuttleworth.com/archives/1316>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 16:45:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to James Hogarth <james.hogarth@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 16:45:09 GMT) (full text, mbox, link).

+ +

Message #7120 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cory <opensourcesoftwaredeveloper@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: How much of L vs T is still relevant in light of + the Ubuntu announcement?
+
Date: Fri, 14 Feb 2014 10:40:02 -0600
+
+
On 02/14/2014 09:58 AM, James Hogarth wrote:
+> Hi guys,
+>
+> So in light of the new announcement[1] how much of L vs T is still
+> relevant?
+>
+> Upstart is obviously going to be pretty much dead in the water now given
+> this - after who is going to seriously contribute to a deprecated
+> project CLA or no?
+>
+> It would seem to this outside observer at any rate this has an impact on
+> certain discussions at any rate...
+>
+> Regards,
+>
+> James
+>
+> [1] http://www.markshuttleworth.com/archives/1316
+>
+>
+Well it looks like upstart is coming to a EOL do to the Vote for systemd 
+in Debian weird
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 17:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 17:51:04 GMT) (full text, mbox, link).

+ +

Message #7125 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 09:47:13 -0800
+
+
Josselin Mouette <joss@debian.org> writes:
+> Le vendredi 14 février 2014 à 13:50 +0000, Ian Jackson a écrit : 
+>> Josselin Mouette writes ("Bug#727708: init system coupling etc."):
+
+>>> In all cases, it is unacceptable to put the burden of implementing
+>>> logind on non-systemd systems on maintainers of packages that just
+>>> need the logind interfaces. If it is not available, software such as
+>>> gdm3 will depend, directly or indirectly, on systemd as PID 1, and
+>>> that will be all.
+
+>> Firstly, I think the scenario where the required integration work is
+>> not done is unlikely.  But in that scenario, we have two choices:
+>>  (a) Effectively, drop all init systems other than systemd
+>>  (b) Effectively, drop GNOME
+
+> This looks very much like a false dichotomy to me.
+
+> You can have (c) GNOME depends on systemd.
+> Same for KDE and Xfce, BTW, since they are going in the same direction.
+
+> Desktop environments are not the only pieces of software in Debian.
+> Having them depend on systemd doesn’t prevent you from using other init
+> systems on machines that don’t have them installed.
+
+Exactly.
+
+I somewhat disagree with Josselin in that I actually do think this is an
+unlikely result and that, at least in the short term, people will step
+forward and find an alternative solution.  I also don't think that
+maintaining a 204-era logind in the archive for jessie if a cgroups fix
+doesn't materialize is the worst thing that could happen, provided that
+someone is willing to maintain it.
+
+But I also don't agree with the idea that it's the end of the world if
+GNOME depends on systemd.  There are a bunch of other DEs, and there are a
+bunch of other uses for Debian systems other than running DEs.
+
+That said, I again repeat that I question whether it's worth having this
+argument when there are concrete steps people can take today to ensure
+that it is an argument we don't have to have.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 17:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 17:57:04 GMT) (full text, mbox, link).

+ +

Message #7130 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Josselin Mouette <joss@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 09:53:02 -0800
+
+
Josselin Mouette <joss@debian.org> writes:
+
+> So either Steve and his cronies commit to maintain a separate systemd204
+> package (with all the switching issues that scenario involves),
+
+Hi Josselin,
+
+I realize that passions are running high here, and there has been a great
+deal of bad blood on both sides.  But regardless of the situation, this is
+inappropriate language.  Talking about other people in Debian as if we're
+part of rival camps, even if in the heat of the moment it feels like that,
+is escalation and makes everything worse.  And using this sort of language
+about other Debian contributors just damages our community without
+accomplishing anything constructive.
+
+I think you can make your point without referring to people with these
+sorts of disparaging terms.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 18:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 18:18:04 GMT) (full text, mbox, link).

+ +

Message #7135 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Andres Freund <andres@anarazel.de>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, + Ansgar Burchardt <ansgar@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 10:14:54 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Feb 14, 2014 at 04:59:34PM +0100, Andres Freund wrote:
+> On 2014-02-14 15:46:18 +0000, Ian Jackson wrote:
+> > Ansgar Burchardt writes ("Bug#727708: init system coupling etc."):
+> > > Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
+> > > plans to depend on logind...
+
+> > logind is a red herring because AIUI we already have a technical
+> > solution to that.  The problem is other things that might be in the
+> > pipeline.
+
+> I am not so sure it's there. The current version runs without systemd
+> but doesn't support everything
+
+Based on what?  There is only one new interface in logind between v204 and
+v208, an 'org.freedesktop.login1.Manager.GetUserByPID' method.  Are you
+telling me that this is a critical feature for desktops, that they won't run
+correctly without?
+
+> and more up2date versions don't run at all.  There's promise of more work
+> in that direction, but that might be influenced by Ubuntu seemingly also
+> switching in the not too far away future:
+> http://www.markshuttleworth.com/archives/1316
+
+Which says right in that blog entry that:
+
+   We’ll certainly complete work to make the new logind work without systemd
+   as pid 1.
+
+Even supposing that GetUserByPID is critical for jessie, and even supposing
+that Canonical did not finish the work to make logind work with cgmanager,
+backporting this one interface to logind 204 will be trivial.  There is no
+excuse at all for Debian getting the compatibility wrong in jessie.  (But an
+awful lot of people who seem eager to make excuses for it.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 18:33:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 18:33:08 GMT) (full text, mbox, link).

+ +

Message #7140 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: James Hogarth <james.hogarth@gmail.com>, 727708@bugs.debian.org, debian-ctte@lists.debian.org
+
Subject: Re: Bug#727708: How much of L vs T is still relevant in light of the Ubuntu announcement?
+
Date: Fri, 14 Feb 2014 11:28:03 -0700
+
+
[Message part 1 (text/plain, inline)]
+
James Hogarth <james.hogarth@gmail.com> writes:
+
+> So in light of the new announcement[1] how much of L vs T is still
+> relevant?
+
+Mark's announcement may mean that upstart is less likely to be a viable
+alternative over time, but it says nothing at all about the other init
+systems and their users in Debian.  
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 18:33:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Cory <opensourcesoftwaredeveloper@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 18:33:11 GMT) (full text, mbox, link).

+ +

Message #7145 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cory <opensourcesoftwaredeveloper@gmail.com>
+
To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 12:30:49 -0600
+
+
On 02/14/2014 12:14 PM, Steve Langasek wrote:
+> On Fri, Feb 14, 2014 at 04:59:34PM +0100, Andres Freund wrote:
+>> On 2014-02-14 15:46:18 +0000, Ian Jackson wrote:
+>>> Ansgar Burchardt writes ("Bug#727708: init system coupling etc."):
+>>>> Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
+>>>> plans to depend on logind...
+>>> logind is a red herring because AIUI we already have a technical
+>>> solution to that.  The problem is other things that might be in the
+>>> pipeline.
+>> I am not so sure it's there. The current version runs without systemd
+>> but doesn't support everything
+> Based on what?  There is only one new interface in logind between v204 and
+> v208, an 'org.freedesktop.login1.Manager.GetUserByPID' method.  Are you
+> telling me that this is a critical feature for desktops, that they won't run
+> correctly without?
+>
+>> and more up2date versions don't run at all.  There's promise of more work
+>> in that direction, but that might be influenced by Ubuntu seemingly also
+>> switching in the not too far away future:
+>> http://www.markshuttleworth.com/archives/1316
+> Which says right in that blog entry that:
+>
+>     We’ll certainly complete work to make the new logind work without systemd
+>     as pid 1.
+>
+> Even supposing that GetUserByPID is critical for jessie, and even supposing
+> that Canonical did not finish the work to make logind work with cgmanager,
+> backporting this one interface to logind 204 will be trivial.  There is no
+> excuse at all for Debian getting the compatibility wrong in jessie.  (But an
+> awful lot of people who seem eager to make excuses for it.
+>
+
+So you guys are forking systemd?
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 18:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 18:39:04 GMT) (full text, mbox, link).

+ +

Message #7150 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: James Hogarth <james.hogarth@gmail.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: How much of L vs T is still relevant in light of the Ubuntu announcement?
+
Date: Fri, 14 Feb 2014 10:34:37 -0800
+
+
Bdale Garbee <bdale@gag.com> writes:
+> James Hogarth <james.hogarth@gmail.com> writes:
+
+>> So in light of the new announcement[1] how much of L vs T is still
+>> relevant?
+
+> Mark's announcement may mean that upstart is less likely to be a viable
+> alternative over time, but it says nothing at all about the other init
+> systems and their users in Debian.  
+
+Completely agreed.
+
+The principles that we're trying to apply here are Debian principles, and
+continue to be sound regardless of the decisions of our downstreams.  It
+will always be possible that init systems will wax and wane, that new ones
+will crop up and that developers might stop working on others.  What we're
+trying to do here is figure out what sort of framework Debian should use
+for thinking about init systems and supporting subsets of our community
+that want to work on different init systems.
+
+As a bonus, if we do this properly, we'll have at least a start on how to
+handle the new init system that comes along after systemd with some other
+neat new feature set that people are excited about.  If there's anything
+that's sure in free software, it's that any given component will
+eventually have some competitor that at least some people like better.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 18:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andres Freund <andres@anarazel.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 18:51:05 GMT) (full text, mbox, link).

+ +

Message #7155 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andres Freund <andres@anarazel.de>
+
To: Steve Langasek <vorlon@debian.org>
+
Cc: 727708@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>, + Ansgar Burchardt <ansgar@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 19:49:32 +0100
+
+
On 2014-02-14 10:14:54 -0800, Steve Langasek wrote:
+> On Fri, Feb 14, 2014 at 04:59:34PM +0100, Andres Freund wrote:
+> > On 2014-02-14 15:46:18 +0000, Ian Jackson wrote:
+> > > Ansgar Burchardt writes ("Bug#727708: init system coupling etc."):
+> > > > Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
+> > > > plans to depend on logind...
+>
+> > > logind is a red herring because AIUI we already have a technical
+> > > solution to that.  The problem is other things that might be in the
+> > > pipeline.
+>
+> > I am not so sure it's there. The current version runs without systemd
+> > but doesn't support everything
+>
+> Based on what?  There is only one new interface in logind between v204 and
+> v208, an 'org.freedesktop.login1.Manager.GetUserByPID' method.  Are you
+> telling me that this is a critical feature for desktops, that they won't run
+> correctly without?
+
+Nono, that's not what I meant, sorry for being imprecise. Logind calls
+out to systemd for shutting down. -shim now supports some of that, but
+the last time I tried logind without systemd but just -shim didn't work
+fully yet?
+
+> > and more up2date versions don't run at all.  There's promise of more work
+> > in that direction, but that might be influenced by Ubuntu seemingly also
+> > switching in the not too far away future:
+> > http://www.markshuttleworth.com/archives/1316
+>
+> Which says right in that blog entry that:
+>
+>    We’ll certainly complete work to make the new logind work without systemd
+>    as pid 1.
+>
+> Even supposing that GetUserByPID is critical for jessie, and even supposing
+> that Canonical did not finish the work to make logind work with cgmanager,
+> backporting this one interface to logind 204 will be trivial.  There is no
+> excuse at all for Debian getting the compatibility wrong in jessie.  (But an
+> awful lot of people who seem eager to make excuses for it.
+
+Please don't get me wrong. I don't think compatibility should be dropped
+in the near future. It's just that Ian argued that gnome requiring
+logind won't become a problem because of the current state of logind and
+systemd-shim, and in consequence that forbidding dependencies on
+interfaces provided only when systemd is present is unproblematic. I
+don't think the current state warrants that.
+
+I think there should be clear language, be it in policy or TC
+resolution, to suggest that maintainers should accept compatibility
+patches. But that's it.
+
+Greetings,
+
+Andres Freund
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 19:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 19:57:04 GMT) (full text, mbox, link).

+ +

Message #7160 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Andres Freund <andres@anarazel.de>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, + Ansgar Burchardt <ansgar@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 11:52:48 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Feb 14, 2014 at 07:49:32PM +0100, Andres Freund wrote:
+
+> > > I am not so sure it's there. The current version runs without systemd
+> > > but doesn't support everything
+
+> > Based on what?  There is only one new interface in logind between v204 and
+> > v208, an 'org.freedesktop.login1.Manager.GetUserByPID' method.  Are you
+> > telling me that this is a critical feature for desktops, that they won't run
+> > correctly without?
+
+> Nono, that's not what I meant, sorry for being imprecise. Logind calls
+> out to systemd for shutting down. -shim now supports some of that, but
+> the last time I tried logind without systemd but just -shim didn't work
+> fully yet?
+
+systemd-shim+logind is working fine in Ubuntu - and shutdown is pretty basic
+functionality, that's expected to work.  I have recently seen some reports
+(via IRC) that logind-based logout is not working from GNOME in unstable,
+even when running systemd as PID1.  So there may be some bugs here, but I
+have yet to receive any bug reports on the systemd-shim package pointing to
+a problem with systemd-shim vs. systemd compatibility.
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 20:21:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 20:21:04 GMT) (full text, mbox, link).

+ +

Message #7165 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Thoughts/Summary on the init-system
+
Date: Fri, 14 Feb 2014 21:17:28 +0100
+
+
* Andreas Metzler (ametzler@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
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 21:45:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zack Weinberg <zackw@panix.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 21:45:09 GMT) (full text, mbox, link).

+ +

Message #7170 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zack Weinberg <zackw@panix.com>
+
To: 727708@bugs.debian.org
+
Subject: init dependencies and smooth upgrades from wheezy
+
Date: Fri, 14 Feb 2014 16:43:29 -0500
+
+
I brought this up earlier in the discussion, but it appeared right in
+the middle of the big argument about what to vote on, and so seems to
+have gotten overlooked.  I think this pair of requirements, both
+grounded in what it's going to take to do upgrades from wheezy in a
+clean fashion, might be a useful alternative to the "L" and "T"
+positions that are currently being discussed:
+
+For the release of jessie only,
+
+1. No package may, merely by being installed or upgraded, change the
+currently-active init system or the init system that will bring up the
+machine on the next reboot.  In other words, installations upgraded
+from wheezy will continue to boot with sysvinit until the local
+sysadmin takes an additional deliberate step to switch to something
+else.
+
+[I see this as a vital requirement simply because the sysadmin of any
+given installation should have a chance to check over local software,
+scripts, etc. to make sure they can handle a changeover.  It also
+provides a stabilization point after all packages have been upgraded
+but before the init system has been changed, which may simplify how
+the changeover process works.]
+
+2. Packages may depend on a particular init system in the usual
+fashion, but because of (1), must be prepared to cope at runtime if
+that init system is not active.  Failure to cope is a bug.  The
+severity of that bug, and the appropriate meaning of "cope" for each
+package, are left to the discretion of individual package maintainers
+and/or the release team.
+
+[In conjunction with (1), this prevents the formation of "archive
+islands" where you can't *install* things just because you don't have
+the maintainer's preferred init system active - perhaps for good
+reason.  But it avoids the equally troublesome situation where
+software with a hard dependency can't express that dependency
+honestly; it just has to have some sort of runtime check as well - and
+that, again, is essential for upgrades to go smoothly.]
+
+[Examples of "failure to cope is a bug": assuming no
+unit-file-to-sysvinit-script shim materializes, it would be an RC bug
+if openssh-server dropped its sysvinit script prior to jessie.
+Similarly for other important network servers. That journal GUI
+Josselin mentioned *ought* to be able to display journal-format logs
+if pointed to them by name, even if journald itself is not running, so
+it has a bug, but if the maintainer wants to call it a wishlist bug
+that's fine.  It does not make sense to try to run cgmanager and
+systemd simultaneously, so cgmanager should detect on startup that
+some other (not necessarily systemd) program has control of cgroups,
+and if so, bail out cleanly; assuming it does so, it does not have a
+bug.]
+
+zw
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 14 Feb 2014 23:12:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 14 Feb 2014 23:12:04 GMT) (full text, mbox, link).

+ +

Message #7175 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Cory <opensourcesoftwaredeveloper@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 14 Feb 2014 17:08:39 -0600
+
+
On 02/14/2014 01:52 PM, Steve Langasek wrote:
+> On Fri, Feb 14, 2014 at 07:49:32PM +0100, Andres Freund wrote:
+>
+>>>> I am not so sure it's there. The current version runs without systemd
+>>>> but doesn't support everything
+>>> Based on what?  There is only one new interface in logind between v204 and
+>>> v208, an 'org.freedesktop.login1.Manager.GetUserByPID' method.  Are you
+>>> telling me that this is a critical feature for desktops, that they won't run
+>>> correctly without?
+>> Nono, that's not what I meant, sorry for being imprecise. Logind calls
+>> out to systemd for shutting down. -shim now supports some of that, but
+>> the last time I tried logind without systemd but just -shim didn't work
+>> fully yet?
+> systemd-shim+logind is working fine in Ubuntu - and shutdown is pretty basic
+> functionality, that's expected to work.  I have recently seen some reports
+> (via IRC) that logind-based logout is not working from GNOME in unstable,
+> even when running systemd as PID1.  So there may be some bugs here, but I
+> have yet to receive any bug reports on the systemd-shim package pointing to
+> a problem with systemd-shim vs. systemd compatibility.
+>
+has any one reported this bug on systemd 205 and up also systemd 207 was 
+a bug's fix release and systemd 204 is really dated i use systemd 204 in 
+Debian testing but the ABI's have change with cgroup's for a newer 
+systemd then 204.
+
+but on the other hand Wayland support in Mutter relies on logind to 
+handle VT switching this is a nice little rabbit hole that needs looked 
+into Wayland-Mutter requires logind from a PID 1 systemd "critical 
+feature" and Mir will too as well as they share some code no? down the 
+road also systemd 208 has a major addition to logind for Wayland
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 15 Feb 2014 10:39:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 15 Feb 2014 10:39:10 GMT) (full text, mbox, link).

+ +

Message #7180 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Sat, 15 Feb 2014 11:36:51 +0100
+
+
* Russ Allbery (rra@debian.org) [140214 04:36]:
+> Andreas Barth <aba@ayous.org> writes:
+> > * Russ Allbery (rra@debian.org) [140212 19:00]:
+> 
+> >>     Packages should normally support the default Linux init system.  There
+> 
+> > I would drop the word "Linux" here - Packages should support our default
+> > init systems.
+> 
+> That's a much stronger statement than we've made about support for the
+> non-Linux ports in the past, where they're treated at most like another
+> release architecture, which means that packages that have never worked on
+> that architecture are not expected to do so and packages that used to work
+> but stopped are sometimes removed from just that architecture rather than
+> ported depending on the situation.
+
+My expectation of packages is indeed that they work on as many
+architectures as reasonable possible, and this includes that they
+support the default init system there. (The question of "which
+severity does a bug have" is a different question, for a release
+architecture that bug would be serious according to
+https://release.debian.org/jessie/rc_policy.txt section 4 paragraph 4
+and I don't think we should lower the bar.)
+
+I don't think that this expectation is wrong.
+
+
+> >>     are some exceptional cases where lack of support for the default
+> >>     init system may be appropriate, such as alternative init system
+> >>     implementations, special-use packages such as managers for
+> >>     non-default init systems, and cooperating groups of packages
+> >>     intended for use with non-default init systems.  However, package
+> >>     maintainers should be aware that a requirement for a non-default
+> >>     init system will mean the package will be unusable for most Debian
+> >>     users and should normally be avoided.
+> 
+> > Also, I would think it appropriate if packages should (i.e. in case
+> > appropriate patches are available) support other init systems, and not
+> > depend on the default init systems.
+> 
+> I think that's already covered in the paragraph after this one.
+
+If we agree on that, then we don't need to duplicate that.
+
+> >>     The Technical Committee offers no advice at this time on requirements
+> >>     or package dependencies on specific init systems after the jessie
+> >>     release.  There are too many variables at this point to know what the
+> >>     correct course of action will be.
+> 
+> > I think we could just drop the whole paragraph.
+> 
+> Why do you want to drop it?
+
+Because I currently don't see why we should say that (or: whats in
+there which is not already said elsewhere), and in that case, less
+text is better.
+
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 15 Feb 2014 13:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Olav Vitters <olav@vitters.nl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 15 Feb 2014 13:51:04 GMT) (full text, mbox, link).

+ +

Message #7185 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Olav Vitters <olav@vitters.nl>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Sat, 15 Feb 2014 14:46:13 +0100
+
+
On Fri, Feb 14, 2014 at 03:31:41PM +0100, Josselin Mouette wrote:
+> Le vendredi 14 février 2014 à 13:50 +0000, Ian Jackson a écrit : 
+> > Josselin Mouette writes ("Bug#727708: init system coupling etc."):
+> > > In all cases, it is unacceptable to put the burden of implementing
+> > > logind on non-systemd systems on maintainers of packages that just need
+> > > the logind interfaces. If it is not available, software such as gdm3
+> > > will depend, directly or indirectly, on systemd as PID 1, and that will
+> > > be all.
+> > 
+> > Firstly, I think the scenario where the required integration work is
+> > not done is unlikely.  But in that scenario, we have two choices:
+> >  (a) Effectively, drop all init systems other than systemd
+> >  (b) Effectively, drop GNOME
+
+From my personal view, GNOME should not block any work to make GNOME
+work properly on other init systems. I'd love something which implements
+the various systemd APIs, but then on *BSD and so on.
+
+GNOME developers have worked and work on various infrastructure projects
+as well. Various of these are freedesktop.org projects. Hereby sometimes
+causing confusion. E.g. ConsoleKit and UPower are/were not driven by
+GNOME; these are freedesktop.org projects.
+
+GNOME is totally open to anyone providing alternative implantations for
+systemd APIs, though IMO we're not a party in that. I'd love if someone
+would write something that works on *BSD. Note that there are a few
+GNOME developers people who've installed FreeBSD for the first time ever
+just to improve the *BSD experience (within the scope of GNOME).
+
+In case there is a distribution policy that prevents GNOME from being
+packaged then we'll work with the distribution to integrate the
+distributions work. Provided that the patches are reasonable.
+
+If distribution policy is more demanding than what the distribution can
+cope with itself, then there is no problem making a reasonable request
+in how we can assist. In case of init system development, I suggest
+first asking init system developers for assistance. However, if all
+fails then seems unfortunate if GNOME is dropped. I don't any sudden
+change in the scope of GNOME (meaning: we are not init system developers
+and we should limit ourselves to ensure APIs could have an alternative
+implementation).
+
+> You can have (c) GNOME depends on systemd.
+
+And
+(d) have other init systems do the maintenance for alternative
+implementations. Have upstream and/or package maintainers be reasonable
+in integrating that work.
+
+> Same for KDE and Xfce, BTW, since they are going in the same direction.
+
+Agreed, various things are freedesktop.org projects.
+
+-- 
+Regards,
+Olav (all comments my own POV, not on behalf of GNOME)
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 15 Feb 2014 19:36:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to svante.signell@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 15 Feb 2014 19:36:04 GMT) (full text, mbox, link).

+ +

Message #7190 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Svante Signell <svante.signell@gmail.com>
+
To: debian-ctte@lists.debian.org
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Sat, 15 Feb 2014 20:33:10 +0100
+
+
> * Russ Allbery (rra@debian.org) [140212 19:00]:
+> >     Packages should normally support the default Linux init system.  There
+> 
+> I would drop the word "Linux" here - Packages should support our
+> default init systems.
+
+If you do that then you have killed all non-linux architectures, is
+that intentional? Debian is digging their own grave with respect to
+Free Software (not not FOSS or FOS), why don't you align with M$soft,
+Apple or especially RedHat :( Debian will just be a memory in a few
+years, RedHat will be the solution for everybody (TM).
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 15 Feb 2014 19:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 15 Feb 2014 19:45:04 GMT) (full text, mbox, link).

+ +

Message #7195 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: svante.signell@gmail.com
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Sat, 15 Feb 2014 11:40:45 -0800
+
+
Svante Signell <svante.signell@gmail.com> writes:
+
+>> * Russ Allbery (rra@debian.org) [140212 19:00]:
+>> >     Packages should normally support the default Linux init system.  There
+>> 
+>> I would drop the word "Linux" here - Packages should support our
+>> default init systems.
+
+> If you do that then you have killed all non-linux architectures, is
+> that intentional?
+
+You have misunderstood Andi's point, I think.  What I believe he's trying
+to say is that the level of support for the default Linux init system and
+the default init system on kFreeBSD or Hurd should be the same, and talked
+about the same.  In other words, if sysvinit is the default init system on
+kFreeBSD, that should be supported at the same level and with the same
+priority as systemd support on Linux.
+
+> Debian is digging their own grave with respect to Free Software (not not
+> FOSS or FOS), why don't you align with M$soft, Apple or especially
+> RedHat :( Debian will just be a memory in a few years, RedHat will be
+> the solution for everybody (TM).
+
+Please take this sort of thing to some other mailing list.  It's not going
+to change the mind of anyone here; it's just annoying and basically
+content-free.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 15 Feb 2014 19:51:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to svante.signell@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 15 Feb 2014 19:51:07 GMT) (full text, mbox, link).

+ +

Message #7200 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Svante Signell <svante.signell@gmail.com>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: init system coupling etc.
+
Date: Sat, 15 Feb 2014 20:48:54 +0100
+
+
> On 2014-02-14 15:46:18 +0000, Ian Jackson wrote:
+> > Ansgar Burchardt writes ("Bug#727708: init system coupling etc."):
+> > > Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
+> > > plans to depend on logind...
+> > 
+> > logind is a red herring because AIUI we already have a technical
+> > solution to that.  The problem is other things that might be in the
+> > pipeline.
+
+It does not, see e.g. bug: 736880, or bug 602724, wrt gdm3 a really old one.
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sat, 15 Feb 2014 20:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to svante.signell@gmail.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sat, 15 Feb 2014 20:15:05 GMT) (full text, mbox, link).

+ +

Message #7205 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Svante Signell <svante.signell@gmail.com>
+
To: 727708@bugs.debian.org
+
Cc: debian-ctte@lists.debian.org
+
Subject: Bug#727708: init system coupling etc
+
Date: Sat, 15 Feb 2014 21:12:55 +0100
+
+
> > Debian is digging their own grave with respect to Free Software (not
+> > FOSS or FOS), why don't you align with M$soft, Apple or especially
+> > RedHat :( Debian will just be a memory in a few years, RedHat will be
+> > the solution for everybody (TM).
+> 
+> Please take this sort of thing to some other mailing list.  It's not going
+> to change the mind of anyone here; it's just annoying and basically
+> content-free
+
+Never mind now, just please read this message in (about) three years
+from now, and judge for yourself (am I a fortune teller, or not? :))
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 18 Feb 2014 05:57:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to su0147pport@zoho.com:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 18 Feb 2014 05:57:05 GMT) (full text, mbox, link).

+ +

Message #7210 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "Helpdesk@eunet.rs" <info@eunet.rs>
+
Subject: Надоградите ваш налог е-поште
+
Date: Tue, 18 Feb 2014 05:48:23 -0000
+
+
Поштовани: Рачун корисника,
+
+Ова порука је из центра за подршку система Администратор. Будите информисани
+да је ваша е-маил налог је премашио границу складиштење је поставио ваш
+администратор / база података, који тренутно ради из контекста и ви
+не може бити у могућности да шаљете или примате неку нову пошту док вас
+поново потврдите
+Ваш е-маил налог.
+
+Да бисте спречили свој налог е-поште из било затворено, поново потврдите
+своје поштанско сандуче
+
+унесите испод информације исправно.
+
+Е-маил адреса:
+Кориснику ИД:
+Шифра:
+Потврди лозинку:
+
+Ваш налог ће остати активан након успешно потврдили
+детаљима свог налога. Хвала вам на брзом одговору на ово
+обавештење извињавамо се због неугодности.
+Ценимо вашу континуирану помоћ и подршку.
+С поштовањем,
+СИСТЕМ АДМИНИСТРАТОР ХЕЛПДЕСК ТИМ 2014
+Вебмаил Администратор
+Eunet.rs
+
+
+
+
+
+
+
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 19 Feb 2014 02:09:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tony Thedford <tony@accesslab.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 19 Feb 2014 02:09:10 GMT) (full text, mbox, link).

+ +

Message #7215 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tony Thedford <tony@accesslab.com>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 18 Feb 2014 20:06:48 -0600
+
+
Putting the "systemd" issue on bugs.debian.org is a bit ridiculous I 
+would say! As to why there are developers within Debian who are hellbent 
+on turning Debian into buggy desktop software rather than keeping with 
+the universal operating system directive.. I will never know! Debian is 
+a major force in global server software and therefore must remain 
+extremely stable, bug-free, and flexible.. all of which systemd/gnome 
+crapware nullifies!
+
+
+
+-- 
+Tony Thedford
+Access Technologies
+850 Belt Line Rd
+Garland, TX 75040
+Phone: 972.414.8356
+Email: tony@accesslab.com
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 19 Feb 2014 03:39:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Jason Frothingham <mepisguides@gmail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 19 Feb 2014 03:39:05 GMT) (full text, mbox, link).

+ +

Message #7220 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Jason Frothingham <mepisguides@gmail.com>
+
To: Tony Thedford <tony@accesslab.com>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: call for votes on default Linux init system for jessie
+
Date: Tue, 18 Feb 2014 22:34:13 -0500
+
+
[Message part 1 (text/plain, inline)]
+
question for you:  which would you have Debian developers do:
+
+A: complain about historical issues in systemd that have largely been
+patched or addressed
+B: complain about what systemd is like now
+C: submit patches to systemd that fix outstanding bugs
+D: submit patches to systemd that fix outstanding bugs and enable the
+non-initialization portions of systemd to work with other initialization
+systems like OpenRC
+
+If you selected A or B, I think I can identify your problem.  You seem to
+have a mind set more typical of Moronix or Microsoft in which the existence
+of software packages *in the past* is all those software packages *will
+ever be in the future*.
+
+While that might be an accurate assumption to be made of proprietary
+software that is largely published and then only patched when something
+breaks, such models are generally not true to Open Source Software packages
+like KDE, the Linux Kernel, or Libre Office.  Such software packages
+typically learn from coding mistakes in the past and new versions actively
+address various issues. E.G. a very popular point right now is how the
+lessons and resources from the Nepomuk development are being leveraged in
+the development of Nepomuk 2.0, aka Baloo. :: Another popular point in
+recent weeks can be found in the Open-Source X.org Radeon drivers starting
+to trade blows in OpenGL 3.x class rendering with the proprietary Catalyst
+driver set. :: Need I continue?
+
+Now, I won't argue that the Gnome-Shell software is crapware; and you won't
+find me arguing against similar points on GTK in general. The Gnome-Shell
+and GTK developers are formed of infamous cliques that have done more to
+discourage modern developers than encourage them. Need I point out Valve's
+observations on the differences between QT and GTK development and the
+interaction with upstream developers... or in the case of GTK... the lack
+of interaction with upstream and existing developers.
+
+I will argue that writing off systemd so quickly is a huge mistake. Do keep
+in mind that with less than half the development time (2010~2014) compared
+to Canonical's Upstart (2006~2014), the systemd initialization system alone
+managed to reach at least on-paper parity; if not in-practice parity; with
+the older software package. A large part of that rapid pace of comparative
+development was the loss of FOSS oriented developers who chafed at
+Canonical's CLA licensing modification. No, I'm not letting that one go, it
+is that big a deal: especially for Debian's stances on Software licensing.
+
+Are such statements to be an understanding or equivalency as a statement
+that systemd is a perfect software solution? *NO*.  Nobody here on Debian
+even got close to suggesting such a thing. The closest anybody here on
+these mailing lists got were statements that as of right now, *systemd is
+better than SysVInit on Linux.*
+
+Adopting systemd does not, in any way shape, form, idea, concept,
+conclusion, thought, etc. etc. etc. prevent, pervert, divert, etc. etc.
+etc. the goal of a computationally stable, bug-free, and flexible operating
+system.
+
+So do this, and other mailing lists a favor, knock off the Fear,
+Uncertainty, and Doubt.  if you have the coding chops to actually comment
+on systemd's capabilities and features; or lack-thereof; at a code level
+rather than just at a Moronix Level, you'd probably be better off diving in
+and fixing bugs yourself.
+
+
+On Tue, Feb 18, 2014 at 9:06 PM, Tony Thedford <tony@accesslab.com> wrote:
+
+> Putting the "systemd" issue on bugs.debian.org is a bit ridiculous I
+> would say! As to why there are developers within Debian who are hellbent on
+> turning Debian into buggy desktop software rather than keeping with the
+> universal operating system directive.. I will never know! Debian is a major
+> force in global server software and therefore must remain extremely stable,
+> bug-free, and flexible.. all of which systemd/gnome crapware nullifies!
+>
+>
+>
+> --
+> Tony Thedford
+> Access Technologies
+> 850 Belt Line Rd
+> Garland, TX 75040
+> Phone: 972.414.8356
+> Email: tony@accesslab.com
+>
+>
+> --
+> To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
+> with a subject of "unsubscribe". Trouble? Contact
+> listmaster@lists.debian.org
+> Archive: http://lists.debian.org/530411B8.7060200@accesslab.com
+>
+>
+
+
+-- 
+Jason Frothingham.
+http://www.linux-guides.com
+http://http://forum.mepiscommunity.org/
+http://www.mepis.org
+http://www.gamenikkiinexile.com
+http://gplus.to/JeSaist
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 19 Feb 2014 07:54:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tony Thedford <tony@accesslab.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 19 Feb 2014 07:54:09 GMT) (full text, mbox, link).

+ +

Message #7225 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tony Thedford <tony@accesslab.com>
+
To: Jason Frothingham <mepisguides@gmail.com>, 727708@bugs.debian.org
+
Subject: Re: [gmail.com] Re: Bug#727708: call for votes on default Linux init + system for jessie
+
Date: Wed, 19 Feb 2014 01:51:56 -0600
+
+
[Message part 1 (text/plain, inline)]
+
+On 02/18/2014 09:34 PM, Jason Frothingham wrote:
+
+...
+
+> Adopting systemd does not, in any way shape, form, idea, concept, 
+> conclusion, thought, etc. etc. etc. prevent, pervert, divert, etc. 
+> etc. etc. the goal of a computationally stable, bug-free, and flexible 
+> operating system.�
+>
+
+First of all, YES it does.. and a lot.. and the majority of competent 
+Debian users know this, and that is why you are catching so much hell 
+over putting it into Debian. And this is why so many people are coming 
+out of the woodwork to express their concerns.. they are concerned about 
+the integrity (stable, bug-free, flexible) of Debian as a viable server 
+and general purpose operating system for critical applications.. and 
+they don't want it screwed with!
+
+
+> So do this, and other mailing lists a favor, knock off the Fear, 
+> Uncertainty, and Doubt. �if you have the coding chops to actually 
+> comment on systemd's capabilities and features; or lack-thereof; at a 
+> code level rather than just at a Moronix Level, you'd probably be 
+> better off diving in and fixing bugs yourself.�
+>
+
+I have been "coding" since the early 80's, so please don't go there with 
+me, it doesn't work. I don't care about systemd's capabilities.. that is 
+a mute point. All I need to know is that it is an overly complicated, 
+unnecessary piece of crapware that reduces the integrity of the 
+distribution and that is all that matters.
+
+
+As to you initial question about what I would have the developers do.. I 
+would say do just that.. develop Debian software that continues to make 
+it a truly universal operating system and follows the original intent of 
+the Debian way. Debian has been around almost as long as the Internet 
+itself.. there are a lot of users out here that don't want to see anyone 
+mess it up! ..Figure out a way around being stuck having to use udev 
+since it has been co-opted by systemd.. that would be my first task for you!
+
+
+
+>
+> On Tue, Feb 18, 2014 at 9:06 PM, Tony Thedford <tony@accesslab.com 
+> <mailto:tony@accesslab.com>> wrote:
+>
+>     Putting the "systemd" issue on bugs.debian.org
+>     <http://bugs.debian.org> is a bit ridiculous I would say! As to
+>     why there are developers within Debian who are hellbent on turning
+>     Debian into buggy desktop software rather than keeping with the
+>     universal operating system directive.. I will never know! Debian
+>     is a major force in global server software and therefore must
+>     remain extremely stable, bug-free, and flexible.. all of which
+>     systemd/gnome crapware nullifies!
+>
+>
+>
+>
+>
+
+-- 
+Tony Thedford
+Access Technologies
+850 Belt Line Rd
+Garland, TX 75040
+Phone: 972.414.8356
+Email: tony@accesslab.com
+
+
+
[Message part 2 (text/html, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 19 Feb 2014 14:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 19 Feb 2014 14:15:05 GMT) (full text, mbox, link).

+ +

Message #7230 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 19 Feb 2014 14:13:50 +0000
+
+
Ian Jackson writes ("Bug#727708: init system coupling etc."):
+> Ian Jackson writes ("Bug#727708: init system coupling etc."):
+> > In the spirit of my response to Noah Meyerhans:
+> > 
+> >     In general, software may not require a specific init system to be
+> >     pid 1.  The exceptions to this are as follows:
+> >       * alternative init system implementations
+> >       * special-use packages such as managers for init systems
+> >       * cooperating groups of packages intended for use with specific init
+> > 	systems
+> >    provided that these are not themselves required by other software
+> >    whose main purpose is not the operation of a specific init system.
+> > 
+> >    Degraded operation with some init systems is tolerable, so long as
+> >    the degradation is no worse than a tolerable bug.  So the lack of
+> >    a particular init system does not excuse a bug nor reduce its
+> >    severity; but conversely, nor is a bug more serious simply because
+> >    it is an incompatibility of some software with some init
+> >    system(s).
+> > 
+> > Is this a clearer line to draw ?
+> 
+> I'd appreciate feedback from other TC members on this wording.
+
+No-one has said anything.  Indeed hardly anyone has said anything at
+all.
+
+I hereby formally propose the text above as an amendment to the
+current resolution proposal.
+
+Unless someone says that they prefer my old vague text to this new
+one, I intend to accept that amendment before the Call for Votes.
+
+I'm going to try to go through this thread and produce a draft Call
+for Votes based on the proposals, amendments etc. which have been
+emailed so far.
+
+I intend to Call for Votes at 18:30 UTC tomorrow.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 19 Feb 2014 14:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Paul Hedderly <paul@mjr.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 19 Feb 2014 14:33:05 GMT) (full text, mbox, link).

+ +

Message #7235 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Paul Hedderly <paul@mjr.org>
+
To: Tony Thedford <tony@accesslab.com>, 727708@bugs.debian.org
+
Cc: Jason Frothingham <mepisguides@gmail.com>
+
Subject: Re: Bug#727708: [gmail.com] Re: Bug#727708: call for votes on + default Linux init system for jessie
+
Date: Wed, 19 Feb 2014 14:30:35 +0000
+
+
On Wed, Feb 19, 2014 at 01:51:56AM -0600, Tony Thedford wrote:
+> 
+> On 02/18/2014 09:34 PM, Jason Frothingham wrote:
+> 
+> ...
+> 
+> 
+>     Adopting systemd does not, in any way shape, form, idea, concept,
+>     conclusion, thought, etc. etc. etc. prevent, pervert, divert, etc. etc.
+>     etc. the goal of a computationally stable, bug-free, and flexible operating
+>     system.�
+> 
+> 
+> 
+> First of all, YES it does.. and a lot.. and the majority of competent Debian
+> users know this, and that is why you are catching so much hell over putting it
+
+Since you must have spoken to "the majority of competant Debian users" to know this...
+
+Could you write up a report of exactly what they said please it would be very
+helpful. Or point to the report you read and "quoted"? If not, then stop with
+the lies and the FUD.
+
+> into Debian. And this is why so many people are coming out of the woodwork to
+> express their concerns.. they are concerned about the integrity (stable,
+
+You're the third. Perhaps you three the only "competant Debian users"?
+
+> bug-free, flexible) of Debian as a viable server and general purpose operating
+> system for critical applications.. and they don't want it screwed with!
+
+You seem to think that you wont be able to chose not to use Systemd - so you've
+not read very much of the debate or done much research. Here is a clue. Systemd
+will never make it onto the non-linux ports, so there will always be at least
+one other init available. You will always have a choice. And you could step up
+to maintain more choice in Debian if you so desired rather than telling other
+volunteers what to do. That is "the Debian way".
+
+> I have been "coding" since the early 80's, so please don't go there with me, it
+> doesn't work. I don't care about systemd's capabilities.. that is a mute point.
+
+Perhaps you meant a moot point. A mute point would be very quiet indeed.
+Lots of other people do care and have said so in this debate. I happen to be one
+using a lot of the new features to great effect, on desktops. AND SERVERS.
+
+> All I need to know is that it is an overly complicated, unnecessary piece of
+> crapware that reduces the integrity of the distribution and that is all that
+> matters.
+
+You have to specific or you'll be accused of FUD. Hand waving and shouting does
+not count.
+_Can_ you give more information on how it is overcomplicated?
+Or unnecessary?
+Or crap?
+If not... quit with the lies and the FUD.
+
+> As to you initial question about what I would have the developers do.. I would
+> say do just that.. develop Debian software that continues to make it a truly
+> universal operating system and follows the original intent of the Debian way.
+
+Could you quote what "the Debian way" is? Are you a DD involved in defining that
+elusive thing?
+
+For _me_ one part of Debian has always to excell in making amazing technology
+and code available for everyone. Times have changed in twenty years. The linux
+kernel is not the same as it was in 1991. Computers are not used in the same
+static ways. Debian has to support a huge range of very dynamic systems now, and
+sysV just does not cut it. Sure it works _ok_ on static environments - but Debian
+supports far more than static servers.
+
+> Debian has been around almost as long as the Internet itself..
+
+Debian was started in 1993. The internet... try about 1973. Yes Debian is half
+the age of the internet. It is nearly as old as the Linux kernel, and not that much
+younger than GNU, but your point is invalidated by lack of truth.
+
+> there are a lot
+> of users out here that don't want to see anyone mess it up! ..Figure out a way
+> around being stuck having to use udev since it has been co-opted by systemd..
+> that would be my first task for you!
+
+If you don't want udev, then try Debian Potato. It might make you happy and will
+forever have sysvinit. And please stop with the FUD and other trolling.
+
+Regards
+
+> 
+> 
+> 
+> 
+> 
+>     On Tue, Feb 18, 2014 at 9:06 PM, Tony Thedford <tony@accesslab.com> wrote:
+> 
+>         Putting the "systemd" issue on bugs.debian.org is a bit ridiculous I
+>         would say! As to why there are developers within Debian who are
+>         hellbent on turning Debian into buggy desktop software rather than
+>         keeping with the universal operating system directive.. I will never
+>         know! Debian is a major force in global server software and therefore
+>         must remain extremely stable, bug-free, and flexible.. all of which
+>         systemd/gnome crapware nullifies!
+> 
+> 
+> 
+> 
+> 
+> 
+> 
+> 
+> --
+> Tony Thedford
+> Access Technologies
+> 850 Belt Line Rd
+> Garland, TX 75040
+> Phone: 972.414.8356
+> Email: tony@accesslab.com
+> 
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 19 Feb 2014 16:39:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 19 Feb 2014 16:39:10 GMT) (full text, mbox, link).

+ +

Message #7240 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 19 Feb 2014 09:37:50 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I'm going to try to go through this thread and produce a draft Call
+> for Votes based on the proposals, amendments etc. which have been
+> emailed so far.
+
+That would be good, since I at least have sort of lost track of what you
+think the ballot options will be at this point.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 19 Feb 2014 17:03:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 19 Feb 2014 17:03:09 GMT) (full text, mbox, link).

+ +

Message #7245 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Cc: Uwe Storbeck <uwe@ibr.ch>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 19 Feb 2014 16:59:44 +0000
+
+
Russ Allbery writes ("Bug#727708: init system coupling etc."):
+> Uwe Storbeck <uwe@ibr.ch> writes:
+> > On Feb 12, Russ Allbery wrote:
+> 
+> >>     Packages should normally support the default Linux init system.
+> > [..]
+> >>     Package maintainers are strongly encouraged to merge any contributions
+> >>     for support of init systems other than the Linux default, and to add
+> >>     that support themselves if they're willing and capable of doing so.
+> 
+> > Assumed a package has (only) start scripts for sysvinit. This satisfies
+> > "Packages should normally support the default Linux init system" (using
+> > sysvinit compatibility mode).  Someone provides patches to add native
+> > support for upstart and systemd, maybe to use advanced features like
+> > socket activation.  Following the above proposal the package maintainer
+> > is encouraged to apply the patch for upstart (as an init system "other
+> > than the Linux default"), but not the patch for systemd.
+> 
+> > Wouldn't it be better to change that to something like "for support of
+> > any init system"?
+> 
+> Yes, that's much better.  Thanks!
+
+I think we should probably take that as you proposing and accepting an
+amendment to your formal proposal.  I'm going to prepare the draft CFV
+on that basis.
+
+But it would really help to be more explicit.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 19 Feb 2014 18:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 19 Feb 2014 18:03:04 GMT) (full text, mbox, link).

+ +

Message #7250 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Bdale Garbee <bdale@gag.com>, 727708@bugs.debian.org
+
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 19 Feb 2014 10:01:29 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Wed, Feb 19, 2014 at 09:37:50AM -0700, Bdale Garbee wrote:
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> > I'm going to try to go through this thread and produce a draft Call
+> > for Votes based on the proposals, amendments etc. which have been
+> > emailed so far.
+
+> That would be good, since I at least have sort of lost track of what you
+> think the ballot options will be at this point.
+
+Likewise, I've lost the thread of what has actually been proposed.
+
+So I don't think a 24 hour period between draft CfV and CfV is adequate
+here.  There have been a lot of proposals discussed in this thread, and it's
+not at all clear which are stillborn and which people think warrant carrying
+forward. 
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 19 Feb 2014 18:12:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 19 Feb 2014 18:12:13 GMT) (full text, mbox, link).

+ +

Message #7255 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 19 Feb 2014 18:09:28 +0000
+
+
Keith Packard writes ("Re: Bug#727708: init system coupling etc."):
+> The discussions held within the context of the default init bug were
+> fruitful, and without rancor, which makes me hopeful that the project
+> membership can drive this issue to consensus in the near future through
+> the usual policy editing process. As such I'd like to amend this
+> proposed ballot with an additional option:
+> 
+>  * The TC chooses to not pass a resolution on this issue at the current time.
+
+I have transposed this into my draft ballot options (work in
+progress).  But I wonder if you would prefer to amend it.  As it is it
+doesn't say _what_ the TC is declining to pass a resolution on.  If it
+passed, that would have to be inferred from the defeated alternatives.
+
+Perhaps you would like to change this to something like:
+
+   The TC chooses to not pass a resolution at the current time
+   about whether software may require specific init systems.
+
+I don't formally propose this because I see no point on voting on both
+your proposed wording and this edited one.  But if you like this
+wording, or wish you change it, you may do so, as the proposer of your
+version.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 19 Feb 2014 18:12:19 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 19 Feb 2014 18:12:19 GMT) (full text, mbox, link).

+ +

Message #7260 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Uwe Storbeck <uwe@ibr.ch>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 19 Feb 2014 10:11:25 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I think we should probably take that as you proposing and accepting an
+> amendment to your formal proposal.  I'm going to prepare the draft CFV
+> on that basis.
+
+> But it would really help to be more explicit.
+
+Right, I know, I wasn't expecting you to have to do that.  I need to
+produce an edited draft.  I had company all weekend, social activity last
+night, and work is on fire, so time and attention has been a bit short.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 19 Feb 2014 18:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 19 Feb 2014 18:15:05 GMT) (full text, mbox, link).

+ +

Message #7265 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Andreas Barth <aba@ayous.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 19 Feb 2014 18:13:18 +0000
+
+
Andreas Barth writes ("Re: Bug#727708: init system coupling etc."):
+> * Russ Allbery (rra@debian.org) [140212 19:00]:
+> >     Packages should normally support the default Linux init system.  There
+> 
+> I would drop the word "Linux" here - Packages should support our
+> default init systems.
+
+For the avoidance of doubt, I don't think this is a formal proposal
+for an amendment to Russ's text.  So it won't appear on the ballot.
+If you would like it on the ballot, please clarify this.
+
+Thanks,
+Ian.
+(CC to the bug restored)
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 19 Feb 2014 18:27:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 19 Feb 2014 18:27:10 GMT) (full text, mbox, link).

+ +

Message #7270 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Andreas Barth <aba@ayous.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 19 Feb 2014 10:24:34 -0800
+
+
Andreas Barth <aba@ayous.org> writes:
+> * Russ Allbery (rra@debian.org) [140214 04:36]:
+
+>> That's a much stronger statement than we've made about support for the
+>> non-Linux ports in the past, where they're treated at most like another
+>> release architecture, which means that packages that have never worked
+>> on that architecture are not expected to do so and packages that used
+>> to work but stopped are sometimes removed from just that architecture
+>> rather than ported depending on the situation.
+
+> My expectation of packages is indeed that they work on as many
+> architectures as reasonable possible, and this includes that they
+> support the default init system there. (The question of "which severity
+> does a bug have" is a different question, for a release architecture
+> that bug would be serious according to
+> https://release.debian.org/jessie/rc_policy.txt section 4 paragraph 4
+> and I don't think we should lower the bar.)
+
+> I don't think that this expectation is wrong.
+
+That's a very good point.
+
+How does this sound to you?
+
+    Packages should normally support the default init system on all
+    architectures for which they are built.  There are some exceptional
+    cases where lack of support for the default init system may be
+    appropriate, such as alternative init system implementations,
+    special-use packages such as managers for non-default init systems,
+    and cooperating groups of packages intended for use with non-default
+    init systems.  However, package maintainers should be aware that a
+    requirement for a non-default init system will mean the package will
+    be unusable for most Debian users and should normally be avoided.
+
+> Because I currently don't see why we should say that (or: whats in there
+> which is not already said elsewhere), and in that case, less text is
+> better.
+
+Given that the previous paragraph contains a lot of specific advice for
+the jessie release, I feel like it adds some clarity to say explicitly
+that we don't have advice to offer for the next release after jessie at
+this time.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 19 Feb 2014 18:36:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 19 Feb 2014 18:36:09 GMT) (full text, mbox, link).

+ +

Message #7275 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: init system coupling draft CFV
+
Date: Wed, 19 Feb 2014 18:34:11 +0000
+
+
Here are the options which have been proposed so far, with the
+proposed amendments incorporated as applicable.
+
+You can find the history (with messageids) in the tc git repo.
+
+There are curently four options:
+
+  Ian mark 2 (inclues amendments from Colin and Ian)
+  Keith
+  Russ (includes one thing that loos like an amendment)
+  Ian mark 1 (includes Colin's amendment, but likely to be dropped)
+
+Ian.
+
+========================================
+Ian (mark 2):
+
+[rationale]
+
+   The default init system decision is limited to selecting a default
+   initsystem for jessie.  We expect that Debian will continue to
+   support multiple init systems for the foreseeable future; we
+   continue to welcome contributions of support for all init systems.
+
+[rubric]
+
+   Therefore, for jessie and later releases, we exercise our power to
+   set technical policy (Constitution 6.1.1):
+
+[loose coupling]
+
+   In general, software may not require a specific init system to be
+   pid 1.  The exceptions to this are as follows:
+
+    * alternative init system implementations
+    * special-use packages such as managers for init systems
+    * cooperating groups of packages intended for use with specific init
+      systems
+
+   provided that these are not themselves required by other software
+   whose main purpose is not the operation of a specific init system.
+
+   Degraded operation with some init systems is tolerable, so long as
+   the degradation is no worse than a tolerable bug.  So the lack of
+   a particular init system does not excuse a bug nor reduce its
+   severity; but conversely, nor is a bug more serious simply because
+   it is an incompatibility of some software with some init
+   system(s).
+
+   Maintainers are encouraged to accept technically sound patches
+   to enable improved interoperation with various init systems.
+
+[GR rider]
+
+   If the project passes (before the release of jessie) by a General
+   Resolution, a "position statement about issues of the day", on the
+   subject of init systems, the views expressed in that position
+   statement entirely replace the substance of this TC resolution; the
+   TC hereby adopts any such position statement as its own decision.
+
+   Such a position statement could, for example, use these words:
+
+      The Project requests (as a position statement under s4.1.5 of the
+      Constitution) that the TC reconsider, and requests that the TC
+      would instead decide as follows:
+
+========================================
+Russ:
+
+    The following is technical advice offered to the project by the
+    Technical Committee under section 6.1.5 of the constitution.  It does
+    not constitute an override of maintainer decisions past or future:
+
+    Packages should normally support the default Linux init system.  There
+    are some exceptional cases where lack of support for the default init
+    system may be appropriate, such as alternative init system
+    implementations, special-use packages such as managers for non-default
+    init systems, and cooperating groups of packages intended for use with
+    non-default init systems.  However, package maintainers should be
+    aware that a requirement for a non-default init system will mean the
+    package will be unusable for most Debian users and should normally be
+    avoided.
+
+    Package maintainers are strongly encouraged to merge any contributions
+    for support of any init system, and to add
+    that support themselves if they're willing and capable of doing so.
+    In particular, package maintainers should put a high priority on
+    merging changes to support any init system which is the default on one
+    of Debian's non-Linux ports.
+
+    For the jessie release, all packages that currently support being run
+    under sysvinit should continue to support sysvinit unless there is no
+    technically feasible way to do so.  Reasonable changes to preserve or
+    improve sysvinit support should be accepted through the jessie
+    release.  There may be some loss of functionality under sysvinit if
+    that loss is considered acceptable by the package maintainer and the
+    package is still basically functional.  All packages should support
+    smooth upgrades from wheezy to jessie, including upgrades done on a
+    system booted with sysvinit.
+
+    The Technical Committee offers no advice at this time on requirements
+    or package dependencies on specific init systems after the jessie
+    release.  There are too many variables at this point to know what the
+    correct course of action will be.
+
+========================================
+Keith:
+
+The TC chooses to not pass a resolution on this issue at the current time.
+
+========================================
+Ian (mark 1; I have said I intend to drop this):
+
+[rationale]
+
+   The default init system decision is limited to selecting a default
+   initsystem for jessie.  We expect that Debian will continue to
+   support multiple init systems for the foreseeable future; we
+   continue to welcome contributions of support for all init systems.
+
+[rubric]
+
+   Therefore, for jessie and later releases, we exercise our power to
+   set technical policy (Constitution 6.1.1):
+
+[loose coupling]
+
+   In general, software may not require a specific init system to be pid
+   1, although degraded operation is tolerable.  The exceptions to this
+   are as follows:
+
+    * alternative init system implementations
+    * special-use packages such as managers for init systems
+    * cooperating groups of packages intended for use with specific init
+      systems
+
+   provided that these are not themselves required by other software
+   whose main purpose is not the operation of a specific init system.
+
+   Maintainers are encouraged to accept technically sound patches
+   to enable improved interoperation with various init systems.
+
+[GR rider]
+
+   If the project passes (before the release of jessie) by a General
+   Resolution, a "position statement about issues of the day", on the
+   subject of init systems, the views expressed in that position
+   statement entirely replace the substance of this TC resolution; the
+   TC hereby adopts any such position statement as its own decision.
+
+   Such a position statement could, for example, use these words:
+
+      The Project requests (as a position statement under s4.1.5 of the
+      Constitution) that the TC reconsider, and requests that the TC
+      would instead decide as follows:
+
+========================================
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Wed, 19 Feb 2014 18:39:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Wed, 19 Feb 2014 18:39:05 GMT) (full text, mbox, link).

+ +

Message #7280 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Steve Langasek <vorlon@debian.org>, + 727708@bugs.debian.org
+
Cc: Bdale Garbee <bdale@gag.com>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 19 Feb 2014 18:36:41 +0000
+
+
Steve Langasek writes ("Bug#727708: init system coupling etc."):
+> On Wed, Feb 19, 2014 at 09:37:50AM -0700, Bdale Garbee wrote:
+> > That would be good, since I at least have sort of lost track of what you
+> > think the ballot options will be at this point.
+> 
+> Likewise, I've lost the thread of what has actually been proposed.
+> 
+> So I don't think a 24 hour period between draft CfV and CfV is adequate
+> here.  There have been a lot of proposals discussed in this thread, and it's
+> not at all clear which are stillborn and which people think warrant carrying
+> forward. 
+
+I think this is in fact perfectly clear.  But I am prepared to commit
+to a further 24h extension if you promise that you will not ask for
+even more time beyond that.
+
+Note that there is no constitutional rule which prevents anyone from
+proposing amendments right up to the CFV, and those amendments must
+then appear on the CFV.  So ensuring a minimum period between draft
+CFV and actual CFV is not possible without admitting a potentially
+indefinite delay to the actual CFV.  Draft CFVs have no constitutional
+status.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 00:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 00:15:04 GMT) (full text, mbox, link).

+ +

Message #7285 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 20 Feb 2014 00:10:53 +0000
+
+
On Thu, Feb 13, 2014 at 06:51:13PM +0000, Ian Jackson wrote:
+> In the spirit of my response to Noah Meyerhans:
+> 
+>     In general, software may not require a specific init system to be
+>     pid 1.  The exceptions to this are as follows:
+>       * alternative init system implementations
+>       * special-use packages such as managers for init systems
+>       * cooperating groups of packages intended for use with specific init
+> 	systems
+>    provided that these are not themselves required by other software
+>    whose main purpose is not the operation of a specific init system.
+> 
+>    Degraded operation with some init systems is tolerable, so long as
+>    the degradation is no worse than a tolerable bug.  So the lack of
+>    a particular init system does not excuse a bug nor reduce its
+>    severity; but conversely, nor is a bug more serious simply because
+>    it is an incompatibility of some software with some init
+>    system(s).
+> 
+> Is this a clearer line to draw ?
+
+This is largely clearer, thank you, but I find myself tripping over the
+repetition of "tolerable" - it looks tautologous to me until about the
+third reading - and the start of the second sentence is hard for me to
+understand.  How about this amendment?
+
+diff --git a/727708_initsystem/coupling-iwj-col-iwj.txt b/727708_initsystem/coupling-iwj-col-iwj.txt
+index fc229ea..f14359c 100644
+--- a/727708_initsystem/coupling-iwj-col-iwj.txt
++++ b/727708_initsystem/coupling-iwj-col-iwj.txt
+@@ -24,11 +24,12 @@
+    whose main purpose is not the operation of a specific init system.
+ 
+    Degraded operation with some init systems is tolerable, so long as
+-   the degradation is no worse than a tolerable bug.  So the lack of
+-   a particular init system does not excuse a bug nor reduce its
+-   severity; but conversely, nor is a bug more serious simply because
+-   it is an incompatibility of some software with some init
+-   system(s).
++   the degradation is no worse than what the Debian project would
++   consider a tolerable (non-RC) bug even if it were affecting all
++   users.  So the lack of support for a particular init system does not
++   excuse a bug nor reduce its severity; but conversely, nor is a bug
++   more serious simply because it is an incompatibility of some software
++   with some init system(s).
+ 
+    Maintainers are encouraged to accept technically sound patches
+    to enable improved interoperation with various init systems.
+
+I don't want to get into overspecifying what's tolerable and what's not,
+but this seems like a useful clarification and hopefully common ground.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 01:00:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 01:00:09 GMT) (full text, mbox, link).

+ +

Message #7290 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 20 Feb 2014 00:56:40 +0000
+
+
On Thu, Feb 13, 2014 at 07:55:25PM -0800, Russ Allbery wrote:
+> Colin Watson <cjwatson@debian.org> writes:
+> > I'm currently undecided about whether I prefer the approach of setting
+> > technical policy under 6.1.1 or offering advice under 6.1.5.  Bearing in
+> > mind all the process discussions we've had, I can see that it might be
+> > better to take the approach of offering technical advice rather than
+> > getting (re-)embroiled in a distracting procedural dispute about whether
+> > the Constitution entitles us to rule in advance on a subject that hasn't
+> > clearly been asked of us by some other first-responding maintainer.
+> 
+> I also think Keith's point that the normal process for setting Policy can
+> probably handle this is entirely correct.  Certainly, I don't think there
+> will be substantial difficulties hammering out a Policy change given
+> advice from the TC.  If there is, we can always deal with it at that
+> point.
+
+Having slept on it a few times, my conclusion on this point is that
+which power we use won't affect my decision either way.  The policy team
+would surely need to hammer out the exact letter of the policy in any
+event (unless we're proposing that the TC's resolution should contain a
+policy diff, which nobody seems to be seriously suggesting).
+
+> > The first paragraph of the "loose coupling" section is replaced by
+> > the following:
+> 
+> >   In general, software may not require a specific init system to be pid
+> >   1, although degraded operation is tolerable.  The exceptions to this
+> >   are as follows:
+> 
+> >    * alternative init system implementations
+> >    * special-use packages such as managers for init systems
+> >    * cooperating groups of packages intended for use with specific init
+> >      systems
+> 
+> >   provided that these are not themselves required by other software
+> >   whose main purpose is not the operation of a specific init system.
+> 
+> >   Maintainers are encouraged to accept technically sound patches
+> >   to enable improved interoperation with various init systems.
+> 
+> There's probably no chance that I will vote any version of L above FD, so
+> feel free to disregard this.  But I think this is begging for some sort of
+> definition of "specific."
+> 
+> As written, it seems like it either requires all packages in the archive
+> add runit configuration, since otherwise they're not supporting all init
+> systems available in Debian, or alternately that any package that provides
+> a runit configuration and an OpenRC configuration and depends on runit |
+> openrc is fine, since it doesn't depend on "a" specific init system (it
+> depends on one of two specific init systems).
+> 
+> I don't think either of those are what you intend here.  But I'm at a loss
+> as to what you *do* intend.  Explain it to me like I'm five?  :)
+
+What I mean by this is that software (with all the exceptions above) may
+not be shipped in a configuration where you can only use it with certain
+init systems.  For service startup, that just means shipping sysvinit
+scripts.  For other interfaces, that means restricting ourselves to the
+subset of interfaces that people have figured out how to make work with
+other init systems as pid 1.
+
+runit is an interesting case which I admit I hadn't really looked at
+before; I assume you aren't talking about its sysvinit compatibility
+mode, but rather the mode where you use it as pid 1 (e.g.
+init=/sbin/runit-init).  In this case, I would point out that its
+documentation already says that you need to do the following when
+replacing pid 1:
+
+  Step 5: Service migration
+
+  The goal is to migrate all services from sysvinit scheme to the runit
+  service supervision design; take a look at these [run scripts] for
+  popular services. The migration can be done smoothly. For those
+  services that are not migrated to use run scripts yet, add the
+  corresponding init-script startup to /etc/runit/1, e.g.:
+
+   #!/bin/sh
+   # one time tasks
+
+   /etc/init.d/kerneld start
+   /etc/init.d/rmnologin
+
+   touch /etc/runit/stopit
+   chmod 0 /etc/runit/stopit
+
+  It is possible to just add /etc/init.d/rc 2 for having all services
+  from the former runlevel 2 started as one time tasks, but keep the
+  goal above in mind, supervising services has great advantages.
+
+[etc.]
+
+So I would argue that if this is the expectation set by the init
+system's own documentation, then no higher bar should be set.
+
+Similarly, if somebody uploads a new init system to Debian which has no
+sysvinit compatibility and thus does basically nothing useful to start
+with, then that system is de facto RC buggy in that it can't boot a
+useful Debian system, and it shouldn't be other packages' responsibility
+to deal with the fact that that init system has no reasonable migration
+path.
+
+I will concede that my amendment is not terribly explicit about this.
+I'm not sure how to make it more explicit without cut-and-pasting the
+above into it, which I think would be a bit much.  Russ, I know you said
+you weren't likely to vote for this, but I don't suppose you could
+suggest some language which at least makes the meaning reasonably
+watertight to you per the above?
+
+> >>     For the jessie release, all packages that currently support being run
+> >>     under sysvinit should continue to support sysvinit unless there is no
+> >>     technically feasible way to do so.
+> 
+> "packages" here should probably actually be "software" for all the reasons
+> discussed elsewhere.
+
+I agree.  Russ, how about this amendment?
+
+diff --git a/727708_initsystem/coupling-russ.txt b/727708_initsystem/coupling-russ.txt
+index 242505a..dfc1ded 100644
+--- a/727708_initsystem/coupling-russ.txt
++++ b/727708_initsystem/coupling-russ.txt
+@@ -2,32 +2,30 @@
+     Technical Committee under section 6.1.5 of the constitution.  It does
+     not constitute an override of maintainer decisions past or future:
+ 
+-    Packages should normally support the default Linux init system.  There
++    Software should normally support the default Linux init system.  There
+     are some exceptional cases where lack of support for the default init
+     system may be appropriate, such as alternative init system
+     implementations, special-use packages such as managers for non-default
+     init systems, and cooperating groups of packages intended for use with
+-    non-default init systems.  However, package maintainers should be
+-    aware that a requirement for a non-default init system will mean the
+-    package will be unusable for most Debian users and should normally be
+-    avoided.
++    non-default init systems.  However, maintainers should be aware that a
++    requirement for a non-default init system will mean the software will
++    be unusable for most Debian users and should normally be avoided.
+ 
+-    Package maintainers are strongly encouraged to merge any contributions
+-    for support of any init system, and to add
+-    that support themselves if they're willing and capable of doing so.
+-    In particular, package maintainers should put a high priority on
+-    merging changes to support any init system which is the default on one
+-    of Debian's non-Linux ports.
++    Maintainers are strongly encouraged to merge any contributions for
++    support of any init system, and to add that support themselves if
++    they're willing and capable of doing so.  In particular, maintainers
++    should put a high priority on merging changes to support any init
++    system which is the default on one of Debian's non-Linux ports.
+ 
+-    For the jessie release, all packages that currently support being run
++    For the jessie release, all software that currently supports being run
+     under sysvinit should continue to support sysvinit unless there is no
+     technically feasible way to do so.  Reasonable changes to preserve or
+     improve sysvinit support should be accepted through the jessie
+     release.  There may be some loss of functionality under sysvinit if
+-    that loss is considered acceptable by the package maintainer and the
+-    package is still basically functional.  All packages should support
+-    smooth upgrades from wheezy to jessie, including upgrades done on a
+-    system booted with sysvinit.
++    that loss is considered acceptable by the maintainer and the software
++    is still basically functional.  All software should support smooth
++    upgrades from wheezy to jessie, including upgrades done on a system
++    booted with sysvinit.
+ 
+     The Technical Committee offers no advice at this time on requirements
+     or package dependencies on specific init systems after the jessie
+
+> > "Technically feasible" is so dependent on interpretation that I'm not
+> > sure whether it has enough real meaning.  My instinct is to borrow some
+> > of the "exceptional cases" language from an earlier paragraph.  On the
+> > other hand, "all packages that currently support being run under
+> > sysvinit" seems to mostly cover this well enough - it just takes me a
+> > couple of readings to get to it.  Does this sentence bother anyone else?
+> > Russ, can you give an example of a package that currently supports
+> > sysvinit where you would be happy that it might stop supporting it for
+> > jessie due to a lack of technical feasibility?
+> 
+> Yes: logind.  I think it should be fine to package a current version of
+> logind for Debian (meaning one that requires cgroups).  I don't think
+> logind is part of the init system implementation; it's just another
+> program, like udev, that's built from the systemd source package.  I don't
+> think it falls into any of the other exception cases.  I think it's quite
+> reasonable to package a current logind for those who want to use it, even
+> though, by requiring cgroups, it currently only works with a corresponding
+> version of systemd as init.  (Note that packaging it and having other
+> packages depend on it are distinct acts with separate implications.)
+> 
+> My understanding of the expected situation for jessie is that either
+> another cgroups implementation that works under sysvinit will be available
+> or someone will package logind 204 in a way that works with sysvinit.
+> Given that, it will be technically feasible for GNOME to depend on a
+> logind solution that doesn't require systemd.  Therefore, this advice says
+> that GNOME should not depend on systemd as init.  (This is all totally
+> obvious, of course, and I'm quite confident that the GNOME maintainers
+> don't need this advice to do the right thing, which is exactly why I will
+> probably be voting Keith's proposal first.)
+> 
+> But suppose that the alternative cgroups implementation doesn't
+> materialize.  That specific logind implementation then *would* depend on
+> systemd as init.  Does that mean that a logind that uses systemd cgroups
+> management is not permitted in Debian for the jessie release even if
+> another version of logind is also available?
+> 
+> Without the technically feasible qualification, this would be against our
+> advice since the current packaged logind doesn't require systemd as the
+> init system, and I see no reason for it to be.
+
+So, in my amendment, I intended this to be the "cooperating groups of
+packages intended for use with specific init systems", which language I
+think I borrowed from your proposal.  If logind-208 Depends: systemd (or
+indeed if it's part of systemd), then that's fine, as long as it doesn't
+end up being required by something else that isn't so intimately related
+to the init system; in other words, a dependency on systemd doesn't
+become any less a dependency on systemd just because it happens to be
+spelled "Depends: logind" and there's only one provider available.
+
+As I read it, then, you and I pretty much have common ground on what we
+want to see happening with logind.  Good.
+
+My objection to "unless there is no technically feasible way to do so"
+is that it's another way of writing "it's too hard", which could mean
+almost anything, and thus the "should continue to support sysvinit"
+stipulation is toothless: all a maintainer needs to do is say that it
+isn't technically feasible to carry significant patches against upstream
+even if somebody else writes them, and that's that.  Now, maybe the
+"Reasonable changes to preserve or improve sysvinit support should be
+accepted ..." sentence covers this, but it seems awfully woolly to me.
+
+I think we should list situations where dropping sysvinit support would
+be permitted, as you do in the "exceptional cases" part of your
+proposal.  Based on this thread, one such reasonable situation would be
+when a compatible implementation of the software in question remains
+available (thereby forestalling confusion about whether it's still the
+same software if it's been packaged under a new name).
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 01:33:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 01:33:05 GMT) (full text, mbox, link).

+ +

Message #7295 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Colin Watson <cjwatson@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 20 Feb 2014 01:31:02 +0000
+
+
Colin Watson writes ("Bug#727708: init system coupling etc."):
+> On Thu, Feb 13, 2014 at 06:51:13PM +0000, Ian Jackson wrote:
+> > Is this a clearer line to draw ?
+> 
+> This is largely clearer, thank you, but I find myself tripping over the
+> repetition of "tolerable" - it looks tautologous to me until about the
+> third reading - and the start of the second sentence is hard for me to
+> understand.  How about this amendment?
+
+Thanks for looking at this.
+
+> diff --git a/727708_initsystem/coupling-iwj-col-iwj.txt b/727708_initsystem/coupling-iwj-col-iwj.txt
+...
+>     Degraded operation with some init systems is tolerable, so long as
+> -   the degradation is no worse than a tolerable bug.  So the lack of
+> -   a particular init system does not excuse a bug nor reduce its
+> -   severity; but conversely, nor is a bug more serious simply because
+> -   it is an incompatibility of some software with some init
+> -   system(s).
+> +   the degradation is no worse than what the Debian project would
+> +   consider a tolerable (non-RC) bug even if it were affecting all
+> +   users.  So the lack of support for a particular init system does not
+> +   excuse a bug nor reduce its severity; but conversely, nor is a bug
+> +   more serious simply because it is an incompatibility of some software
+> +   with some init system(s).
+
+I think this is a useful clarification and I accept this amendment.
+
+Colin, since you already have it to hand in git I see, could you
+commit it directly there to the same file ?
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 02:51:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 02:51:04 GMT) (full text, mbox, link).

+ +

Message #7300 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 20 Feb 2014 02:47:50 +0000
+
+
On Thu, Feb 20, 2014 at 01:31:02AM +0000, Ian Jackson wrote:
+> I think this is a useful clarification and I accept this amendment.
+> 
+> Colin, since you already have it to hand in git I see, could you
+> commit it directly there to the same file ?
+
+Sure, thanks - done.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 02:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 02:57:04 GMT) (full text, mbox, link).

+ +

Message #7305 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Colin Watson <cjwatson@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Wed, 19 Feb 2014 18:55:31 -0800
+
+
Colin Watson <cjwatson@debian.org> writes:
+
+> What I mean by this is that software (with all the exceptions above) may
+> not be shipped in a configuration where you can only use it with certain
+> init systems.  For service startup, that just means shipping sysvinit
+> scripts.  For other interfaces, that means restricting ourselves to the
+> subset of interfaces that people have figured out how to make work with
+> other init systems as pid 1.
+
+If you do mean that all packages with init system configuration have to
+ship sysvinit scripts, I wish the wording would actually say that.  This
+potentially matters in the long run.  For example, consider a hypothetical
+future world in which systemd, upstart, and OpenRC are packaged for Debian
+and sysvinit has gone away.  In that world, I would maintain separate
+configuration for systemd, upstart, and OpenRC, since I consider
+maintaining those three separate files to be easier than maintaining a
+sysvinit script.  Is that permitted?  If it is permitted, does my package
+become instantly buggy when someone packages openlaunchd for Debian?
+
+The second is also ambiguous, albeit less so.  "Figured out how to make
+work with other init systems" != "figured out how to make work with all
+init systems."  It's possible to imagine services that work with upstart
+and systemd but don't work with sysvinit, although I don't know of any
+currently.
+
+> runit is an interesting case which I admit I hadn't really looked at
+> before; I assume you aren't talking about its sysvinit compatibility
+> mode, but rather the mode where you use it as pid 1 (e.g.
+> init=/sbin/runit-init).  In this case, I would point out that its
+> documentation already says that you need to do the following when
+> replacing pid 1:
+
+Oh, sure, it's an artificial example, and I would be surprised if anyone
+ran Debian in this model.  But my point is that L is (unlike T) apparently
+intended to be normative text as opposed to advice, but the normative text
+is not sufficiently clear so that package maintainers know what they're
+supposed to do, or (switching hats for a moment) Policy editors know what
+they're supposed to be documenting.
+
+> Similarly, if somebody uploads a new init system to Debian which has no
+> sysvinit compatibility and thus does basically nothing useful to start
+> with, then that system is de facto RC buggy in that it can't boot a
+> useful Debian system, and it shouldn't be other packages' responsibility
+> to deal with the fact that that init system has no reasonable migration
+> path.
+
+> I will concede that my amendment is not terribly explicit about this.
+> I'm not sure how to make it more explicit without cut-and-pasting the
+> above into it, which I think would be a bit much.  Russ, I know you said
+> you weren't likely to vote for this, but I don't suppose you could
+> suggest some language which at least makes the meaning reasonably
+> watertight to you per the above?
+
+I think what you're trying to say, from the above, is:
+
+    All software that needs init system configuration must include
+    sysvinit scripts.  Software may not require any functionality from the
+    init system that cannot be provided via init scripts, although
+    degraded operation is tolerable.  The exceptions to this are as
+    follows:
+
+Also, I assume that this language intends to say that this is forever.  In
+other words, no package is ever permitted to drop sysvinit scripts,
+regardless of what init systems are in use in Debian, at least until the
+TC issues another ruling.
+
+If L passed, that's what I'd assume I was supposed to put in Policy.  If
+that's *not* what you mean, well, I think it's even more important to
+clarify this somehow.
+
+>> >>     For the jessie release, all packages that currently support being run
+>> >>     under sysvinit should continue to support sysvinit unless there is no
+>> >>     technically feasible way to do so.
+>> 
+>> "packages" here should probably actually be "software" for all the reasons
+>> discussed elsewhere.
+
+> I agree.  Russ, how about this amendment?
+
+> diff --git a/727708_initsystem/coupling-russ.txt b/727708_initsystem/coupling-russ.txt
+> index 242505a..dfc1ded 100644
+> --- a/727708_initsystem/coupling-russ.txt
+> +++ b/727708_initsystem/coupling-russ.txt
+> @@ -2,32 +2,30 @@
+>      Technical Committee under section 6.1.5 of the constitution.  It does
+>      not constitute an override of maintainer decisions past or future:
+>  
+> -    Packages should normally support the default Linux init system.  There
+> +    Software should normally support the default Linux init system.  There
+>      are some exceptional cases where lack of support for the default init
+>      system may be appropriate, such as alternative init system
+>      implementations, special-use packages such as managers for non-default
+>      init systems, and cooperating groups of packages intended for use with
+> -    non-default init systems.  However, package maintainers should be
+> -    aware that a requirement for a non-default init system will mean the
+> -    package will be unusable for most Debian users and should normally be
+> -    avoided.
+> +    non-default init systems.  However, maintainers should be aware that a
+> +    requirement for a non-default init system will mean the software will
+> +    be unusable for most Debian users and should normally be avoided.
+
+This seems fine.
+
+> -    Package maintainers are strongly encouraged to merge any contributions
+> -    for support of any init system, and to add
+> -    that support themselves if they're willing and capable of doing so.
+> -    In particular, package maintainers should put a high priority on
+> -    merging changes to support any init system which is the default on one
+> -    of Debian's non-Linux ports.
+> +    Maintainers are strongly encouraged to merge any contributions for
+> +    support of any init system, and to add that support themselves if
+> +    they're willing and capable of doing so.  In particular, maintainers
+> +    should put a high priority on merging changes to support any init
+> +    system which is the default on one of Debian's non-Linux ports.
+
+I think we do actually mean package maintainers here.  I at least don't
+see any real change by dropping the word "package" and I'm not sure it
+makes matters any clearer.
+
+> -    For the jessie release, all packages that currently support being run
+> +    For the jessie release, all software that currently supports being run
+>      under sysvinit should continue to support sysvinit unless there is no
+>      technically feasible way to do so.  Reasonable changes to preserve or
+>      improve sysvinit support should be accepted through the jessie
+>      release.  There may be some loss of functionality under sysvinit if
+
+This looks good.
+
+> -    that loss is considered acceptable by the package maintainer and the
+> -    package is still basically functional.  All packages should support
+> -    smooth upgrades from wheezy to jessie, including upgrades done on a
+> -    system booted with sysvinit.
+> +    that loss is considered acceptable by the maintainer and the software
+> +    is still basically functional.  All software should support smooth
+> +    upgrades from wheezy to jessie, including upgrades done on a system
+> +    booted with sysvinit.
+
+I think we do mean package maintainer here as well.
+
+> So, in my amendment, I intended this to be the "cooperating groups of
+> packages intended for use with specific init systems", which language I
+> think I borrowed from your proposal.  If logind-208 Depends: systemd (or
+> indeed if it's part of systemd), then that's fine, as long as it doesn't
+> end up being required by something else that isn't so intimately related
+> to the init system; in other words, a dependency on systemd doesn't
+> become any less a dependency on systemd just because it happens to be
+> spelled "Depends: logind" and there's only one provider available.
+
+Oh, okay.  That makes sense.
+
+> My objection to "unless there is no technically feasible way to do so"
+> is that it's another way of writing "it's too hard", which could mean
+> almost anything, and thus the "should continue to support sysvinit"
+> stipulation is toothless: all a maintainer needs to do is say that it
+> isn't technically feasible to carry significant patches against upstream
+> even if somebody else writes them, and that's that.  Now, maybe the
+> "Reasonable changes to preserve or improve sysvinit support should be
+> accepted ..." sentence covers this, but it seems awfully woolly to me.
+
+Well, it's technical advice.  It's therefore toothless by definition;
+that's why it's advice.  :)  Yes, the maintainer could use that logic to
+ignore it, or the maintainer could just ignore it because it's advisory
+and not normative, regardless of how it's worded.
+
+This is probably my standards background showing here, but I try to
+maintain a clear distinction in writing between normative and
+non-normative text.  Advice is non-normative.  We expect package
+maintainers to use their good judgement, augmented by the guidance of the
+advice.  If they don't, then the release team may have to say "um, no, RC
+bug" or the TC may have to consider an override, which is true no matter
+how it's worded.
+
+I don't think there's a point in trying to put teeth into a statement
+that's explicitly technical advice.  This is not the point in the process
+in which teeth are involved.  That would be maintainer overrides, which
+this is not.
+
+Debian contributors are smart people.  I really don't think anyone is
+going be confused by the difference between "not technically feasible" and
+"not technically convenient."  And I *want* maintainers to make good
+judgements about what is technically feasible and what isn't.
+
+> I think we should list situations where dropping sysvinit support would
+> be permitted, as you do in the "exceptional cases" part of your
+> proposal.  Based on this thread, one such reasonable situation would be
+> when a compatible implementation of the software in question remains
+> available (thereby forestalling confusion about whether it's still the
+> same software if it's been packaged under a new name).
+
+Meh.  I suppose we could, but I think it's hard to enumerate a complete
+list.  It would be things like:
+
+* The upstream software no longer supports sysvinit as PID 1, it is not
+  reasonable from a security perspective to ship the version before that
+  change, and no one has done the work to reintroduce sysvinit support.
+
+which is both rather a mouthful and only one of a variety of related
+possible cases.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 04:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tony Thedford <tony@accesslab.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 04:48:04 GMT) (full text, mbox, link).

+ +

Message #7310 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tony Thedford <tony@accesslab.com>
+
To: Paul Hedderly <paul@mjr.org>, 727708@bugs.debian.org
+
Cc: Jason Frothingham <mepisguides@gmail.com>
+
Subject: Re: [mjr.org] Re: Bug#727708: [gmail.com] Re: Bug#727708: call for + votes on default Linux init system for jessie
+
Date: Wed, 19 Feb 2014 22:44:51 -0600
+
+
It is just as I thought.. incompetence has taken control. Good luck with 
+that.
+
+
+
+On 02/19/2014 08:30 AM, Paul Hedderly wrote:
+> On Wed, Feb 19, 2014 at 01:51:56AM -0600, Tony Thedford wrote:
+>> On 02/18/2014 09:34 PM, Jason Frothingham wrote:
+>>
+>> ...
+>>
+>>
+>>      Adopting systemd does not, in any way shape, form, idea, concept,
+>>      conclusion, thought, etc. etc. etc. prevent, pervert, divert, etc. etc.
+>>      etc. the goal of a computationally stable, bug-free, and flexible operating
+>>      system.�
+>>
+>>
+>>
+>> First of all, YES it does.. and a lot.. and the majority of competent Debian
+>> users know this, and that is why you are catching so much hell over putting it
+> Since you must have spoken to "the majority of competant Debian users" to know this...
+>
+> Could you write up a report of exactly what they said please it would be very
+> helpful. Or point to the report you read and "quoted"? If not, then stop with
+> the lies and the FUD.
+>
+>> into Debian. And this is why so many people are coming out of the woodwork to
+>> express their concerns.. they are concerned about the integrity (stable,
+> You're the third. Perhaps you three the only "competant Debian users"?
+>
+>> bug-free, flexible) of Debian as a viable server and general purpose operating
+>> system for critical applications.. and they don't want it screwed with!
+> You seem to think that you wont be able to chose not to use Systemd - so you've
+> not read very much of the debate or done much research. Here is a clue. Systemd
+> will never make it onto the non-linux ports, so there will always be at least
+> one other init available. You will always have a choice. And you could step up
+> to maintain more choice in Debian if you so desired rather than telling other
+> volunteers what to do. That is "the Debian way".
+>
+>> I have been "coding" since the early 80's, so please don't go there with me, it
+>> doesn't work. I don't care about systemd's capabilities.. that is a mute point.
+> Perhaps you meant a moot point. A mute point would be very quiet indeed.
+> Lots of other people do care and have said so in this debate. I happen to be one
+> using a lot of the new features to great effect, on desktops. AND SERVERS.
+>
+>> All I need to know is that it is an overly complicated, unnecessary piece of
+>> crapware that reduces the integrity of the distribution and that is all that
+>> matters.
+> You have to specific or you'll be accused of FUD. Hand waving and shouting does
+> not count.
+> _Can_ you give more information on how it is overcomplicated?
+> Or unnecessary?
+> Or crap?
+> If not... quit with the lies and the FUD.
+>
+>> As to you initial question about what I would have the developers do.. I would
+>> say do just that.. develop Debian software that continues to make it a truly
+>> universal operating system and follows the original intent of the Debian way.
+> Could you quote what "the Debian way" is? Are you a DD involved in defining that
+> elusive thing?
+>
+> For _me_ one part of Debian has always to excell in making amazing technology
+> and code available for everyone. Times have changed in twenty years. The linux
+> kernel is not the same as it was in 1991. Computers are not used in the same
+> static ways. Debian has to support a huge range of very dynamic systems now, and
+> sysV just does not cut it. Sure it works _ok_ on static environments - but Debian
+> supports far more than static servers.
+>
+>> Debian has been around almost as long as the Internet itself..
+> Debian was started in 1993. The internet... try about 1973. Yes Debian is half
+> the age of the internet. It is nearly as old as the Linux kernel, and not that much
+> younger than GNU, but your point is invalidated by lack of truth.
+>
+>> there are a lot
+>> of users out here that don't want to see anyone mess it up! ..Figure out a way
+>> around being stuck having to use udev since it has been co-opted by systemd..
+>> that would be my first task for you!
+> If you don't want udev, then try Debian Potato. It might make you happy and will
+> forever have sysvinit. And please stop with the FUD and other trolling.
+>
+> Regards
+>
+>>
+>>
+>>
+>>
+>>      On Tue, Feb 18, 2014 at 9:06 PM, Tony Thedford <tony@accesslab.com> wrote:
+>>
+>>          Putting the "systemd" issue on bugs.debian.org is a bit ridiculous I
+>>          would say! As to why there are developers within Debian who are
+>>          hellbent on turning Debian into buggy desktop software rather than
+>>          keeping with the universal operating system directive.. I will never
+>>          know! Debian is a major force in global server software and therefore
+>>          must remain extremely stable, bug-free, and flexible.. all of which
+>>          systemd/gnome crapware nullifies!
+>>
+>>
+>>
+>>
+
+-- 
+Tony Thedford
+Access Technologies
+850 Belt Line Rd
+Garland, TX 75040
+Phone: 972.414.8356
+Email: tony@accesslab.com
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 13:51:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 13:51:08 GMT) (full text, mbox, link).

+ +

Message #7315 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Cc: Colin Watson <cjwatson@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 20 Feb 2014 13:48:48 +0000
+
+
Russ Allbery writes ("Bug#727708: init system coupling etc."):
+> If you do mean that all packages with init system configuration have to
+> ship sysvinit scripts, I wish the wording would actually say that.  This
+> potentially matters in the long run.  For example, consider a hypothetical
+> future world in which systemd, upstart, and OpenRC are packaged for Debian
+> and sysvinit has gone away.  In that world, I would maintain separate
+> configuration for systemd, upstart, and OpenRC, since I consider
+> maintaining those three separate files to be easier than maintaining a
+> sysvinit script.  Is that permitted?  If it is permitted, does my package
+> become instantly buggy when someone packages openlaunchd for Debian?
+
+The draft text in my option says:
+
+   In general, software may not require a specific init system to be
+                                        ^^^^^^^^^^^^^^^^^^^^^^
+   pid 1.  The exceptions to this are as follows:
+
+I think this leaves open the possibility that software might not work
+with certain init systems.  I'm not trying to say that all software
+must work properly with all init systems, no matter how experimental
+or broken.  (Although that would be nice of course.)
+
+In particular, I don't think this is imposing a requirement for
+daemons to work with init systems which do not provide at least a
+compatibility mode for common interfaces (at the moment, the common
+interfaces for this include sysvinit scripts, inetd.conf and perhaps
+something else I haven't thought of).
+
+In practice what I would like to see is a kind of more powerful
+compability mechanism that is better able to exploit the better
+behaviours of more modern daemon supervisors.
+
+But at the moment the main compatibility mechanism sysvinit scripts,
+and all of our init systems support sysvinit scripts.  So that means
+that all packages should ship sysvinit scripts.  Work is ongoing on
+other kinds of compatibility approaches.  (It's not even necessary for
+all daemon packages or all init systems to use the same compatibility
+approach.)
+
+I'm relaxed about the idea of packages having to ship sysvinit scripts
+indefinitely.  Shipping sysvinit scripts does not mean that they have
+to be handwritten.  It would be perfectly feasible for a daemon which
+only supported a sensible non-forking startup approach to provide an
+init script which is autogenerated from some kind of meta information
+(and to use a helper tool for daemonisation).
+
+I think there's a clear segment of opinion in the project and amongst
+our users who want to keep the traditional sysvinit approach.  It's
+not clear whether a minority or a majority will actually want to run
+sysvinit indefinitely, but even if we think other approaches are
+better that doesn't mean we should be forcing them on everyone.
+
+> I think what you're trying to say, from the above, is:
+> 
+>     All software that needs init system configuration must include
+>     sysvinit scripts.  Software may not require any functionality from the
+>     init system that cannot be provided via init scripts, although
+>     degraded operation is tolerable.  The exceptions to this are as
+>     follows:
+> 
+> Also, I assume that this language intends to say that this is forever.  In
+> other words, no package is ever permitted to drop sysvinit scripts,
+> regardless of what init systems are in use in Debian, at least until the
+> TC issues another ruling.
+> 
+> If L passed, that's what I'd assume I was supposed to put in Policy.  If
+> that's *not* what you mean, well, I think it's even more important to
+> clarify this somehow.
+
+For now, yes, you should put that into policy.  If we later come up
+with a better compatibility approach, policy can be amended.  The TC
+decision is defining the objectives, not the details.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 13:57:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 13:57:11 GMT) (full text, mbox, link).

+ +

Message #7320 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling draft CFV
+
Date: Thu, 20 Feb 2014 13:53:38 +0000
+
+
Ian Jackson writes ("Bug#727708: init system coupling draft CFV"):
+> Here are the options which have been proposed so far, with the
+> proposed amendments incorporated as applicable.
+> 
+> You can find the history (with messageids) in the tc git repo.
+> 
+> There are curently four options:
+> 
+>   Ian mark 2 (inclues amendments from Colin and Ian)
+>   Keith
+>   Russ (includes one thing that loos like an amendment)
+>   Ian mark 1 (includes Colin's amendment, but likely to be dropped)
+
+I hereby accept what I've called the "mark 2" amendment here, which
+has the effect of dropping "mark 1" from the ballot.
+
+(I'm about to make the corresponding change to the git repo.)
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 14:09:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 14:09:04 GMT) (full text, mbox, link).

+ +

Message #7325 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 20 Feb 2014 13:56:57 +0000 (UTC)
+
+
Ian Jackson dixit:
+
+>(and to use a helper tool for daemonisation).
+
+mksh -T- -c 'exec daemond arg1 …'
+
+bye,
+//mirabilos
+-- 
+„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
+mksh auf jedem System zu installieren.“
+	-- XTaran auf der OpenRheinRuhr, ganz begeistert
+(EN: “[…]uhr.gz is a reason to install mksh on every system.”)
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 14:15:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 14:15:09 GMT) (full text, mbox, link).

+ +

Message #7330 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Cc: Colin Watson <cjwatson@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 20 Feb 2014 14:10:50 +0000
+
+
I'm writing here in a purely secretarial capacity.
+
+Russ Allbery writes ("Bug#727708: init system coupling etc."):
+> Colin Watson <cjwatson@debian.org> writes:
+> > I agree.  Russ, how about this amendment?
+
+Is that a formal proposal ?
+
+> > diff --git a/727708_initsystem/coupling-russ.txt b/727708_initsystem/coupling-russ.txt
+> > index 242505a..dfc1ded 100644
+[etc]
+> 
+> This seems fine.
+
+And is this an acceptance ?
+
+
+As a matter of process, it would be very wise for everyone to at least
+make all statements approving changes to these kind of resolutions as
+formal proposals.  That way you don't risk not having time to
+explicitly accept the formal amendment before the CFV.
+
+Likewise if a TC member thinks a change is important enough that they
+want to press for it, it would be better to propose it as a formal
+amendment.  It can always be withdrawn or accepted later.  A TC member
+would be well-advised to make such a formal proposal iff they want
+something like their suggestion to be on the ballot.
+
+
+I think in the absence of clarity, when preparing the CFV, I should
+probably proceed on the following basis:
+
+  - Statements from TC members suggesting changes but not explicitly
+    stating that they are formal proposals, are not formal proposals.
+
+    Rationale: This avoids the ballot being clogged up with a
+    profusion of suggested edits which the suggester probably didn't
+    want to put onto the ballot if not accepted.
+
+  - Statements from TC members expressing unqualified approval of
+    suggested edits to their own texts are to be treated as formal
+    acceptance of amendments (including formal proposal of the
+    amendment if necessary).  Even if the TC member's message does
+    not contain an explicit "I hereby ..." statement.
+
+    Rationale: This avoids the ballot containing older versions of a
+    text in a situation where a TC member didn't get around to
+    whatever tidying up or redrafting they felt they were waiting for.
+
+If anyone disagrees with this, please say.
+
+
+So accordingly, I intend to treat Russ's "this seems fine" as an
+acceptance of Colin's suggestion.
+
+> > -    For the jessie release, all packages that currently support being run
+> > +    For the jessie release, all software that currently supports being run
+> >      under sysvinit should continue to support sysvinit unless there is no
+> >      technically feasible way to do so.  Reasonable changes to preserve or
+> >      improve sysvinit support should be accepted through the jessie
+> >      release.  There may be some loss of functionality under sysvinit if
+> 
+> This looks good.
+
+And this.
+
+But not the other suggestions in Colin's mail, which Russ either
+didn't quote or disagreed with.
+
+
+But for now I'm not going to make these changes in git.  Instead I'm
+going to drop the message-id of Russ's message into the git repo as a
+note that it contains accepted amendments which need integrating.
+
+That will save effort if Russ decides to rewrite or re-edit the file
+himself.
+
+I trust this meets with everyone's approval.  Sorry to be so
+long-winded and pernickety about process, but I don't want to make
+sure that we all agree on the process and the proprieties and I don't
+want anyone to be taken by surprise.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 14:21:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 14:21:10 GMT) (full text, mbox, link).

+ +

Message #7335 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Cc: Steve Langasek <vorlon@debian.org>, + Bdale Garbee <bdale@gag.com>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 20 Feb 2014 14:17:33 +0000
+
+
Ian Jackson writes ("Bug#727708: init system coupling etc."):
+> Steve Langasek writes ("Bug#727708: init system coupling etc."):
+> > So I don't think a 24 hour period between draft CfV and CfV is
+> > adequate here.  There have been a lot of proposals discussed in
+> > this thread, and it's not at all clear which are stillborn and
+> > which people think warrant carrying forward.
+> 
+> I think this is in fact perfectly clear.  But I am prepared to commit
+> to a further 24h extension if you promise that you will not ask for
+> even more time beyond that.
+
+I've not heard from Steve.  Under the circumstances I think it would
+be entirely reasonable of me to call for votes at 18:30 UTC today as I
+originally said I would.  However, I don't want to get into another
+process row.
+
+Also Russ and Colin do seem still to be working on final improvements
+to Russ's text.  So, I'm going to wait another day.
+
+I will Call for Votes at 18:00 UTC tomorrow, Friday.  I'm going to
+send another Draft CFV this evening at around the same time, including
+whatever amendments etc. have been put forward by then.
+
+In the meantime I'm generally transferring formal actions into the git
+repo so that I don't have to go through my mailbox again later looking
+for them.
+
+As I have previously said, there is nothing stopping anyone putting
+forward amendments right up to the Call for Votes.  But I don't want
+to delay this CFV again.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 14:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 14:33:04 GMT) (full text, mbox, link).

+ +

Message #7340 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 20 Feb 2014 14:31:06 +0000
+
+
On Wed, Feb 19, 2014 at 06:55:31PM -0800, Russ Allbery wrote:
+> Colin Watson <cjwatson@debian.org> writes:
+> > What I mean by this is that software (with all the exceptions above) may
+> > not be shipped in a configuration where you can only use it with certain
+> > init systems.  For service startup, that just means shipping sysvinit
+> > scripts.  For other interfaces, that means restricting ourselves to the
+> > subset of interfaces that people have figured out how to make work with
+> > other init systems as pid 1.
+> 
+> If you do mean that all packages with init system configuration have to
+> ship sysvinit scripts, I wish the wording would actually say that.  This
+> potentially matters in the long run.  For example, consider a hypothetical
+> future world in which systemd, upstart, and OpenRC are packaged for Debian
+> and sysvinit has gone away.  In that world, I would maintain separate
+> configuration for systemd, upstart, and OpenRC, since I consider
+> maintaining those three separate files to be easier than maintaining a
+> sysvinit script.  Is that permitted?  If it is permitted, does my package
+> become instantly buggy when someone packages openlaunchd for Debian?
+
+I've gone back and forth in my own mind about how/whether we ought to be
+sunsetting this stuff, so apologies if this contradicts something I've
+previously said.  My preference is (to borrow a phrase from British
+constitutional law) that the TC should not be trying to bind its
+successor.  I'm entirely happy for us to set policy (or give advice,
+whatever) based on how things stand at the moment, and revisit it later
+when the landscape changes.
+
+I know we're all tired of this debate at the moment.  But if and when
+sysvinit goes away, I think it'll be relatively straightforward by
+comparison to establish revised policy in light of that, and it will be
+much clearer then what that policy ought to say than it is now.  There
+doesn't seem any danger that we'll forget about this.
+
+My instinct is that in the new world you outline where we
+(hypothetically) have no common subset of service configuration among
+init systems, we probably ought to end up with an explicitly supported
+list of init systems (determined at a more lightweight level than the
+TC) and any new init system would have the job of fleshing out enough
+support in the archive to convince us to add it to that list.  But I
+explicitly don't want to try to lay out something like that now; we
+don't need it yet and it would be unnecessarily contentious.
+
+Would it improve things if we added an informative paragraph such as
+this?  (I'm not necessarily asking whether it would lead you to rank
+this option higher, just whether it makes the intent clearer.)
+
+  This policy is intended for the current situation where most services
+  can still easily include support for multiple init systems by means
+  such as shipping a sysvinit script.  If this changes then we expect to
+  revise this policy or ask the policy editors to do so.
+
+> The second is also ambiguous, albeit less so.  "Figured out how to make
+> work with other init systems" != "figured out how to make work with all
+> init systems."  It's possible to imagine services that work with upstart
+> and systemd but don't work with sysvinit, although I don't know of any
+> currently.
+
+This is a situation that some people have raised but that I honestly
+don't consider interesting.  Upstart and systemd are different enough,
+and Upstart takes a minimal enough approach to the interfaces it offers,
+that a service that (non-trivially, i.e. not just with straightforward
+job/unit files) supports both has IMO demonstrated enough extensibility
+that it wouldn't be hard to port to other things.  Consider the single
+cgroup writer in cgmanager as an example: that's a separate add-on
+service that has nothing Upstart-specific about it and should work just
+as well with other init systems.
+
+I understand that there is a theoretical ambiguity here, but I'm not
+sure how to tighten it up and I'm not keen on spending time doing so
+since I think it will remain theoretical.
+
+> > Similarly, if somebody uploads a new init system to Debian which has no
+> > sysvinit compatibility and thus does basically nothing useful to start
+> > with, then that system is de facto RC buggy in that it can't boot a
+> > useful Debian system, and it shouldn't be other packages' responsibility
+> > to deal with the fact that that init system has no reasonable migration
+> > path.
+> 
+> > I will concede that my amendment is not terribly explicit about this.
+> > I'm not sure how to make it more explicit without cut-and-pasting the
+> > above into it, which I think would be a bit much.  Russ, I know you said
+> > you weren't likely to vote for this, but I don't suppose you could
+> > suggest some language which at least makes the meaning reasonably
+> > watertight to you per the above?
+> 
+> I think what you're trying to say, from the above, is:
+> 
+>     All software that needs init system configuration must include
+>     sysvinit scripts.  Software may not require any functionality from the
+>     init system that cannot be provided via init scripts, although
+>     degraded operation is tolerable.  The exceptions to this are as
+>     follows:
+
+I would be fine with this, perhaps with s/require/have a hard
+requirement of/ for the sake of emphasis, and s/via init scripts/via
+init scripts or other similar compatibility mechanisms/.  But it's
+really Ian's proposal; Ian, what do you think?
+
+> Also, I assume that this language intends to say that this is forever.  In
+> other words, no package is ever permitted to drop sysvinit scripts,
+> regardless of what init systems are in use in Debian, at least until the
+> TC issues another ruling.
+
+See above.
+
+> I think we do actually mean package maintainers here.  I at least don't
+> see any real change by dropping the word "package" and I'm not sure it
+> makes matters any clearer.
+
+[and similar] OK, I don't mind either way on that.  Could you go ahead
+and commit the necessary adjustments to git?
+
+> > My objection to "unless there is no technically feasible way to do so"
+> > is that it's another way of writing "it's too hard", which could mean
+> > almost anything, and thus the "should continue to support sysvinit"
+> > stipulation is toothless: all a maintainer needs to do is say that it
+> > isn't technically feasible to carry significant patches against upstream
+> > even if somebody else writes them, and that's that.  Now, maybe the
+> > "Reasonable changes to preserve or improve sysvinit support should be
+> > accepted ..." sentence covers this, but it seems awfully woolly to me.
+> 
+> Well, it's technical advice.  It's therefore toothless by definition;
+> that's why it's advice.  :)  Yes, the maintainer could use that logic to
+> ignore it, or the maintainer could just ignore it because it's advisory
+> and not normative, regardless of how it's worded.
+> 
+> This is probably my standards background showing here, but I try to
+> maintain a clear distinction in writing between normative and
+> non-normative text.  Advice is non-normative.  We expect package
+> maintainers to use their good judgement, augmented by the guidance of the
+> advice.  If they don't, then the release team may have to say "um, no, RC
+> bug" or the TC may have to consider an override, which is true no matter
+> how it's worded.
+> 
+> I don't think there's a point in trying to put teeth into a statement
+> that's explicitly technical advice.  This is not the point in the process
+> in which teeth are involved.  That would be maintainer overrides, which
+> this is not.
+> 
+> Debian contributors are smart people.  I really don't think anyone is
+> going be confused by the difference between "not technically feasible" and
+> "not technically convenient."  And I *want* maintainers to make good
+> judgements about what is technically feasible and what isn't.
+
+OK.  It still makes me itchy about the details of the message it's
+sending (and the point of technical advice is exactly to send a
+message), but I take your point about the different character of
+informative text, and I don't have a better suggestion right now.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 14:45:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 14:45:05 GMT) (full text, mbox, link).

+ +

Message #7345 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 20 Feb 2014 14:43:18 +0000
+
+
On Thu, Feb 20, 2014 at 02:31:06PM +0000, Colin Watson wrote:
+> On Wed, Feb 19, 2014 at 06:55:31PM -0800, Russ Allbery wrote:
+> > If you do mean that all packages with init system configuration have to
+> > ship sysvinit scripts, I wish the wording would actually say that.  This
+> > potentially matters in the long run.  For example, consider a hypothetical
+> > future world in which systemd, upstart, and OpenRC are packaged for Debian
+> > and sysvinit has gone away.  In that world, I would maintain separate
+> > configuration for systemd, upstart, and OpenRC, since I consider
+> > maintaining those three separate files to be easier than maintaining a
+> > sysvinit script.  Is that permitted?  If it is permitted, does my package
+> > become instantly buggy when someone packages openlaunchd for Debian?
+> 
+> I've gone back and forth in my own mind about how/whether we ought to be
+> sunsetting this stuff, so apologies if this contradicts something I've
+> previously said.  My preference is (to borrow a phrase from British
+> constitutional law) that the TC should not be trying to bind its
+> successor.  I'm entirely happy for us to set policy (or give advice,
+> whatever) based on how things stand at the moment, and revisit it later
+> when the landscape changes.
+> 
+> I know we're all tired of this debate at the moment.  But if and when
+> sysvinit goes away, I think it'll be relatively straightforward by
+> comparison to establish revised policy in light of that, and it will be
+> much clearer then what that policy ought to say than it is now.  There
+> doesn't seem any danger that we'll forget about this.
+
+Also, after rereading your proposal, I notice you have a post-jessie
+sunset clause where we would have to renew our advice if we wanted it to
+continue to be effective (is this very meaningful in an informative
+context?).  While I agree with your too-many-variables sentence, I
+prefer this indefinite until-we-decide-otherwise approach, because
+engineering timescales are wildly variable even in the corporate world
+never mind in a volunteer project.  We definitely want our
+advice/policy/whatever to be effective up to the release of jessie for
+practical upgrade reasons, but I would prefer that changes after that be
+in response to definite changes in the init system landscape, rather
+than simply the passage of time and Debian releases.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 14:48:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 14:48:04 GMT) (full text, mbox, link).

+ +

Message #7350 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Colin Watson <cjwatson@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 20 Feb 2014 14:45:43 +0000
+
+
Colin Watson writes ("Bug#727708: init system coupling etc."):
+> Would it improve things if we added an informative paragraph such as
+> this?  (I'm not necessarily asking whether it would lead you to rank
+> this option higher, just whether it makes the intent clearer.)
+> 
+>   This policy is intended for the current situation where most services
+>   can still easily include support for multiple init systems by means
+>   such as shipping a sysvinit script.  If this changes then we expect to
+>   revise this policy or ask the policy editors to do so.
+
+I guess open to the idea of a clarification along these lines, but I
+would want to ensure that this was limited to the question of service
+startup.  Otherwise we will be faced with claims that the new foobard
+service provided by only one init system is now absolutely mandatory
+for subsystem wombat and this paragraph justifies revisiting the
+situation.
+
+Frankly I find it difficult to imagine a situation where it is
+impractical, or even an unacceptable amount of work, to provide
+service startup for multiple init systems.
+
+> I understand that there is a theoretical ambiguity here, but I'm not
+> sure how to tighten it up and I'm not keen on spending time doing so
+> since I think it will remain theoretical.
+
+Quite.
+
+> > I think what you're trying to say, from the above, is:
+> > 
+> >     All software that needs init system configuration must include
+> >     sysvinit scripts.  Software may not require any functionality from the
+> >     init system that cannot be provided via init scripts, although
+> >     degraded operation is tolerable.  The exceptions to this are as
+> >     follows:
+> 
+> I would be fine with this, perhaps with s/require/have a hard
+> requirement of/ for the sake of emphasis, and s/via init scripts/via
+> init scripts or other similar compatibility mechanisms/.  But it's
+> really Ian's proposal; Ian, what do you think?
+
+I think it's better not to get into implementation details.
+
+If someone comes up with a compatibility approach that doesn't involve
+packages actually shipping sysvinit scripts, we wouldn't want to rule
+it out.  Eg, perhaps the sysvinit scripts are autogenerated at
+package install time; or perhaps the package is started by a
+supervisor daemon which itself has a sysvinit script, but the package
+itself only has configuration for said supervisor (and perhaps no
+other init system config at all).
+
+I have some opinions about the best approaches to cross-init-system
+compatibility but I wouldn't want the TC to prevent policy from
+evolving if experience shows those opinion to be wrong, or even if
+simply the people doing the work decide to do things differently.
+
+So I agree that _at the moment_ the TC wording implies that everyone
+must ship a sysvinit script.  But with future advances or changes
+that may cease to be true.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 14:57:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 14:57:13 GMT) (full text, mbox, link).

+ +

Message #7355 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling draft CFV
+
Date: Thu, 20 Feb 2014 14:53:14 +0000
+
+
Ian Jackson writes ("Bug#727708: init system coupling draft CFV"):
+> There are curently four options:
+> 
+>   Ian mark 2 (inclues amendments from Colin and Ian)
+>   Keith
+>   Russ (includes one thing that loos like an amendment)
+
+These descriptions of the options are obviously suboptimal.  We should
+follow our usual practice and give a summary line on the ballot.
+
+I suggest (for the options on the ballot right now):
+
+  L  Software may not depend on a specific init system (Ian "mk2")
+  A  Provide advice; software may so require (Russ)
+  N  No TC resolution on this question at this time (Keith)
+  FD
+
+I'm going to put those three as headings into the .txt files in git.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 16:57:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 16:57:13 GMT) (full text, mbox, link).

+ +

Message #7360 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling draft CFV
+
Date: Thu, 20 Feb 2014 08:53:50 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I suggest (for the options on the ballot right now):
+
+>   L  Software may not depend on a specific init system (Ian "mk2")
+>   A  Provide advice; software may so require (Russ)
+
+    A  Advise sysvinit compatibility through jessie, multiple init support
+
+is the closest I can get (at least right at the moment) to capturing the
+nuance of my proposal in one line.
+
+On the other procedural matter, my intent is to produce a revised draft of
+my wording incorporating the various suggestions people have made.  When
+I've done so (my intent is to do so today), I'll send that to this bug and
+commit it to Git.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 18:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 18:27:04 GMT) (full text, mbox, link).

+ +

Message #7365 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling draft CFV
+
Date: Thu, 20 Feb 2014 18:25:33 +0000
+
+
Russ Allbery writes ("Bug#727708: init system coupling draft CFV"):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+>     A  Advise sysvinit compatibility through jessie, multiple init support
+> 
+> is the closest I can get (at least right at the moment) to capturing the
+> nuance of my proposal in one line.
+
+How about
+
+    A  Advice: sysvinit compatibility in jessie and multiple init support
+
+which makes it clear that it's all advice.  Replacing "through"
+with "in" gives us more space and sounds less corporate :-).
+
+> On the other procedural matter, my intent is to produce a revised draft of
+> my wording incorporating the various suggestions people have made.  When
+> I've done so (my intent is to do so today), I'll send that to this bug and
+> commit it to Git.
+
+Great, thank you.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 18:33:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 18:33:04 GMT) (full text, mbox, link).

+ +

Message #7370 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling draft CFV
+
Date: Thu, 20 Feb 2014 18:30:31 +0000
+
+
Ian Jackson writes ("Re: Bug#727708: init system coupling draft CFV"):
+> Russ Allbery writes ("Bug#727708: init system coupling draft CFV"):
+> > is the closest I can get (at least right at the moment) to capturing the
+> > nuance of my proposal in one line.
+> 
+> How about
+>     A  Advice: sysvinit compatibility in jessie and multiple init support
+> which makes it clear that it's all advice.  Replacing "through"
+> with "in" gives us more space and sounds less corporate :-).
+
+I have put this heading line into git.  I don't think these summaries
+(which only appear on the TC ballot and tend to be made up by the
+person doing the CFV) are part of the resolution text.
+
+So anyway, Russ, if you want to edit the heading to clarify
+etc. please do that along with your other changes.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 18:39:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 18:39:05 GMT) (full text, mbox, link).

+ +

Message #7375 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling 2nd draft CFV
+
Date: Thu, 20 Feb 2014 18:36:32 +0000
+
+
Here are the options on the table right now:
+
+  L  Software may not depend on a specific init system (Ian "mk2")
+  N  No TC resolution on this question at this time (Keith)
+  A  Advice: sysvinit compatibility in jessie and multiple init support
+  FD
+
+Full texts below.  I have improved the formatting of my text.  Russ
+intends to update his text.  The summary lines are non-normative and
+may be clarified.
+
+The Call for Votes will be at 18:00 UTC tomorrow, about 23.5h from
+now.  Other amendments proposed (and maybe accepted) before then will
+appear on the ballot.
+
+Ian.
+
+
+L  Software may not depend on a specific init system (Ian "mk2")
+================================================================
+
+  Rationale
+
+    The default init system decision is limited to selecting a default
+    initsystem for jessie.  We expect that Debian will continue to
+    support multiple init systems for the foreseeable future; we
+    continue to welcome contributions of support for all init systems.
+
+  Rubric
+
+    Therefore, for jessie and later releases, we exercise our power to
+    set technical policy (Constitution 6.1.1):
+
+  Loose coupling
+
+    In general, software may not require a specific init system to be
+    pid 1.  The exceptions to this are as follows:
+
+     * alternative init system implementations
+     * special-use packages such as managers for init systems
+     * cooperating groups of packages intended for use with specific init
+       systems
+
+    provided that these are not themselves required by other software
+    whose main purpose is not the operation of a specific init system.
+
+    Degraded operation with some init systems is tolerable, so long as
+    the degradation is no worse than what the Debian project would
+    consider a tolerable (non-RC) bug even if it were affecting all
+    users.  So the lack of support for a particular init system does not
+    excuse a bug nor reduce its severity; but conversely, nor is a bug
+    more serious simply because it is an incompatibility of some software
+    with some init system(s).
+
+    Maintainers are encouraged to accept technically sound patches
+    to enable improved interoperation with various init systems.
+
+  GR rider
+
+    If the project passes (before the release of jessie) by a General
+    Resolution, a "position statement about issues of the day", on the
+    subject of init systems, the views expressed in that position
+    statement entirely replace the substance of this TC resolution; the
+    TC hereby adopts any such position statement as its own decision.
+
+    Such a position statement could, for example, use these words:
+
+       The Project requests (as a position statement under s4.1.5 of the
+       Constitution) that the TC reconsider, and requests that the TC
+       would instead decide as follows:
+
+
+N  No TC resolution on this question at this time (Keith)
+=========================================================
+
+The TC chooses to not pass a resolution on this issue at the current time.
+
+
+A  Advice: sysvinit compatibility in jessie and multiple init support
+=====================================================================
+
+[ apparently-accepted amendments from <874n3ubiho.fsf@windlord.stanford.edu>
+  not yet incorporated here ]
+
+    The following is technical advice offered to the project by the
+    Technical Committee under section 6.1.5 of the constitution.  It does
+    not constitute an override of maintainer decisions past or future:
+
+    Packages should normally support the default Linux init system.  There
+    are some exceptional cases where lack of support for the default init
+    system may be appropriate, such as alternative init system
+    implementations, special-use packages such as managers for non-default
+    init systems, and cooperating groups of packages intended for use with
+    non-default init systems.  However, package maintainers should be
+    aware that a requirement for a non-default init system will mean the
+    package will be unusable for most Debian users and should normally be
+    avoided.
+
+    Package maintainers are strongly encouraged to merge any contributions
+    for support of any init system, and to add
+    that support themselves if they're willing and capable of doing so.
+    In particular, package maintainers should put a high priority on
+    merging changes to support any init system which is the default on one
+    of Debian's non-Linux ports.
+
+    For the jessie release, all packages that currently support being run
+    under sysvinit should continue to support sysvinit unless there is no
+    technically feasible way to do so.  Reasonable changes to preserve or
+    improve sysvinit support should be accepted through the jessie
+    release.  There may be some loss of functionality under sysvinit if
+    that loss is considered acceptable by the package maintainer and the
+    package is still basically functional.  All packages should support
+    smooth upgrades from wheezy to jessie, including upgrades done on a
+    system booted with sysvinit.
+
+    The Technical Committee offers no advice at this time on requirements
+    or package dependencies on specific init systems after the jessie
+    release.  There are too many variables at this point to know what the
+    correct course of action will be.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 18:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 18:45:04 GMT) (full text, mbox, link).

+ +

Message #7380 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling draft CFV
+
Date: Thu, 20 Feb 2014 10:41:56 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> How about
+
+>     A  Advice: sysvinit compatibility in jessie and multiple init support
+
+> which makes it clear that it's all advice.  Replacing "through"
+> with "in" gives us more space and sounds less corporate :-).
+
+Sounds great here.  Thanks!
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 20 Feb 2014 22:27:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 20 Feb 2014 22:27:09 GMT) (full text, mbox, link).

+ +

Message #7385 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 20 Feb 2014 14:25:25 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> Perhaps you would like to change this to something like:
+>
+>    The TC chooses to not pass a resolution at the current time
+>    about whether software may require specific init systems.
+>
+> I don't formally propose this because I see no point on voting on both
+> your proposed wording and this edited one.  But if you like this
+> wording, or wish you change it, you may do so, as the proposer of your
+> version.
+
+Thanks, yes, this looks better than my original version. Would you like
+me to commit the change, or would you like to?
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 05:12:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 05:12:08 GMT) (full text, mbox, link).

+ +

Message #7390 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 20 Feb 2014 21:03:28 -0800
+
+
Colin Watson <cjwatson@debian.org> writes:
+
+> Also, after rereading your proposal, I notice you have a post-jessie
+> sunset clause where we would have to renew our advice if we wanted it to
+> continue to be effective (is this very meaningful in an informative
+> context?).
+
+This was just an error on my part.  That was only supposed to apply to the
+advice about sysvinit support, not to the entirety of the advice.  I think
+the rest of it is generally applicable and doesn't need a sunset clause.
+
+> While I agree with your too-many-variables sentence, I prefer this
+> indefinite until-we-decide-otherwise approach, because engineering
+> timescales are wildly variable even in the corporate world never mind in
+> a volunteer project.  We definitely want our advice/policy/whatever to
+> be effective up to the release of jessie for practical upgrade reasons,
+> but I would prefer that changes after that be in response to definite
+> changes in the init system landscape, rather than simply the passage of
+> time and Debian releases.
+
+I'm very reluctant to support a statement that *requires* that we have
+this debate in the TC again.  I would prefer to let the project try to
+work this out and only get involved again if we actually have to.
+
+I don't want to get caught in the trap where we're assuming, even
+implicitly, that the project will do something stupid unless the TC is
+constantly keeping our hands on the wheel.  Maintainers really don't need
+us to tell them how to do their work for the vast majority of issues and
+decisions, and I fully expect that will apply to init systems as well once
+we get through this rocky and controversial part.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 05:15:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 05:15:04 GMT) (full text, mbox, link).

+ +

Message #7395 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling draft CFV
+
Date: Thu, 20 Feb 2014 21:10:19 -0800
+
+
Here is the new draft of my ballot option.  I think this addresses all of
+the issues that were raised.  I didn't rewrite the whole thing to avoid
+all the shoulds; I thought about it, but it felt like it made it a bit too
+hard to read.  I did try a few different wordings of the bit about
+upgrades, and hopefully what I came up with will work.
+
+This includes the change I proposed to Andreas, although unfortunately
+Andreas hasn't had a chance to respond on whether that addressed his
+objection.  It also makes it clearer that the point about not offering
+advice past jessie only applies to the sysvinit compatibility part.
+
+This has also been committed to Git.
+
+A  Advice: sysvinit compatibility in jessie and multiple init support
+=====================================================================
+
+    The following is technical advice offered to the project by the
+    Technical Committee under section 6.1.5 of the constitution.  It does
+    not constitute an override of maintainer decisions past or future.
+
+    Software should normally support the default init system on all
+    architectures for which it is built.  There are some exceptional cases
+    where lack of support for the default init system may be appropriate,
+    such as alternative init system implementations, special-use packages
+    such as managers for non-default init systems, and cooperating
+    groups of packages intended for use with non-default init systems.
+    However, package maintainers should be aware that a requirement for a
+    non-default init system will mean the software will be unusable for
+    most Debian users and should normally be avoided.
+
+    Package maintainers are strongly encouraged to merge any contributions
+    for support of any init system, and to add that support themselves if
+    they're willing and capable of doing so.  In particular, package
+    maintainers should put a high priority on merging changes to support
+    any init system which is the default on one of Debian's non-Linux
+    ports.
+
+    For the jessie release, all software that currently supports being run
+    under sysvinit should continue to support sysvinit unless there is no
+    technically feasible way to do so.  Reasonable changes to preserve
+    or improve sysvinit support should be accepted through the jessie
+    release.  There may be some loss of functionality under sysvinit if
+    that loss is considered acceptable by the package maintainer and
+    the package is still basically functional, but Debian's standard
+    requirement to support smooth upgrades from wheezy to jessie still
+    applies, even when the system is booted with sysvinit.
+
+    The Technical Committee offers no advice at this time on sysvinit
+    support beyond the jessie release.  There are too many variables at
+    this point to know what the correct course of action will be.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 08:12:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 08:12:05 GMT) (full text, mbox, link).

+ +

Message #7400 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: Russ Allbery <rra@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling draft CFV
+
Date: Fri, 21 Feb 2014 09:09:41 +0100
+
+
* Russ Allbery (rra@debian.org) [140221 06:15]:
+> This includes the change I proposed to Andreas, although unfortunately
+> Andreas hasn't had a chance to respond on whether that addressed his
+> objection.  It also makes it clearer that the point about not offering
+> advice past jessie only applies to the sysvinit compatibility part.
+
+I think I'll be able to answer during the weekend, sorry for the
+delay.
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 11:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 11:27:05 GMT) (full text, mbox, link).

+ +

Message #7405 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Andreas Barth <aba@ayous.org>, + 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system coupling draft CFV
+
Date: Fri, 21 Feb 2014 11:23:30 +0000
+
+
Andreas Barth writes ("Bug#727708: init system coupling draft CFV"):
+> * Russ Allbery (rra@debian.org) [140221 06:15]:
+> > This includes the change I proposed to Andreas, although unfortunately
+> > Andreas hasn't had a chance to respond on whether that addressed his
+> > objection.  It also makes it clearer that the point about not offering
+> > advice past jessie only applies to the sysvinit compatibility part.
+> 
+> I think I'll be able to answer during the weekend, sorry for the
+> delay.
+
+I'm afraid that I still intend to call for votes at 18:00 UTC today,
+so if you want Russ to take your comments into account in his draft,
+you will have to reply sooner.
+
+Apologies,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 11:42:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 11:42:04 GMT) (full text, mbox, link).

+ +

Message #7410 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Keith Packard <keithp@keithp.com>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 21 Feb 2014 11:39:51 +0000
+
+
Keith Packard writes ("Re: Bug#727708: init system coupling etc."):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > Perhaps you would like to change this to something like:
+> >
+> >    The TC chooses to not pass a resolution at the current time
+> >    about whether software may require specific init systems.
+...
+> Thanks, yes, this looks better than my original version. Would you like
+> me to commit the change, or would you like to?
+
+I've done so, thanks.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 11:45:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 11:45:09 GMT) (full text, mbox, link).

+ +

Message #7415 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>, + 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling draft CFV
+
Date: Fri, 21 Feb 2014 11:43:07 +0000
+
+
Russ Allbery writes ("Bug#727708: init system coupling draft CFV"):
+> Here is the new draft of my ballot option.  I think this addresses all of
+> the issues that were raised.  I didn't rewrite the whole thing to avoid
+> all the shoulds; I thought about it, but it felt like it made it a bit too
+> hard to read.  I did try a few different wordings of the bit about
+> upgrades, and hopefully what I came up with will work.
+> 
+> This includes the change I proposed to Andreas, although unfortunately
+> Andreas hasn't had a chance to respond on whether that addressed his
+> objection.  It also makes it clearer that the point about not offering
+> advice past jessie only applies to the sysvinit compatibility part.
+> 
+> This has also been committed to Git.
+
+I don't see it.  Perhaps you failed to push.  I have transposed it
+into git myself and pushed.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 11:48:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Tollef Fog Heen <tfheen@err.no>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 11:48:05 GMT) (full text, mbox, link).

+ +

Message #7420 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Tollef Fog Heen <tfheen@err.no>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Thu, 20 Feb 2014 05:20:22 +0100
+
+
]] Colin Watson 
+
+> So, in my amendment, I intended this to be the "cooperating groups of
+> packages intended for use with specific init systems", which language I
+> think I borrowed from your proposal.  If logind-208 Depends: systemd (or
+> indeed if it's part of systemd), then that's fine, as long as it doesn't
+> end up being required by something else that isn't so intimately related
+> to the init system; in other words, a dependency on systemd doesn't
+> become any less a dependency on systemd just because it happens to be
+> spelled "Depends: logind" and there's only one provider available.
+
+To be honest, I'm not sure why init systems are being singled out
+here. It's not really feasible to run both kdm and gdm at the same time,
+or run multiple window managers at the same time or a whole host of
+other software.  Or would you be as strongly opposed to having a tool
+(say an accessibility tool) depend on GDM because it provided interfaces
+that KDM doesn't?  (I'm not sure this is actually true, but I could
+easily see it being true.)
+
+I also find it curious how A depending on interface B provided by
+packages C and D becomes RC buggy because D is unmaintained and gets
+removed from the archive.  It's not how we usually treat bugs.
+
+-- 
+Tollef Fog Heen
+UNIX is user friendly, it's just picky about who its friends are
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 12:18:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 12:18:04 GMT) (full text, mbox, link).

+ +

Message #7425 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 21 Feb 2014 13:15:35 +0100
+
+
* Russ Allbery (rra@debian.org) [140219 19:24]:
+> Andreas Barth <aba@ayous.org> writes:
+> > * Russ Allbery (rra@debian.org) [140214 04:36]:
+> 
+> >> That's a much stronger statement than we've made about support for the
+> >> non-Linux ports in the past, where they're treated at most like another
+> >> release architecture, which means that packages that have never worked
+> >> on that architecture are not expected to do so and packages that used
+> >> to work but stopped are sometimes removed from just that architecture
+> >> rather than ported depending on the situation.
+> 
+> > My expectation of packages is indeed that they work on as many
+> > architectures as reasonable possible, and this includes that they
+> > support the default init system there. (The question of "which severity
+> > does a bug have" is a different question, for a release architecture
+> > that bug would be serious according to
+> > https://release.debian.org/jessie/rc_policy.txt section 4 paragraph 4
+> > and I don't think we should lower the bar.)
+> 
+> > I don't think that this expectation is wrong.
+> 
+> That's a very good point.
+> 
+> How does this sound to you?
+> 
+>     Packages should normally support the default init system on all
+>     architectures for which they are built.  There are some exceptional
+>     cases where lack of support for the default init system may be
+>     appropriate, such as alternative init system implementations,
+>     special-use packages such as managers for non-default init systems,
+>     and cooperating groups of packages intended for use with non-default
+>     init systems.  However, package maintainers should be aware that a
+>     requirement for a non-default init system will mean the package will
+>     be unusable for most Debian users and should normally be avoided.
+
+Better but I think we should also point out that supporting different
+architectures is a good thing.
+
+So the first sentence rather as
+| Packages should support as many architectures as reasonably possible,
+| and they should normally ...
+
+Also I'd like to amend the last sentence with ", and could constitute
+an serious bug of the package." (which is a correct observation
+according to the current RC policy)
+
+
+
+
+> > Because I currently don't see why we should say that (or: whats in there
+> > which is not already said elsewhere), and in that case, less text is
+> > better.
+> 
+> Given that the previous paragraph contains a lot of specific advice for
+> the jessie release, I feel like it adds some clarity to say explicitly
+> that we don't have advice to offer for the next release after jessie at
+> this time.
+
+Well, the paragraph cited above does apply not only to jessie (but
+it's meaning could change depending on which architectures debian
+supports in which way).
+
+So I propose to change the text:
+>
+>     The Technical Committee offers no advice at this time on requirements
+>     or package dependencies on specific init systems after the jessie
+>     release.  There are too many variables at this point to know what the
+>     correct course of action will be.
+
+to
+| The Technical Committee offers no advice regarding sysvinit
+| compatibility at this time after the jessie release.  There are too
+| many variables at this point to know what the correct course of action
+| will be.
+
+(the empty line above is there by purpose, i.e. it also merges this
+paragraph with the previous one)
+
+
+
+To avoid any doubt, this is a formal proposal for an amendment to
+Russ's text, i.e. I would like to see it on the ballot.
+
+I'll try to check my mail before 18:00 UTC but I cannot promise.
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 12:30:15 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 12:30:15 GMT) (full text, mbox, link).

+ +

Message #7430 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Andreas Barth <aba@ayous.org>, + 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 21 Feb 2014 12:29:12 +0000
+
+
Andreas Barth writes ("Bug#727708: init system coupling etc."):
+> So I propose to change the text:
+> >
+> >     The Technical Committee offers no advice at this time on requirements
+> >     or package dependencies on specific init systems after the jessie
+> >     release.  There are too many variables at this point to know what the
+> >     correct course of action will be.
+> 
+> to
+> | The Technical Committee offers no advice regarding sysvinit
+> | compatibility at this time after the jessie release.  There are too
+> | many variables at this point to know what the correct course of action
+> | will be.
+> 
+> (the empty line above is there by purpose, i.e. it also merges this
+> paragraph with the previous one)
+
+I will transpose this into git.
+
+As an observation from a native English speaker, the language is
+rather odd.  It is not conventional to have two time clauses next to
+each other like that.  I would suggest (but do not formally propose):
+
+   The Technical Committee offers no advice at this time regarding
+   sysvinit compatibility after the jessie release.  There are too
+   many variables at this point to know what the correct course of
+   action will be.
+
+Ie, move "at this time" to after "advice".
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 12:39:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 12:39:04 GMT) (full text, mbox, link).

+ +

Message #7435 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Andreas Barth <aba@ayous.org>, + 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 21 Feb 2014 12:37:18 +0000
+
+
Andreas Barth writes ("Bug#727708: init system coupling etc."):
+> Russ Allbery (rra@debian.org) [140219 19:24]:
+> > How does this sound to you?
+> > 
+> >     Packages should normally support the default init system on all
+> >     architectures for which they are built.  There are some exceptional
+> >     cases where lack of support for the default init system may be
+> >     appropriate, such as alternative init system implementations,
+> >     special-use packages such as managers for non-default init systems,
+> >     and cooperating groups of packages intended for use with non-default
+> >     init systems.  However, package maintainers should be aware that a
+> >     requirement for a non-default init system will mean the package will
+> >     be unusable for most Debian users and should normally be avoided.
+> 
+> Better but I think we should also point out that supporting different
+> architectures is a good thing.
+> 
+> So the first sentence rather as
+> | Packages should support as many architectures as reasonably possible,
+> | and they should normally ...
+> 
+> Also I'd like to amend the last sentence with ", and could constitute
+> an serious bug of the package." (which is a correct observation
+> according to the current RC policy)
+
+Russ has already amended his text to say "Software should ...".  So
+when transposing your amendment onto Russ's new text, I have to decide
+between using your new text verbatim (effectively reverting that
+change), or treating your proposal as a request to change only the
+parts you are actually aiming at.
+
+I'm going to do the latter because it appears to best reflect your
+intent.  This results in
+
+    Software should support as many architectures as reasonably possible,
+    and it should normally support the default [...]
+
+(changing "they" to "it" to agree gramatically with "software" rather
+than "packages").
+
+
+> To avoid any doubt, this is a formal proposal for an amendment to
+> Russ's text, i.e. I would like to see it on the ballot.
+
+Thanks for being clear.
+
+Regards,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 12:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 12:45:04 GMT) (full text, mbox, link).

+ +

Message #7440 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Andreas Barth <aba@ayous.org>, + 727708@bugs.debian.org
+
Cc: Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 21 Feb 2014 12:40:57 +0000
+
+
Andreas Barth writes ("Bug#727708: init system coupling etc."):
+> Russ Allbery (rra@debian.org) [140219 19:24]:
+> So I propose to change the text:
+> >
+> >     The Technical Committee offers no advice at this time on requirements
+> >     or package dependencies on specific init systems after the jessie
+> >     release.  There are too many variables at this point to know what the
+> >     correct course of action will be.
+> 
+> to
+> | The Technical Committee offers no advice regarding sysvinit
+> | compatibility at this time after the jessie release.  There are too
+> | many variables at this point to know what the correct course of action
+> | will be.
+> 
+> (the empty line above is there by purpose, i.e. it also merges this
+> paragraph with the previous one)
+
+Looking at Russ's draft, he has already made an effectively identical
+change.  Russ's wording is:
+
+    The Technical Committee offers no advice at this time on sysvinit
+    support beyond the jessie release.  There are too many variables at
+    this point to know what the correct course of action will be.
+
+This differs from yours in the placement of "at this time" (see my
+previous mail) and in that it uses "beyond the jessie release" rather
+than "after the jessie release".  These don't seem to change the
+meaning much for me but improve the way it reads.
+
+You may wish to adopt Russ's wording.
+
+Thanks,
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 13:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 13:45:04 GMT) (full text, mbox, link).

+ +

Message #7445 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 21 Feb 2014 13:41:12 +0000
+
+
On Thu, Feb 20, 2014 at 05:20:22AM +0100, Tollef Fog Heen wrote:
+> ]] Colin Watson 
+> > So, in my amendment, I intended this to be the "cooperating groups of
+> > packages intended for use with specific init systems", which language I
+> > think I borrowed from your proposal.  If logind-208 Depends: systemd (or
+> > indeed if it's part of systemd), then that's fine, as long as it doesn't
+> > end up being required by something else that isn't so intimately related
+> > to the init system; in other words, a dependency on systemd doesn't
+> > become any less a dependency on systemd just because it happens to be
+> > spelled "Depends: logind" and there's only one provider available.
+> 
+> To be honest, I'm not sure why init systems are being singled out
+> here. It's not really feasible to run both kdm and gdm at the same time,
+> or run multiple window managers at the same time or a whole host of
+> other software.  Or would you be as strongly opposed to having a tool
+> (say an accessibility tool) depend on GDM because it provided interfaces
+> that KDM doesn't?  (I'm not sure this is actually true, but I could
+> easily see it being true.)
+
+They're being singled out because this is actually something people have
+been proposing to do, and other people have objected.
+
+Regarding the hypothetical about display managers, I can *conceive* of
+situations where this might be an issue.  It's less clear than with init
+systems, though, because desktop software tends to naturally go with a
+display manager in ways that it doesn't so naturally go with a
+particular init system: assuming that grandomaccessibilitytool has a
+visible interface, it's probably themed the same way as GDM, most of its
+users will probably be using GDM already (or maybe LightDM, I suppose),
+and so on.  It's technically possible but pretty unlikely that a KDE
+tool will suddenly decide that it really needs GDM and thus conflict
+with the rest of your KDE desktop, or in general that you'd end up
+wanting to install multiple packages that require different display
+managers, just because most people tend to stick within a cooperating
+set of packages for their desktop environment.
+
+> I also find it curious how A depending on interface B provided by
+> packages C and D becomes RC buggy because D is unmaintained and gets
+> removed from the archive.  It's not how we usually treat bugs.
+
+I don't view this ballot option as stating that a particular package
+becomes RC-buggy.  It's making a statement about how our software ought
+to be structured, not specifically assigning problems to one end or
+other of a dependency arc.  I still hold out some hope that maintainers
+will actually cooperate and talk to each other about this kind of
+problem ...
+
+If part of an init system (whether packaged monolithically or as an
+add-on) that's essential for the operation of other software in the
+archive with that init system used to work but then ceases to be
+maintained enough to be shippable, then that's a serious regression for
+that init system and we would want to look at whether it's still viable
+at all or perhaps whether the component in question can be resurrected.
+It shouldn't be just a mindlessly static approach where package A
+becomes RC-buggy and we don't think about the underlying reasons that
+led up to it.  I think that situation is quite different, though, from
+the situation where package A introduces a new interface dependency in a
+way that's known to have only limited support.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 15:33:14 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 15:33:14 GMT) (full text, mbox, link).

+ +

Message #7450 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 21 Feb 2014 07:28:09 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I've done so, thanks.
+
+Looks good.
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 15:33:18 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 15:33:18 GMT) (full text, mbox, link).

+ +

Message #7455 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 21 Feb 2014 16:28:19 +0100
+
+
* Ian Jackson (ijackson@chiark.greenend.org.uk) [140221 13:29]:
+> Andreas Barth writes ("Bug#727708: init system coupling etc."):
+> > So I propose to change the text:
+> > >
+> > >     The Technical Committee offers no advice at this time on requirements
+> > >     or package dependencies on specific init systems after the jessie
+> > >     release.  There are too many variables at this point to know what the
+> > >     correct course of action will be.
+> > 
+> > to
+> > | The Technical Committee offers no advice regarding sysvinit
+> > | compatibility at this time after the jessie release.  There are too
+> > | many variables at this point to know what the correct course of action
+> > | will be.
+> > 
+> > (the empty line above is there by purpose, i.e. it also merges this
+> > paragraph with the previous one)
+> 
+> I will transpose this into git.
+> 
+> As an observation from a native English speaker, the language is
+> rather odd.  It is not conventional to have two time clauses next to
+> each other like that.  I would suggest (but do not formally propose):
+> 
+>    The Technical Committee offers no advice at this time regarding
+>    sysvinit compatibility after the jessie release.  There are too
+>    many variables at this point to know what the correct course of
+>    action will be.
+> 
+> Ie, move "at this time" to after "advice".
+
+Thanks, accepted.
+
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 15:33:21 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 15:33:21 GMT) (full text, mbox, link).

+ +

Message #7460 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 21 Feb 2014 16:29:04 +0100
+
+
* Ian Jackson (ijackson@chiark.greenend.org.uk) [140221 13:37]:
+> Andreas Barth writes ("Bug#727708: init system coupling etc."):
+> > Russ Allbery (rra@debian.org) [140219 19:24]:
+> > > How does this sound to you?
+> > > 
+> > >     Packages should normally support the default init system on all
+> > >     architectures for which they are built.  There are some exceptional
+> > >     cases where lack of support for the default init system may be
+> > >     appropriate, such as alternative init system implementations,
+> > >     special-use packages such as managers for non-default init systems,
+> > >     and cooperating groups of packages intended for use with non-default
+> > >     init systems.  However, package maintainers should be aware that a
+> > >     requirement for a non-default init system will mean the package will
+> > >     be unusable for most Debian users and should normally be avoided.
+> > 
+> > Better but I think we should also point out that supporting different
+> > architectures is a good thing.
+> > 
+> > So the first sentence rather as
+> > | Packages should support as many architectures as reasonably possible,
+> > | and they should normally ...
+> > 
+> > Also I'd like to amend the last sentence with ", and could constitute
+> > an serious bug of the package." (which is a correct observation
+> > according to the current RC policy)
+> 
+> Russ has already amended his text to say "Software should ...".  So
+> when transposing your amendment onto Russ's new text, I have to decide
+> between using your new text verbatim (effectively reverting that
+> change), or treating your proposal as a request to change only the
+> parts you are actually aiming at.
+> 
+> I'm going to do the latter because it appears to best reflect your
+> intent.  This results in
+
+Yes, that was the intention (basically it was a patch). Thanks.
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 15:33:24 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 15:33:24 GMT) (full text, mbox, link).

+ +

Message #7465 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 21 Feb 2014 16:29:30 +0100
+
+
* Ian Jackson (ijackson@chiark.greenend.org.uk) [140221 13:41]:
+> Andreas Barth writes ("Bug#727708: init system coupling etc."):
+> > Russ Allbery (rra@debian.org) [140219 19:24]:
+> > So I propose to change the text:
+> > >
+> > >     The Technical Committee offers no advice at this time on requirements
+> > >     or package dependencies on specific init systems after the jessie
+> > >     release.  There are too many variables at this point to know what the
+> > >     correct course of action will be.
+> > 
+> > to
+> > | The Technical Committee offers no advice regarding sysvinit
+> > | compatibility at this time after the jessie release.  There are too
+> > | many variables at this point to know what the correct course of action
+> > | will be.
+> > 
+> > (the empty line above is there by purpose, i.e. it also merges this
+> > paragraph with the previous one)
+> 
+> Looking at Russ's draft, he has already made an effectively identical
+> change.  Russ's wording is:
+> 
+>     The Technical Committee offers no advice at this time on sysvinit
+>     support beyond the jessie release.  There are too many variables at
+>     this point to know what the correct course of action will be.
+> 
+> This differs from yours in the placement of "at this time" (see my
+> previous mail) and in that it uses "beyond the jessie release" rather
+> than "after the jessie release".  These don't seem to change the
+> meaning much for me but improve the way it reads.
+> 
+> You may wish to adopt Russ's wording.
+
+I do.
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 15:39:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 15:39:09 GMT) (full text, mbox, link).

+ +

Message #7470 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Andreas Barth <aba@ayous.org>
+
Cc: 727708@bugs.debian.org, + Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 21 Feb 2014 15:37:29 +0000
+
+
Andreas Barth writes ("Re: Bug#727708: init system coupling etc."):
+> Ian Jackson (ijackson@chiark.greenend.org.uk) [140221 13:41]:
+> > Looking at Russ's draft, he has already made an effectively identical
+> > change.  Russ's wording is:
+> > 
+> >     The Technical Committee offers no advice at this time on sysvinit
+> >     support beyond the jessie release.  There are too many variables at
+> >     this point to know what the correct course of action will be.
+> > 
+> > This differs from yours in the placement of "at this time" (see my
+> > previous mail) and in that it uses "beyond the jessie release" rather
+> > than "after the jessie release".  These don't seem to change the
+> > meaning much for me but improve the way it reads.
+> > 
+> > You may wish to adopt Russ's wording.
+> 
+> I do.
+
+Thanks, transferred to git.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 15:45:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 15:45:04 GMT) (full text, mbox, link).

+ +

Message #7475 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Andreas Barth <aba@ayous.org>, + 727708@bugs.debian.org, + Russ Allbery <rra@debian.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 21 Feb 2014 15:40:56 +0000
+
+
For Andi's version of Russ's text I have written this summary line
+into the git repo:
+
+  B  Advice: sysvinit compatibility in jessie and multi init, arch, support
+
+The difference between Russ's (A) and Andi's (B) is precisely this:
+
+ <     Software should normally support the default init system on all
+ ---
+ >     Software should support as many architectures as reasonably possible,
+ >     and it should normally support the default init system on all
+
+If Russ does not accept this amendment then both A and B will be on
+the ballot.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 16:51:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Georgy Demidov <georgy.demidov@mail.ru>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 16:51:05 GMT) (full text, mbox, link).

+ +

Message #7480 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Georgy Demidov <georgy.demidov@mail.ru>
+
To: 727708@bugs.debian.org, + debian-project@lists.debian.org, + debian-devel@lists.debian.org
+
Subject: Linux Security, Red Hat and Systemd Conspiracy
+
Date: Fri, 21 Feb 2014 20:48:46 +0400
+
+
Hi!
+
+Debian user here. This is my first and last letter about the bug #727708. I feel this is important to share.
+
+Quote from Soylent News [1].
+
+Former cypherpunk shares his  conspiratorial view on Linux security [1] :
+Since then, more has happened to reveal the true story here, the depth of which surprised even me. The GTK development story and the systemd debate on Debian revealed much corporate pressure being brought to bear in Linux. [...] Some really startling facts about Red Hat came to light. For me the biggest was the fact that the US military is Red Hat's largest customer:
+>"When we rolled into Baghdad, we did it using open source," General Justice continued. "It may come as a surprise to many of you, but the  U.S. Army is 'the' single largest install base for Red Hat Linux. I'm their largest customer ." ( 2008 ) [3]
+This is pretty much what I had figured. I'm not exactly new to this, and I figured that in some way the military-industrial/corporate/intelligence complex was in control of Red Hat and Linux. [...] But I didn't expect it to be stated so plainly. Any fool should realize that "biggest customer" doesn't mean tallest or widest, it means the most money. In other words, most of Red Hat's money comes from the military and, as a result, they have significant pull in its development. In that respect, the connection between the military and spying agencies, etc. should be obvious.
+Next, the  FOSDEM: NSA Operation ORCHESTRA Annual Status Report is well worth watching in its entirety (including the Q&A at the end). To me, this turned out to be a road-map detailing how Red Hat is operating on Linux!"
+
+Linus Torvalds about Lennart Poettering: “Two-faced lying weasel” would be the most polite thing I could say.
+But it almost certainly will involve a lot of cursing.
+
+"Systemd propaganda: It's a crap!" - Gentoo Dev Patrick Lauer [5]
+
+[1] http://soylentnews.org/article.pl?sid=14/02/20/031231
+
+[2] http://igurublog.wordpress.com/2014/02/17/biography-of-a-cypherpunk-and-how-cryptography-affects-your-life/
+
+[3] http://archive09.linux.com/feed/61302
+
+[4] http://video.fosdem.org/2014/Janson/Sunday/NSA_operation_ORCHESTRA_Annual_Status_Report.webm
+
+[5] http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 17:27:13 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 17:27:13 GMT) (full text, mbox, link).

+ +

Message #7485 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system - achieving diversity
+
Date: Fri, 21 Feb 2014 17:15:02 +0000
+
+
I'm taking off my secretarial hat for a moment and presenting a short
+polemic in favour of my proposal over Russ's (whether as amended by
+Andi or not).
+
+I'm addressing myself primarily to the members of the TC who are in
+favour of diversity in init systems, and in architectures, and who
+think that the freedom and autonomy of our users and downstreams is
+more important than the convenience of us or our upstreams.
+
+Do not think that Russ's text does anything to support these goals.
+Nothing in it goes beyond the obvious and even that is purely advice.
+
+It doesn't explicitly address the key question: "is it OK to require a
+specific init system".  But, implicitly, it says "yes, that is OK".
+
+We need to send a clear signal about our commitment to diversity that
+will be received not just in Debian, but also in the upstream
+communities where key decisions are being made - specifically, about
+whether it is OK to require systemd.  Russ's text does not contain any
+kind of decision or statement that could be used as a part of a strong
+argument by systemd sceptics in the GNOME community, for example.
+
+And, we need to make a commitment internally that we intend to
+continue to support and encourage diversity and choice for the
+foreseeable future.
+
+Russ's proposal is worse than "no decision now".  At least Keith's
+text clearly ducks the critical question.  Russ answers it the wrong
+way.  The fact that Russ's resolution text doesn't make its own
+unpleasant consequences explicit is effective politics, but it makes
+for a bad TC ruling.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 17:27:17 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 17:27:17 GMT) (full text, mbox, link).

+ +

Message #7490 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org, Andreas Barth <aba@ayous.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 21 Feb 2014 09:20:52 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> For Andi's version of Russ's text I have written this summary line
+> into the git repo:
+
+>   B  Advice: sysvinit compatibility in jessie and multi init, arch, support
+
+> The difference between Russ's (A) and Andi's (B) is precisely this:
+
+>  <     Software should normally support the default init system on all
+>  ---
+>  >     Software should support as many architectures as reasonably possible,
+>  >     and it should normally support the default init system on all
+
+> If Russ does not accept this amendment then both A and B will be on
+> the ballot.
+
+I accept this amendment.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 17:27:20 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 17:27:20 GMT) (full text, mbox, link).

+ +

Message #7495 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling draft CFV
+
Date: Fri, 21 Feb 2014 09:22:11 -0800
+
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I don't see it.  Perhaps you failed to push.  I have transposed it
+> into git myself and pushed.
+
+Indeed, I forgot to push.  I'm sorry about that.  :/  I'm clearly not at
+my best at the moment.
+
+I can confirm that Git found your change to be identical to mine, so
+everything should be good.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 17:33:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 17:33:08 GMT) (full text, mbox, link).

+ +

Message #7500 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: Russ Allbery <rra@debian.org>
+
Cc: 727708@bugs.debian.org, + Andreas Barth <aba@ayous.org>
+
Subject: Re: Bug#727708: init system coupling etc.
+
Date: Fri, 21 Feb 2014 17:29:13 +0000
+
+
Russ Allbery writes ("Re: Bug#727708: init system coupling etc."):
+> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+> > If Russ does not accept this amendment then both A and B will be on
+> > the ballot.
+> 
+> I accept this amendment.
+
+I have removed the unamended version from the git repo.  I've
+transferred the option letter and summary from the unamended to the
+amended version, as that seems less confusing and there is no longer a
+need to distinguish what-as-A (which is now dropped) and what-was B
+(which I'm now calling A) on the ballto summary.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 17:33:11 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 17:33:11 GMT) (full text, mbox, link).

+ +

Message #7505 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system coupling final draft CFV
+
Date: Fri, 21 Feb 2014 17:32:07 +0000
+
+
Options on the ballot right now:
+
+  L  Software may not depend on a specific init system (Ian "mk2")
+  N  No TC resolution on this question at this time (Keith)
+  A  Advice: sysvinit compatibility in jessie and multiple init support
+  FD
+
+Full texts below.  There are no outstanding textual amendment
+suggestions.  I will Call for Votes in about 30 minutes, barring
+procedural objections (or last-minute amendments to incorporate).
+
+Ian.
+
+
+L  Software may not depend on a specific init system (Ian "mk2")
+================================================================
+
+  Rationale
+
+    The default init system decision is limited to selecting a default
+    initsystem for jessie.  We expect that Debian will continue to
+    support multiple init systems for the foreseeable future; we
+    continue to welcome contributions of support for all init systems.
+
+  Rubric
+
+    Therefore, for jessie and later releases, we exercise our power to
+    set technical policy (Constitution 6.1.1):
+
+  Loose coupling
+
+    In general, software may not require a specific init system to be
+    pid 1.  The exceptions to this are as follows:
+
+     * alternative init system implementations
+     * special-use packages such as managers for init systems
+     * cooperating groups of packages intended for use with specific init
+       systems
+
+    provided that these are not themselves required by other software
+    whose main purpose is not the operation of a specific init system.
+
+    Degraded operation with some init systems is tolerable, so long as
+    the degradation is no worse than what the Debian project would
+    consider a tolerable (non-RC) bug even if it were affecting all
+    users.  So the lack of support for a particular init system does not
+    excuse a bug nor reduce its severity; but conversely, nor is a bug
+    more serious simply because it is an incompatibility of some software
+    with some init system(s).
+
+    Maintainers are encouraged to accept technically sound patches
+    to enable improved interoperation with various init systems.
+
+  GR rider
+
+    If the project passes (before the release of jessie) by a General
+    Resolution, a "position statement about issues of the day", on the
+    subject of init systems, the views expressed in that position
+    statement entirely replace the substance of this TC resolution; the
+    TC hereby adopts any such position statement as its own decision.
+
+    Such a position statement could, for example, use these words:
+
+       The Project requests (as a position statement under s4.1.5 of the
+       Constitution) that the TC reconsider, and requests that the TC
+       would instead decide as follows:
+
+
+N  No TC resolution on this question at this time (Keith)
+=========================================================
+
+   The TC chooses to not pass a resolution at the current time
+   about whether software may require specific init systems.
+
+
+A  Advice: sysvinit compatibility in jessie and multiple init support
+=====================================================================
+
+    The following is technical advice offered to the project by the
+    Technical Committee under section 6.1.5 of the constitution.  It does
+    not constitute an override of maintainer decisions past or future.
+
+    Software should support as many architectures as reasonably possible,
+    and it should normally support the default init system on all
+    architectures for which it is built.  There are some exceptional cases
+    where lack of support for the default init system may be appropriate,
+    such as alternative init system implementations, special-use packages
+    such as managers for non-default init systems, and cooperating
+    groups of packages intended for use with non-default init systems.
+    However, package maintainers should be aware that a requirement for a
+    non-default init system will mean the software will be unusable for
+    most Debian users and should normally be avoided.
+
+    Package maintainers are strongly encouraged to merge any contributions
+    for support of any init system, and to add that support themselves if
+    they're willing and capable of doing so.  In particular, package
+    maintainers should put a high priority on merging changes to support
+    any init system which is the default on one of Debian's non-Linux
+    ports.
+
+    For the jessie release, all software that currently supports being run
+    under sysvinit should continue to support sysvinit unless there is no
+    technically feasible way to do so.  Reasonable changes to preserve
+    or improve sysvinit support should be accepted through the jessie
+    release.  There may be some loss of functionality under sysvinit if
+    that loss is considered acceptable by the package maintainer and
+    the package is still basically functional, but Debian's standard
+    requirement to support smooth upgrades from wheezy to jessie still
+    applies, even when the system is booted with sysvinit.
+
+    The Technical Committee offers no advice at this time on sysvinit
+    support beyond the jessie release.  There are too many variables at
+    this point to know what the correct course of action will be.
+
+-- 
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 18:06:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 18:06:04 GMT) (full text, mbox, link).

+ +

Message #7510 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Bug#727708: Call for Votes on init system coupling
+
Date: Fri, 21 Feb 2014 18:04:07 +0000
+
+
I hereby call for votes on my coupling proposal and the amendments
+that have been put.
+
+The options on the ballot are:
+
+  L   Software may not depend on a specific init system
+  N   No TC resolution on this question at this time
+  A   Advice: sysvinit compatibility in jessie and multiple init support
+  FD  Further discussion
+
+(I have removed the proponents' names from the summary lines.)
+
+Thanks,
+Ian.
+
+
+L  Software may not depend on a specific init system
+====================================================
+
+  Rationale
+
+    The default init system decision is limited to selecting a default
+    initsystem for jessie.  We expect that Debian will continue to
+    support multiple init systems for the foreseeable future; we
+    continue to welcome contributions of support for all init systems.
+
+  Rubric
+
+    Therefore, for jessie and later releases, we exercise our power to
+    set technical policy (Constitution 6.1.1):
+
+  Loose coupling
+
+    In general, software may not require a specific init system to be
+    pid 1.  The exceptions to this are as follows:
+
+     * alternative init system implementations
+     * special-use packages such as managers for init systems
+     * cooperating groups of packages intended for use with specific init
+       systems
+
+    provided that these are not themselves required by other software
+    whose main purpose is not the operation of a specific init system.
+
+    Degraded operation with some init systems is tolerable, so long as
+    the degradation is no worse than what the Debian project would
+    consider a tolerable (non-RC) bug even if it were affecting all
+    users.  So the lack of support for a particular init system does not
+    excuse a bug nor reduce its severity; but conversely, nor is a bug
+    more serious simply because it is an incompatibility of some software
+    with some init system(s).
+
+    Maintainers are encouraged to accept technically sound patches
+    to enable improved interoperation with various init systems.
+
+  GR rider
+
+    If the project passes (before the release of jessie) by a General
+    Resolution, a "position statement about issues of the day", on the
+    subject of init systems, the views expressed in that position
+    statement entirely replace the substance of this TC resolution; the
+    TC hereby adopts any such position statement as its own decision.
+
+    Such a position statement could, for example, use these words:
+
+       The Project requests (as a position statement under s4.1.5 of the
+       Constitution) that the TC reconsider, and requests that the TC
+       would instead decide as follows:
+
+
+N  No TC resolution on this question at this time
+=================================================
+
+   The TC chooses to not pass a resolution at the current time
+   about whether software may require specific init systems.
+
+
+A  Advice: sysvinit compatibility in jessie and multiple init support
+=====================================================================
+
+    The following is technical advice offered to the project by the
+    Technical Committee under section 6.1.5 of the constitution.  It does
+    not constitute an override of maintainer decisions past or future.
+
+    Software should support as many architectures as reasonably possible,
+    and it should normally support the default init system on all
+    architectures for which it is built.  There are some exceptional cases
+    where lack of support for the default init system may be appropriate,
+    such as alternative init system implementations, special-use packages
+    such as managers for non-default init systems, and cooperating
+    groups of packages intended for use with non-default init systems.
+    However, package maintainers should be aware that a requirement for a
+    non-default init system will mean the software will be unusable for
+    most Debian users and should normally be avoided.
+
+    Package maintainers are strongly encouraged to merge any contributions
+    for support of any init system, and to add that support themselves if
+    they're willing and capable of doing so.  In particular, package
+    maintainers should put a high priority on merging changes to support
+    any init system which is the default on one of Debian's non-Linux
+    ports.
+
+    For the jessie release, all software that currently supports being run
+    under sysvinit should continue to support sysvinit unless there is no
+    technically feasible way to do so.  Reasonable changes to preserve
+    or improve sysvinit support should be accepted through the jessie
+    release.  There may be some loss of functionality under sysvinit if
+    that loss is considered acceptable by the package maintainer and
+    the package is still basically functional, but Debian's standard
+    requirement to support smooth upgrades from wheezy to jessie still
+    applies, even when the system is booted with sysvinit.
+
+    The Technical Committee offers no advice at this time on sysvinit
+    support beyond the jessie release.  There are too many variables at
+    this point to know what the correct course of action will be.
+
+-- 
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 18:09:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Ian Jackson <ijackson@chiark.greenend.org.uk>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 18:09:10 GMT) (full text, mbox, link).

+ +

Message #7515 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Fri, 21 Feb 2014 18:05:57 +0000
+
+
Ian Jackson writes ("Bug#727708: Call for Votes on init system coupling"):
+> I hereby call for votes on my coupling proposal and the amendments
+> that have been put.
+> 
+> The options on the ballot are:
+> 
+>   L   Software may not depend on a specific init system
+>   N   No TC resolution on this question at this time
+>   A   Advice: sysvinit compatibility in jessie and multiple init support
+>   FD  Further discussion
+
+I vote:
+   L, N, A, FD
+
+I have resisted the temptation to try to exploit the constitutional
+bug by ranking FD 2nd.
+
+Ian.
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 18:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 18:15:05 GMT) (full text, mbox, link).

+ +

Message #7520 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Fri, 21 Feb 2014 10:12:23 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I hereby call for votes on my coupling proposal and the amendments
+> that have been put.
+
+> The options on the ballot are:
+
+>   L   Software may not depend on a specific init system
+>   N   No TC resolution on this question at this time
+>   A   Advice: sysvinit compatibility in jessie and multiple init support
+>   FD  Further discussion
+
+> (I have removed the proponents' names from the summary lines.)
+
+I vote:
+
+    N A L FD
+
+Thanks to Ian and Colin for the work on clarifying L over the past few
+weeks.  While I still don't agree with it, I at least now understand what
+it means and what I would need to do with it as Policy Editor.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 18:27:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 18:27:05 GMT) (full text, mbox, link).

+ +

Message #7525 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Fri, 21 Feb 2014 10:22:43 -0800
+
+
On Fri, 21 Feb 2014, Ian Jackson wrote:
+> I hereby call for votes on my coupling proposal and the amendments
+> that have been put.
+> 
+> The options on the ballot are:
+> 
+>   L   Software may not depend on a specific init system
+>   N   No TC resolution on this question at this time
+>   A   Advice: sysvinit compatibility in jessie and multiple init support
+>   FD  Further discussion
+> 
+
+I vote A > N > L > FD.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+6: I'm human. I have a thousand flaws. I break down. I get up or I
+don't get up. I get lost. I make the same mistakes over and over. I
+have scars and wounds. Sometimes when I can't bear them anymore, I
+drink. You can't fix me. You can't fix any of us. You can't make us
+perfect.
+ -- "The Prisoner (2009 Miniseries)" _Checkmate_
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 18:51:09 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 18:51:09 GMT) (full text, mbox, link).

+ +

Message #7530 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Fri, 21 Feb 2014 18:49:38 +0000
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Feb 21, 2014 at 06:04:07PM +0000, Ian Jackson wrote:
+>   L   Software may not depend on a specific init system
+>   N   No TC resolution on this question at this time
+>   A   Advice: sysvinit compatibility in jessie and multiple init support
+>   FD  Further discussion
+
+I vote L N A FD.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 19:21:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 19:21:05 GMT) (full text, mbox, link).

+ +

Message #7535 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Fri, 21 Feb 2014 12:16:15 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I hereby call for votes on my coupling proposal and the amendments
+> that have been put.
+>
+>   L   Software may not depend on a specific init system
+>   N   No TC resolution on this question at this time
+>   A   Advice: sysvinit compatibility in jessie and multiple init support
+>   FD  Further discussion
+
+I vote N, A, FD, L.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 20:39:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Keith Packard <keithp@keithp.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 20:39:08 GMT) (full text, mbox, link).

+ +

Message #7540 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Keith Packard <keithp@keithp.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Fri, 21 Feb 2014 12:37:30 -0800
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I hereby call for votes on my coupling proposal and the amendments
+> that have been put.
+>
+> The options on the ballot are:
+>
+>   L   Software may not depend on a specific init system
+>   N   No TC resolution on this question at this time
+>   A   Advice: sysvinit compatibility in jessie and multiple init support
+>   FD  Further discussion
+
+I vote
+
+        N > A > FD > L
+
+-- 
+keith.packard@intel.com
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 21:15:08 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Chris.Knadle@coredump.us:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 21:15:08 GMT) (full text, mbox, link).

+ +

Message #7545 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Chris Knadle <Chris.Knadle@coredump.us>
+
To: debian-ctte@lists.debian.org, Georgy Demidov <georgy.demidov@mail.ru>, 727708@bugs.debian.org
+
Cc: debian-project@lists.debian.org, debian-devel@lists.debian.org
+
Subject: Re: Bug#727708: Linux Security, Red Hat and Systemd Conspiracy
+
Date: Fri, 21 Feb 2014 16:13:17 -0500
+
+
This particular statement was taken out of context:
+
+On Friday, February 21, 2014 20:48:46 Georgy Demidov wrote:
+[...]
+> Linus Torvalds about Lennart Poettering: “Two-faced lying weasel” would be
+> the most polite thing I could say. But it almost certainly will involve a
+> lot of cursing.
+
+When Linus wrote this (in Oct 2012), it was specifically about a bug in udev 
+concerning deadlocking if moudule_init() did a request_firmware() which 
+apparently broke in udev182. [1]
+
+Linus was really pissed off because this issue had dragged on for months and 
+Kay had apparently ignored patches to fix it [2].  I don't personally think 
+this was because of malice or conspiracy -- it's far more likely to be some 
+kind of technical misunderstanding or a design issue than anything else.
+
+[1]: https://lkml.org/lkml/2012/10/2/303
+
+[2]: https://lkml.org/lkml/2012/10/3/484
+
+  -- Chris
+
+--
+Chris Knadle
+Chris.Knadle@coredump.us
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 21 Feb 2014 21:57:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Olav Vitters <olav@vitters.nl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 21 Feb 2014 21:57:05 GMT) (full text, mbox, link).

+ +

Message #7550 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Olav Vitters <olav@vitters.nl>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system - achieving diversity
+
Date: Fri, 21 Feb 2014 22:54:06 +0100
+
+
On Fri, Feb 21, 2014 at 05:15:02PM +0000, Ian Jackson wrote:
+> whether it is OK to require systemd.  Russ's text does not contain any
+> kind of decision or statement that could be used as a part of a strong
+> argument by systemd sceptics in the GNOME community, for example.
+
+As explained before: If someone wants to make something happen, they're
+more than free to do so. There is simply no need for any statement from
+Debian. What is appreciated is commitment and action. Notify when you
+have concrete problems with something.
+
+Your "strong argument by systemd sceptics" gives the impression, despite
+several explanations given by me and on Planet GNOME, that we do not
+consider or need to be taught to think about portability. If you want a
+productive discussion or change feel free to reach out to us. What I
+quoted from you comes across as a bit condescending and mistrusting.
+I've made clear that any cooperation is more than welcome (alternative
+implementations for APIs or just constructive discussions). I discussed
+within the release team mailing list (they're public), various others
+agree. Nobody disagrees.
+
+-- 
+Regards,
+Olav
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 24 Feb 2014 21:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Andreas Barth <aba@ayous.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 24 Feb 2014 21:57:04 GMT) (full text, mbox, link).

+ +

Message #7555 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Andreas Barth <aba@ayous.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Mon, 24 Feb 2014 22:54:19 +0100
+
+
* Ian Jackson (ijackson@chiark.greenend.org.uk) [140221 19:06]:
+> The options on the ballot are:
+> 
+>   L   Software may not depend on a specific init system
+>   N   No TC resolution on this question at this time
+>   A   Advice: sysvinit compatibility in jessie and multiple init support
+>   FD  Further discussion
+
+I vote L A N FD.
+
+
+
+Andi
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 25 Feb 2014 19:03:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Don Armstrong <don@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 25 Feb 2014 19:03:05 GMT) (full text, mbox, link).

+ +

Message #7560 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Don Armstrong <don@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Tue, 25 Feb 2014 10:58:25 -0800
+
+
On Mon, 24 Feb 2014, Andreas Barth wrote:
+> * Ian Jackson (ijackson@chiark.greenend.org.uk) [140221 19:06]:
+> > The options on the ballot are:
+> > 
+> >   L   Software may not depend on a specific init system
+> >   N   No TC resolution on this question at this time
+> >   A   Advice: sysvinit compatibility in jessie and multiple init support
+> >   FD  Further discussion
+> 
+> I vote L A N FD.
+
+With this vote, the outcome is potentially in doubt; if Steve ranks L >
+A, then Bdale has the casting vote between L and N. If Steve ranks A >
+L, or does not vote, then N is the winner. [Presumably in the first
+case, Bdale will select N, but I'm not sure if that's enough to call the
+vote no longer in doubt.]
+
+727708_initsystem/coupling_votes.txt has the current votes which you can
+run Ian's utility on.
+
+-- 
+Don Armstrong                      http://www.donarmstrong.com
+
+He was wrong. Nature abhors dimensional abnormalities, and seals them
+neatly away so that they don't upset people. Nature, in fact, abhors a
+lot of things, including vacuums, ships called the Marie Celeste, and
+the chuck keys for electric drills.
+ -- Terry Pratchet _Pyramids_ p166
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Tue, 25 Feb 2014 20:27:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Kurt Roeckx <kurt@roeckx.be>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Tue, 25 Feb 2014 20:27:04 GMT) (full text, mbox, link).

+ +

Message #7565 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Kurt Roeckx <kurt@roeckx.be>
+
To: Don Armstrong <don@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Tue, 25 Feb 2014 21:22:08 +0100
+
+
On Tue, Feb 25, 2014 at 10:58:25AM -0800, Don Armstrong wrote:
+> On Mon, 24 Feb 2014, Andreas Barth wrote:
+> > * Ian Jackson (ijackson@chiark.greenend.org.uk) [140221 19:06]:
+> > > The options on the ballot are:
+> > > 
+> > >   L   Software may not depend on a specific init system
+> > >   N   No TC resolution on this question at this time
+> > >   A   Advice: sysvinit compatibility in jessie and multiple init support
+> > >   FD  Further discussion
+> > 
+> > I vote L A N FD.
+> 
+> With this vote, the outcome is potentially in doubt; if Steve ranks L >
+> A, then Bdale has the casting vote between L and N. If Steve ranks A >
+> L, or does not vote, then N is the winner. [Presumably in the first
+> case, Bdale will select N, but I'm not sure if that's enough to call the
+> vote no longer in doubt.]
+
+Assuming this is all the case, I haven't really checked, I think
+that N is the winner in any case.  I see no reason why Bdale would
+suddenly pick L over N since he already put N first and L below
+FD.
+
+
+Kurt
+
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Thu, 27 Feb 2014 18:12:18 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Steve Langasek <vorlon@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Thu, 27 Feb 2014 18:12:18 GMT) (full text, mbox, link).

+ +

Message #7570 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Steve Langasek <vorlon@debian.org>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Thu, 27 Feb 2014 10:11:54 -0800
+
+
[Message part 1 (text/plain, inline)]
+
On Fri, Feb 21, 2014 at 06:04:07PM +0000, Ian Jackson wrote:
+> I hereby call for votes on my coupling proposal and the amendments
+> that have been put.
+
+> The options on the ballot are:
+
+>   L   Software may not depend on a specific init system
+>   N   No TC resolution on this question at this time
+>   A   Advice: sysvinit compatibility in jessie and multiple init support
+>   FD  Further discussion
+
+> (I have removed the proponents' names from the summary lines.)
+
+I vote:
+
+  L > A > N > FD
+
+-- 
+Steve Langasek                   Give me a lever long enough and a Free OS
+Debian Developer                   to set it on, and I can move the world.
+Ubuntu Developer                                    http://www.debian.org/
+slangasek@ubuntu.com                                     vorlon@debian.org
+
+
[signature.asc (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 28 Feb 2014 07:39:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 28 Feb 2014 07:39:10 GMT) (full text, mbox, link).

+ +

Message #7575 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Fri, 28 Feb 2014 00:30:12 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
+
+> I hereby call for votes on my coupling proposal and the amendments
+> that have been put.
+
+With all 8 votes cast, this CFV on the init system coupling issue has
+ended in a tie between options "L" and "N".  Given my vote on this
+issue, it should be no surprise that I use my casting vote to declare
+option "N" is the winner.  
+
+Therefore:
+
+   The TC chooses to not pass a resolution at the current time
+   about whether software may require specific init systems.
+
+- - -
+
+During the TC's IRC meeting some hours ago, Steve Langasek expressed 
+disappointment that I ranked the "L" option below "FD" without providing
+some explanation.  While this had no material effect on the outcome, I
+agreed to explain my reasoning here. 
+
+As I stated in my call for votes on the simple question of which init
+system should be the default for Linux in the jessie release, I'm in
+favor of Debian supporting multiple init systems.  The problem is that I
+don't believe this is something we should try to preemptively legislate
+in the TC by imposing a new dependency restriction.  It will only happen
+if those of us who want support for multiple init system in Debian
+actually do the work required in the context of normal Debian processes
+and behavior.
+
+Some TC members who put the "L" option first express concern that *not*
+imposing a restriction on dependencies effectively guarantees bad things
+will happen.  Everything I think I know about the Debian project and how
+we have generally chosen to interact with each other over the last 20
+years leads me to disagree.  The discussion I've seen since our systemd
+ballot reinforces my belief that package maintainers try to do the right
+things, and we should give them the benefit of the doubt.  Should the
+technical decisions they make, including expressing dependencies on some
+subset of our available init systems, ultimately lead to disagreements
+worthy of referral to the TC, we can and will deal with them then. 
+
+Regarding option "A", giving non-binding advice to the project, my
+feeling was that this option just captured the status quo, and thus
+wasn't necessary to issue as a TC resolution.  However, since I do think
+option "A" likely captures the broad consensus of the project, I hope it
+will be seen as well-reasoned input by those who now turn their
+attention to updating Debian policy around init systems for the jessie
+release. 
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Fri, 28 Feb 2014 16:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Fri, 28 Feb 2014 16:15:05 GMT) (full text, mbox, link).

+ +

Message #7580 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
+
To: Dimitri John Ledkov <xnox@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: init system discussion status
+
Date: Fri, 28 Feb 2014 17:14:28 +0100
+
+
On Sun, Jan 05, 2014 at 12:16:58AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
+> git notes are used to mark backport-worthy commits. See
+> http://lists.freedesktop.org/archives/systemd-devel/2013-September/013188.html.
+> We currently mark patches as bugfixes (which includes fixes for bugs
+> present in the latest release, but not those introduced later),
+> or documentation and performance improvements.
+> 
+> > Fedora 19 appears to be packaging patches from v204-stable branch
+> > which I can't find anywhere public.
+> It's my private branch I generate Fedora packages from [1]. It's the
+> same content as in Fedora git repos [2], but in a more convenient form
+> for me. I talked with other systemd maintainers in Fedora about making
+> it more official and public, but we haven't found the time to do it
+> yet. If it was to be useful to other people, it can certainly be done.
+> 
+> [1] http://kawka.in.waw.pl/git/systemd/
+> [2] http://cgit.freedesktop.org/systemd/systemd/
+Hi,
+
+stable branches have a new official home:
+http://cgit.freedesktop.org/systemd/systemd-stable/
+
+The policy wrt. to bugfixes and stable branches is described in
+http://www.freedesktop.org/wiki/Software/systemd/Backports/.
+
+Zbyszek
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Mar 2014 18:57:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Colin Watson <cjwatson@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Mar 2014 18:57:04 GMT) (full text, mbox, link).

+ +

Message #7585 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Colin Watson <cjwatson@debian.org>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Sun, 2 Mar 2014 18:55:49 +0000
+
+
I ran across this interesting post from an upstream GNOME developer
+which I think deserves some signal-boosting, as I haven't seen much of
+its contents mentioned or alluded to so far in this thread, and it's
+quite relevant to how much we should expect this to be a problem:
+
+  http://blogs.gnome.org/desrt/2014/02/19/on-portability/
+
+Aside from an anonymous troll (it's a shame everyone even remotely
+involved appears to have to deal with those these days), his comments
+seem to have pretty broad support among the other GNOME developers I
+recognise who've commented.
+
+-- 
+Colin Watson                                       [cjwatson@debian.org]
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Mar 2014 19:45:07 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Mar 2014 19:45:07 GMT) (full text, mbox, link).

+ +

Message #7590 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Colin Watson <cjwatson@debian.org>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Sun, 02 Mar 2014 11:42:01 -0800
+
+
Colin Watson <cjwatson@debian.org> writes:
+
+> I ran across this interesting post from an upstream GNOME developer
+> which I think deserves some signal-boosting, as I haven't seen much of
+> its contents mentioned or alluded to so far in this thread, and it's
+> quite relevant to how much we should expect this to be a problem:
+
+>   http://blogs.gnome.org/desrt/2014/02/19/on-portability/
+
+> Aside from an anonymous troll (it's a shame everyone even remotely
+> involved appears to have to deal with those these days), his comments
+> seem to have pretty broad support among the other GNOME developers I
+> recognise who've commented.
+
+I want to reiterate here, since it's easy to lose in the long discussions,
+that I completely agree with the sentiments here.  I like the idea of
+standardized services, I like having the flexibility of multiple
+implementations of those services and use that flexibility quite a bit
+myself, and would generally prefer for multiple implementations to be
+possible in any case where there are multiple ways of going about
+something.
+
+However, I also don't think those principles were ever what this debate
+was about.  I don't think you'll find much disagreement with those as
+general principles.
+
+The question that was before us, and which is now likely to be before the
+project as a GR, is not whether we approve of standard interfaces and
+multiple implementations.  Everyone, from the GNOME upstream to the GNOME
+package maintainers through the systemd maintainers, has indicated support
+for allowing multiple implementations of standard interfaces.  Rather, the
+question that was before us was about the error case.  When circumstances
+arise where those multiple implementations do not exist, who bears the
+burden of creating them?
+
+The position of loose coupling is that the Debian contributor who wants to
+package a piece of software is responsible for porting it to every major
+init system.
+
+The position for which I was advocating is that the people who are
+interested in having software run on the non-default init system, who
+*may* include the Debian contributor who is packaging it but *might not*,
+are responsible for the porting work, and that packaging of the software
+for Debian should not necessarily block on that work being completed.
+
+In other words, I'm advocating the same position that we have right now
+for translations: the package maintainer is not expected to translate
+their package to other languages, but they are expected to incorporate
+translations as they are made available.  The translators bear the burden
+of the work for doing the translation, and if no one steps up to translate
+a particular package to some language, it won't be available in that
+language.
+
+To take the specific example of GNOME, in a world in which there are
+multiple implementations of logind that satisfy the same interface, there
+is no conflict here.  I want to keep reiterating that, since it seems like
+people keep thinking they're at war with others when no actual conflict
+exists.  The GNOME maintainers have already said they'd be happy to allow
+alternative dependencies, the systemd maintainers have already said they'd
+be happy to work with the providers of alternative logind implementations
+to sort out the proper dependency and package structure, GNOME upstream
+has said that they'd be delighted for such a thing to exist, and everyone
+would be happy to have this in place by jessie.  We're all a big happy
+family on this point, even if some of the people in the back seat can't
+stop poking each other.  :)
+
+*All* of this argument is over what happens when those multiple
+implementations don't actually materialize.
+
+My continued objections to loose coupling is that I think it makes the
+wrong choice in that contingency, and I think it does so in a way that's
+destructive to Debian as a project.  I believe the loose coupling proposal
+attempts to force Debian contributors to care about something they don't
+necessarily care about as the bar to entry in the project.
+
+Now, that is appropriate to some extent, since the goal of Debian is to
+create a distribution, not a random collection of packages.  But
+historically (and this line is what Policy is *all about*, so I've had a
+lot of practical experience with it), we've tried to limit the places
+where we make this sort of requirement to two types of problems: places
+where the package simply has to work a particular way or it won't be
+functional or may break the rest of the system, and places where the
+amount of effort required for the maintainer is reasonably small.  So, for
+example, if you package a shared library, you have to care about shlibs or
+symbols, SONAMEs, and library package naming.  That's just the way it is;
+we rely on those mechanisms to make shared libraries work properly, and
+your package is broken and will break other things if you don't follow
+those rules.  Or, for the second point, your package should not strip
+binaries if DEB_BUILD_OPTIONS=nostrip is set.  This is generally quite
+easy to do, and normally the standard tools do it for you, so there aren't
+a lot of good reasons for not supporting this.
+
+Porting GNOME to something other than logind, or implementing logind
+without its various systemd requirements, is neither of these things.
+It's not something that has to be done or the packages are simply broken,
+as demonstrated by the fact that they would work fine with the default
+init system (which was, at least as far as I'm concerned, chosen for
+different reasons than this whole argument).  And it's not a small amount
+of work.
+
+If people do the work, great!  Everyone thinks that's great, as noted
+above.  We define a virtual package that provides the necessary
+interfaces, multiple maintenance teams happily maintain multiple
+implementations going forward, and we move on with our lives.  We all hope
+that's the situation that we end up in.
+
+But when providing project-wide guidance, we have an obligation to worry
+about the error conditions as well.  If multiple logind implementations do
+*not* materialize, or if they do materialize but then people lose interest
+or run out of time and stop maintaining them and they stop being viable,
+loose coupling says that the burden now falls on the GNOME package
+maintainers to do all the work to write or maintain an alternative logind
+implementation.  For init systems they don't use or for systems they don't
+use.
+
+The project that would assign work in that way is not the sort of project
+that I want to be part of.  That's not cooperation and coordination and
+working together.  That's holding someone's work hostage to try to force
+them to do (substantial) work that they're not interested in.  I think
+it's directly contrary to the spirit of section 2.1.1 of the constitution,
+and it makes me very unhappy.
+
+We all want there to be multiple implementations of standard, reasonable
+APIs so that we can choose software based on its merits and not because
+it's the only implementation of a useful interface.  We also all live in
+the real world where that doesn't always happen.  The work doesn't
+magically accomplish itself.  Someone has to care enough to make it
+happen.  If no one cares enough, then I think we need to recognize that
+maybe having multiple implementations isn't important enough to motivate
+anyone to volunteer to do it, and therefore we'll have to live without the
+benefits of having them.
+
+If that feels like an unacceptable outcome, well, I think the right
+reaction is to go do the work so that this outcome doesn't arise.  Not to
+try to write project rules to force other people who are less interested
+in the work or who may not agree with the acceptability of the outcome to
+do the work on our behalf.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Mar 2014 20:03:04 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Mar 2014 20:03:04 GMT) (full text, mbox, link).

+ +

Message #7595 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: 727708@bugs.debian.org
+
Cc: Colin Watson <cjwatson@debian.org>
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Sun, 02 Mar 2014 11:59:05 -0800
+
+
I have reposted an improved version of this reply to debian-project and
+debian-vote, in response to the proposed GR, since I think the TC work has
+concluded and that's now the appropriate forum for the conversation.  We
+can keep talking about it here if that seems like a good idea for some
+reason that I'm missing, but it may be best to respond there instead to
+make it easier for those following the proposed GR discussion to see.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Mar 2014 20:15:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Bdale Garbee <bdale@gag.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Mar 2014 20:15:05 GMT) (full text, mbox, link).

+ +

Message #7600 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: Colin Watson <cjwatson@debian.org>, 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Sun, 02 Mar 2014 13:00:06 -0700
+
+
[Message part 1 (text/plain, inline)]
+
Colin Watson <cjwatson@debian.org> writes:
+
+> I ran across this interesting post from an upstream GNOME developer
+> which I think deserves some signal-boosting ...
+
+Indeed.  Thanks for the pointer.
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Mar 2014 20:21:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Thorsten Glaser <tg@mirbsd.de>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Mar 2014 20:21:05 GMT) (full text, mbox, link).

+ +

Message #7605 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Thorsten Glaser <tg@mirbsd.de>
+
To: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Sun, 2 Mar 2014 20:13:55 +0000 (UTC)
+
+
Russ Allbery dixit:
+
+>But when providing project-wide guidance, we have an obligation to worry
+>about the error conditions as well.  If multiple logind implementations do
+>*not* materialize, or if they do materialize but then people lose interest
+
+I question why logind is needed in the first place.
+Current-day systems are getting way too complex and complicated;
+we did not need something like this a few months ago either.
+
+*That’s* what my problem with systemd is.
+
+----
+
+Real follow-up question: will a user be able to install jessie
+with anything but systemd as init? (As opposed to an upgrade
+from wheezy, which will work anyway.) And what about jessie+1?
+
+Thanks,
+//mirabilos
+-- 
+<mirabilos> Owāte Jong… isch owāte disch gleisch…
+<Natureshadow> Ich kenn nur Oblate
+<mirabilos> Lernenz Platt
+<Natureshadow> Ich bin zu dick für Platt
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Sun, 02 Mar 2014 20:30:05 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to Russ Allbery <rra@debian.org>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Sun, 02 Mar 2014 20:30:05 GMT) (full text, mbox, link).

+ +

Message #7610 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Russ Allbery <rra@debian.org>
+
To: Thorsten Glaser <tg@mirbsd.de>
+
Cc: 727708@bugs.debian.org
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Sun, 02 Mar 2014 12:26:31 -0800
+
+
Thorsten Glaser <tg@mirbsd.de> writes:
+> Russ Allbery dixit:
+
+>> But when providing project-wide guidance, we have an obligation to
+>> worry about the error conditions as well.  If multiple logind
+>> implementations do *not* materialize, or if they do materialize but
+>> then people lose interest
+
+> I question why logind is needed in the first place.  Current-day systems
+> are getting way too complex and complicated; we did not need something
+> like this a few months ago either.
+
+The link that Colin posted provides a fairly good summary of why logind is
+attractive from the perspective of a GNOME maintainer.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+
+ +

+ + + +Information forwarded +to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
+Bug#727708; Package tech-ctte. + (Mon, 03 Mar 2014 00:24:10 GMT) (full text, mbox, link).

+ +

+ + + +Acknowledgement sent +to <usspookslovesystmd@muchomail.com>:
+Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. + (Mon, 03 Mar 2014 00:24:10 GMT) (full text, mbox, link).

+ +

Message #7615 received at 727708@bugs.debian.org (full text, mbox, reply):

+
+ +
From: "NoTo CTTE" <usspookslovesystmd@muchomail.com>
+
To: "Russ Allbery" <rra@debian.org>, <727708@bugs.debian.org>
+
Cc: <tg@mirbsd.de>, <727708@bugs.debian.org>, <debian-users@bugs.debian.org>, + <debian-devel@bugs.debian.org>, <debian-project@bugs.debian.org>, + <debian-ctte@bugs.debian.org>, <scott.ferguson.debian.user@gmail.com>, + <debian-devel@lists.debian.org>, <debian-ctte@lists.debian.org>, + <debian-vote@lists.debian.org>, <debian-project@lists.debian.org>, + <linux-kernel@vger.kernel.org>, <pascal@plouf.fr.eu.org>, + <yaro@marupa.net>, <cbannister@slingshot.co.nz>, + <andreimpopescu@gmail.com>, <ghaverla@materialisations.com>, + <debian-mirrors@lists.debian.org>, <debian-security@lists.debian.org>
+
Subject: Re: Bug#727708: Call for Votes on init system coupling
+
Date: Sun, 2 Mar 2014 14:43:16 -0800
+
+
Why should we believe you or the bullshit excuses given in the article?
+
+The fact is, last year none of this crap was needed.
+Now it suddenly is.
+Furthermore gnome stole libgtk from the gimp project recently
+and then they made an incompatable "libgtk" 3.0.
+
+And now they're requiring all these bullshit daemons, and systemd.
+
+This is a political coup. We are being lead by the nose.
+Notice the arguments from the gnome and systemd people are always the same
+across all forums, for years.
+
+"It is for your own good"
+"You must join the modern era"
+They know better than us and we must join.
+Over and over again for the past year or two.
+
+I think these are the same people.
+Fake personas, or directed by their employers.
+
+They should be thrown out, we should recongise them for what they are.
+
+Real, traditional linux includes
+sysv or bsd style init (or openrc).
+libgtk2 (not 3). 
+gnome2 (not 3).
+
+And no systemd.
+
+We should also take heed of Snowden's documents which show that
+the United States government, which is an evil force that 
+blows up and burns alive little girls and boys in afghanistan
+iraq and elsewhere, had and has a program to subvert technology
+and software projects everywhere.
+
+Systemd and its shills are likely part of this.
+They should be thrown out of our community distributions.
+Pretty much anything by redhat is harmful nowadays.
+And anyone associated.
+
+--- rra@debian.org wrote:
+
+From: Russ Allbery <rra@debian.org>
+To: Thorsten Glaser <tg@mirbsd.de>
+Cc: 727708@bugs.debian.org
+Subject: Bug#727708: Call for Votes on init system coupling
+Date: Sun, 02 Mar 2014 12:26:31 -0800
+
+Thorsten Glaser <tg@mirbsd.de> writes:
+> Russ Allbery dixit:
+
+>> But when providing project-wide guidance, we have an obligation to
+>> worry about the error conditions as well.  If multiple logind
+>> implementations do *not* materialize, or if they do materialize but
+>> then people lose interest
+
+> I question why logind is needed in the first place.  Current-day systems
+> are getting way too complex and complicated; we did not need something
+> like this a few months ago either.
+
+The link that Colin posted provides a fairly good summary of why logind is
+attractive from the perspective of a GNOME maintainer.
+
+-- 
+Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
+
+
+-- 
+To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
+with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
+Archive: https://lists.debian.org/87vbvwfitk.fsf@windlord.stanford.edu
+
+
+
+
+
+_____________________________________________________________
+The Free Email with so much more!
+=====> http://www.MuchoMail.com <=====
+
+
+
+ +

+ + + +Reply sent +to Bdale Garbee <bdale@gag.com>:
+You have taken responsibility. + (Tue, 18 Mar 2014 18:06:16 GMT) (full text, mbox, link).

+ +

+ + + +Notification sent +to Paul Tagliamonte <paultag@debian.org>:
+Bug acknowledged by developer. + (Tue, 18 Mar 2014 18:06:16 GMT) (full text, mbox, link).

+ +

Message #7620 received at 727708-done@bugs.debian.org (full text, mbox, reply):

+
+ +
From: Bdale Garbee <bdale@gag.com>
+
To: 727708-done@bugs.debian.org
+
Subject: resolved
+
Date: Tue, 18 Mar 2014 12:04:17 -0600
+
+
[Message part 1 (text/plain, inline)]
+
This issue was decided by committee vote concluded 11 Feb 2014:
+
+  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6734
+
+Bdale
+
+
[Message part 2 (application/pgp-signature, inline)]
+ +

+ + + + + + + +Bug archived. +Request was from Ian Jackson <ijackson@chiark.greenend.org.uk> +to control@bugs.debian.org. + (Thu, 20 Mar 2014 11:27:20 GMT) (full text, mbox, link).

+ +

+ + + + + + + +Removed indication that bug 727708 blocks 726763 +Request was from Andreas Cadhalpun <andreas.cadhalpun@googlemail.com> +to control@bugs.debian.org. + (Tue, 06 May 2014 14:49:01 GMT) (full text, mbox, link).

+ +
+

Send a report that this bug log contains spam.

+
+
Debian bug tracking system administrator <owner@bugs.debian.org>. +Last modified: +Tue Nov 29 23:32:42 2022; +Machine Name: +buxtehude +

+Debian Bug tracking system +

+

+ Debbugs is free software and licensed under the terms of the GNU + Public License version 2. The current version can be obtained + from https://bugs.debian.org/debbugs-source/. +

+

+Copyright © 1999 Darren O. Benham, +1997,2003 nCipher Corporation Ltd, +1994-97 Ian Jackson, +2005-2017 Don Armstrong, and many other contributors. +

+
+ + + diff --git a/newsboat/urls b/newsboat/urls index 7814d4e5..fbf882e7 100644 --- a/newsboat/urls +++ b/newsboat/urls @@ -6,4 +6,7 @@ https://gabmus.org/index.xml https://www.wilfred.me.uk/rss.xml https://interrupt.memfault.com/feed.xml https://www.brain-dump.org/index.xml +https://planet.debian.org/rss20.xml file://./rss/VYPJXZwH.rss +file://./rss/ewontfix.rss +file://./rss/0pointer.rss diff --git a/updates.txt b/updates.txt index ec2e039a..620ffa57 100644 --- a/updates.txt +++ b/updates.txt @@ -188,6 +188,7 @@ Go to Chrome store and install CSS Dig on brave Install slop and gifsicle and libimage-exiftool-perl and rebuild-detector and keynav and dvtm and dtach and lowdown and inotify-tools -doas pacman -S slop gifsicle libimage-exiftool-perl rebuild-detector keynav dvtm lowdown inotify-tools +doas pacman -S slop gifsicle libimage-exiftool-perl rebuild-detector keynav dvtm +lowdown inotify-tools lynis paru dtach sherlock-git