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

[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)]
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



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



[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)]
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



[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)]
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



[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)]
[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)]
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/>



[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)]
-----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-----



[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)]
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
: :' :
`. `'
  `-




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.



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/



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
 



[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)]
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



[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)]
[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)]
[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)]
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/>



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



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/>



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



[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)]
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



* 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



* 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



[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)]
[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)]
[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)]
[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)]
[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)]
[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)]
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/>



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)



[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)]
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



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/



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



]] 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



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



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



[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)]
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/>



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




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



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/>



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



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



]] 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



[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)]
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/



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



* 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



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



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



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.



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.



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/>



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



[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)]
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



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/>



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



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



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/>



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.



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



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



[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)]
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



[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)]
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/>



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



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
: :' :
`. `'
  `-




[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)]
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/>



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



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/>



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



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



]] 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



* 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



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



* 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



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/>



* 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



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



"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/>



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



* 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



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



[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)]
[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)]
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/>



* 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



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



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



[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)]
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".



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/>



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



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




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



[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)]
[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)]
[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)]
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

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.



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.





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



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



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
: :' :
`. `'
  `-




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.



[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)]
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
: :' :
`. `'
  `-




* 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



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





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



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



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
: :' :
`. `'
  `-




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



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






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



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




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/>



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/



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.



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.



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.




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/>



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



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




]] 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



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.



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
: :' :
`. `'
  `-




[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)]
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/>



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/>



[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)]
[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)]
[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)]
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/>



[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)]
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
: :' :
`. `'
  `-




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



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?





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/>



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/>



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/>



]] 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



]] 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



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/>



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?



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



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.



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/>



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
: :' :
`. `'
  `-




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.



[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)]
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




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



[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)]
[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)]
[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)]
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

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




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



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.



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/>



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.



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.



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.



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.



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.



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.



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.





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



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



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



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




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
: :' :
`. `'
  `-




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




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/>



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




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




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/>



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/>



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
: :' :
`. `'
  `-




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



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/>



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




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
: :' :
`. `'
  `-




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.





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




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



]] 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



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




[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)]
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




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
: :' :
`. `'
  `-




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>



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




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
: :' :
`. `'
  `-




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




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




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.





]] 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



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/>



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/>



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.



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.



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]



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]



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.



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/>



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/>



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]



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.



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/>



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/>



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/>



[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)]
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




]] 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



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




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.



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.



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]



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



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



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/>



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/>



[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)]
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]



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/>



[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)]
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
: :' :
`. `'
  `-




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





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/>



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.



[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)]
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/>



* 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



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/>



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/>



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



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.



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/>



* 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



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/>



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/>



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/>



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.



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/>



* 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



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
: :' :
`. `'
  `-




]] 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



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/>



]] 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



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.





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/>



* 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



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?




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/>




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?




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/>



]] 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



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/>



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



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/>



]] 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



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



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



#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]



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




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



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/>



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



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



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



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




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]



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/>



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.



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.



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.



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.



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
: :' :
`. `'
  `-




[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)]
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/>



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/>



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/>



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/>



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/>



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/>



[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)]
[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)]
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/>



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



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/>



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/>



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/>



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





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





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/>



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





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/>



[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)]
[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)]
[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)]
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/



[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)]
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
: :' :
`. `'
  `-




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]



]] 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



]] 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



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.





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/>



[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)]
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/>



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/>



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.





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/>



]] 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



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/>



]] 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




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



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.





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



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/>



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



[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)]
]] 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



[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)]
[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)]
[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)]
]] 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



[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)]
* 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.).



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/>



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/>



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/>



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.



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=



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/>



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.



]] 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



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



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/



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/>



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.



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.



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/>



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/>



[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)]
[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)]
[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)]
[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)]
]] 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



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/>



[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)]
[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)]
]] 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



[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)]
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/>



]] 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



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



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/>



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/>



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



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



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





[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)]
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/>



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



[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)]
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/>



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



[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)]
[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)]
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



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]



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]



[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)]
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/>



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



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/>



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





[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)]
[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)]
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



[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)]
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/>



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/>



[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)]
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.«



]] 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



[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)]
[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)]
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



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



* 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



[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)]
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/>



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.



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.



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.



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/>



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



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.



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.



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.



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



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




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/>



[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)]
[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)]
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/>



]] 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



]] 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



]] 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



[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)]
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
: :' :
`. `'
  `-




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




[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)]
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/>



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/>



[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)]
[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)]
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



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



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.



]] 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



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



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/>



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
: :' :
`. `'
  `-




[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)]
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
: :' :
`. `'
  `-




[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)]
[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)]
[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)]
[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)]
[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)]
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/>



[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)]
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]



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]



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



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




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



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]



[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)]
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".





[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)]
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.«



[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)]
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.«



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



[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)]
> 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



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



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



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
: :' :
`. `'
  `-




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
: :' :
`. `'
  `-




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]



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.



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.





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/>



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/>



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/>



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.



]] 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



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/>



[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)]
]] 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



[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)]
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/>



[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)]
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.«



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.



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/



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



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



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



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.



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



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.



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



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



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/>



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.



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/>



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/>



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
: :' :
`. `'
  `-




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.



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.



[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)]
]] 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



]] 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



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/>



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.



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]



| 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



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.



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/>



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.



[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)]
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



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/>



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
: :' :
`. `'
  `-




> 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



[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)]
[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)]
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



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



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>



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/



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.




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.



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.




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.



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



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.





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.



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



"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/>



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.



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/>



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/>



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/>



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/>



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?





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/>



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.



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/>



[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)]
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/>



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



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



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.





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



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/>



[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)]
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)




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>



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.



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.



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
: :' :
`. `'
  `-




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/>



[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)]
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



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.



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.



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.



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/>



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/>



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/>



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.



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.



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



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.



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.



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/>



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/>



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.



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/>



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.



[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)]
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/>



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



]] 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



]] 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



[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)]
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



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



[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)]
]] 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



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??




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>



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



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



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.



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.



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/>



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.



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/>



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.



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/>



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/>



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.



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.



[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)]
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/>



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/>



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



[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)]
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/>



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/>



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



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



]] 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



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>



[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)]
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
: :' :
`. `'
  `-




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



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



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



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

-- 
Алексей Шилин
Алексей Шилин 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



[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)]
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/



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



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.



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)



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



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.



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?



Понедельник, 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.


-- 
Алексей Шилин

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/>



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/>



[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)]
[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)]
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




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.



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



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.



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.



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?



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



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.



[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)]
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




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.



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
: :' :
`. `'
  `-




[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)]
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




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/>



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.



[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)]
[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)]
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



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



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/>



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



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



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)



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)



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



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



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



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



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



[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)]
[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)]
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
: :' :
`. `'
  `-





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



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.



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



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.



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





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/>



]] 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



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



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/>



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




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



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.





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/>



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.



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



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



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



[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)]
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



[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)]
[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)]
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)



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.



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)



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.



[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)]
]] 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



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



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
: :' :
`. `'
  `-




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



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
: :' :
`. `'
  `-




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.




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



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.




[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)]
[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)]
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?



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



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



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/>



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




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/>



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.





[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)]
[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)]
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.«



[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)]
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/>



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 



[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)]
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



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/>



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>



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




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,



]] 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



* 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



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




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.



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



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/>



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/>



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/>



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



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




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




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/>



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




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/>



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




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)



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 :/




]] 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



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/>



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




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/>



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.



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




[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)]
* 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



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.



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



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



]] 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



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



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




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



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



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'



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
: :' :
`. `'
  `-




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



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



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




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




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/>



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.




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/>



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/>



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



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.



[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)]
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/



[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)]
[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)]
[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)]
[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)]
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.«



[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)]
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/>



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>



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/>



[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)]
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... ;))




[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)]
]] 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



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)




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/>



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.



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.



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.



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.



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.



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



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.



[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)]
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



[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)]
* 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



[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)]
[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)]
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.«



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



[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)]
[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)]
[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)]
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



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



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>



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.



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



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



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"



[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)]
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]



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.





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/>



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




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



[Message part 1 (text/plain, inline)]
Actually systemd might be better than upstart.
-- 
Pouar

[Message part 2 (text/html, inline)]
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.



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.



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.



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.



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/>



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.



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
: :' :
`. `'
  `-




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/>



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.



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.



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
: :' :
`. `'
  `-




[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)]
[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)]
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



[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)]
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



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



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



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



]] 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



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




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




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




[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)]
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



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
: :' :
`. `'
  `-




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.



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.



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.



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)



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



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



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



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.



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



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.



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?



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



[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)]
[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)]
[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)]
[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)]
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




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




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




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.



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.



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.



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.



[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)]
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/>



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.



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.



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/>



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



[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)]
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



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



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"



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




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



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.





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>



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



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.




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



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



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.



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.



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/>



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.




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

	





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.



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
: :' :
`. `'
  `-




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.
 



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]



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




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




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




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



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
: :' :
`. `'
  `-




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




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
: :' :
`. `'
  `-




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




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
: :' :
`. `'
  `-




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/>



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




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/



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



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




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/>



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



[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)]
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



[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)]
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/>



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.



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



2014-01-30 ChaosEsque Team <chaosesqueteam@yahoo.com>:
>  [bullshit]

Wasn't there some kind of a ban applied here?
I am confused.
Cheers,
    Matthias



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.



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?



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.



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



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.



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.



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



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.



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!




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.



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



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.



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/



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*



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.



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.



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



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?



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
: :' :
`. `'
  `-




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



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.






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.



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.



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.

-- 



[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)]
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



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



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



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)



  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



[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)]
[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)]
[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)]
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/



[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)]
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



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
: :' :
`. `'
  `-




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
: :' :
`. `'
  `-




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



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



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.



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.



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!





[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)]
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
: :' :
`. `'
  `-




[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)]
[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)]
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




[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)]
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



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



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.



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.





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



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.



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/>



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



[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)]
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/>



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



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/>



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



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



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



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





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



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



[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)]
[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)]
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



[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



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



[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)]
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/>



[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)]
[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)]
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



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



[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)]
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/>



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.



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




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]



]] 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



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/>



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/>



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




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



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.



[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)]
[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)]
[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)]
[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)]
[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)]
[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)]
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



[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)]
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



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.



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




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.



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?



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.



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.



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.



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.



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




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.



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.

-- 



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



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.



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


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/>



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



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



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



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



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



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



 



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



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]



]] 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



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.





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



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



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.



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.



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. :(



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.

-- 



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.



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



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.



[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)]
* 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



* 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



[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)]
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



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




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




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




[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)]
* 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



* 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



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




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.



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



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.



[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)]
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



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]



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]



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




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]



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!



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?



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



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.



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.



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



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.



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




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



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




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




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



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/>



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.



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>



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




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>



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/>



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/>



[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)]
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



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>



[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)]
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-



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]



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.



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]



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.



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.



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]



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]



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



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.



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.



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



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
: :' :
`. `'
  `-




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.



[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)]
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/




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



[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)]
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]



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.



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.



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



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




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




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



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.



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




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




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.



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




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.



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



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




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



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




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.



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.



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




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>



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




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/>



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




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>



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/>



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



[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)]
[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)]
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




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/>



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



[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)]
* 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



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. 		 	   		  


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



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






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



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.



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]



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



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.



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.



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.



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.



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.



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]



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.



[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)]
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



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.



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:



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]



[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)]
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]



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



[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)]
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]



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.



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



>>>>> "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



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



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.



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.



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




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.



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




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




[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)]
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




[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)]
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




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/>



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



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



"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/>



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




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/>



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.



[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)]
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




[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)]
[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)]
[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)]
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




[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)]
[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)]
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.«



[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)]
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/>



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



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



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



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



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



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



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.



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




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.





[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)]
[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)]
[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)]
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/>



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/>



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/>



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




[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)]
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/>



[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)]
[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)]
[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)]
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)



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/>



[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)]
[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)]
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



[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)]
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/>



[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)]
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/>



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



[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)]
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



[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)]
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/>



[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)]
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/>



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/>



[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)]
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



[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)]
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



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/>



[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)]
]] 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



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



]] 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



[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)]
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



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



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>



[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)]
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



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




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



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



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



[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)]
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?



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



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



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



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



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



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



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.



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.



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:

-- 



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




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 :-(  




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.



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.



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



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.



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/>



[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)]
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



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



[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)]
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/>



[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)]
[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)]
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>



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



[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)]
[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)]
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



oops.. that was supposed to be a private message, sorry for the noise.
Please remove this one and my previous one.



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



[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)]
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



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



[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)]
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."




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



[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)]
[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)]
[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)]
[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)]
[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)]
[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)]
* 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



* 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



* 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



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



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




[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)]
[Message part 1 (text/plain, inline)]

[Message part 2 (message/rfc822, 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

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!


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



[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)]
[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)]
[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)]
[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)]
>>>>> "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.



[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)]
[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)]
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



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.



[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)]
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




[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)]
[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)]
[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)]
[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)]
[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)]
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/




[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)]
]] 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



[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)]
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/>



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




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




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]



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.



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



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



[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)]
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/>



[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)]
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




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/>



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.



[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)]
[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)]
[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)]
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



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




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




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.



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>



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



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.





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/>



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.



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.



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.



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.



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



  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



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



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]



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.



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



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



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.



* 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



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]



[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)]
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/>



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/>



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/>



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
: :' :
`. `'
  `-




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.



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



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
: :' :
`. `'
  `-




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



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.



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



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.



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.



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





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



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>



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



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/>



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/>



[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)]
[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)]
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?



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/>



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



[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)]
* 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



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



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



* 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



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)



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




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/>



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




> > 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? :))




Поштовани: Рачун корисника,

Ова порука је из центра за подршку система Администратор. Будите информисани
да је ваша е-маил налог је премашио границу складиштење је поставио ваш
администратор / база података, који тренутно ради из контекста и ви
не може бити у могућности да шаљете или примате неку нову пошту док вас
поново потврдите
Ваш е-маил налог.

Да бисте спречили свој налог е-поште из било затворено, поново потврдите
своје поштанско сандуче

унесите испод информације исправно.

Е-маил адреса:
Кориснику ИД:
Шифра:
Потврди лозинку:

Ваш налог ће остати активан након успешно потврдили
детаљима свог налога. Хвала вам на брзом одговору на ово
обавештење извињавамо се због неугодности.
Ценимо вашу континуирану помоћ и подршку.
С поштовањем,
СИСТЕМ АДМИНИСТРАТОР ХЕЛПДЕСК ТИМ 2014
Вебмаил Администратор
Eunet.rs











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




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



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
> 



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



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



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/>



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)



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/>



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:

========================================



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.



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]



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]



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.



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]



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/>



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




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.



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.



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



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.



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.



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]



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]



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.



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.



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/>



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.



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.



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.



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/>



[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)]
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/>



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/>



* 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



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.



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.



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.



]] 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




* 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



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.



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.



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.



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]



[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)]
* 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



* 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



* 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



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.



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.



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



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/>



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/>



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.



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.

-- 



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.

-- 



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.



[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)]
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_



[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)]
[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)]
[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)]
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



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



* 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



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



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




[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)]
[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)]
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



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]



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/>



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/>



[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)]
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



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/>



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 <=====



[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)]

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

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