Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Russ Allbery]

Lucas Nussbaum  writes:

> During the TC discussions in January/February 2014, the TC had a small
> legitimacy crisis, that resulted in the GR override clause of the
> default init resolution. I hope that the result of this GR will be able
> to serve as input in future TC discussions on similar/related topics.

As one of the people who thought that clause was a good idea, I don't
think that it's only there due to a legitimacy crisis.  My opinion then,
which continues to be my position now, is that requiring a supermajority
to overrule the TC is a mistake.  The bar for a GR is already high enough,
and we, as a project, already tend to defer to existing decisions.  I
think that's enough protection against unnecessary reversals, and I think
a TC decision opposed by 60% of the project but still enforced is a very
unhealthy place to be.

The clause allowing an override by simple majority was a hack to disable
the constitution's super-majority requirement.  I continue to be in favor
of a constitutional amendment to remove the super-majority requirement for
TC overrides via GR in general, thus eliminating the need for such hacks.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738agrqy1@hope.eyrie.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Lucas Nussbaum]

Hi,

On 20/10/14 at 14:47 -0400, Sam Hartman wrote:
> > "Joey" == Joey Hess  writes:
> 
> Joey> Why not just make your proposal be something along the lines
> Joey> of reaffirming the technical decision-making process as it
> Joey> currently stands, from the package maintainers, to the policy,
> Joey> to the TC.  It could implicitly or explicitly reaffirm both
> Joey> recent TC decisions on init systems.
> 
> I'd support very strongly something like this, no more than one or two
> more paragraphs like the above.

I think that this is what Charles' proposal does now.

And my personal hope is that it will be the winning option, preferably
with FD beating all three other options.

However, I don't plan to withdraw my own proposal. Given that we are
going to vote anyway, it will be useful to have a representative set of
options for the general technical directions that Debian could take on
this set of questions, in order to estimate what the project wants.

During the TC discussions in January/February 2014, the TC had a small
legitimacy crisis, that resulted in the GR override clause of the
default init resolution. I hope that the result of this GR will be able
to serve as input in future TC discussions on similar/related topics.

Lucas


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Jonas Smedegaard]

Quoting Nikolaus Rath (2014-10-21 02:41:12)
> Ian Jackson  writes:
>> Nikolaus Rath writes ("Re: Alternative proposal: support for alternative 
>> init systems is desirable but not mandatory"):
>>> I just don't understand why you consider uselessd a "trick" that I came
>>> up with (leaving alone the fact that David brought it up here, and that
>>> yet another guy started the project).
>>
>> When I read someone mention uselessd before, I thought it was a
>> hypothetical fork of systemd which was nearly identical to systemd.
>>
>> I think uselessd, if it is successful, deals squarely with many of the
>> actual reasons why people don't like systemd: systemd's tendency to
>> try to be everything.  That is the real coupling threat - not the lack
>> of ability to continue to use init scripts.
>>
>> So I think in practice there aren't going to be many packages that
>> would want to couple specifically to systemd _or_ uselessd, but where
>> support for other init systems is hard to provide.
>
> So just to be clear: A package requiring either uselessd or systemd
> would be acceptable in Debian if your GR proposal passes?

Yes.

This GR is not anti-systemd, it is pro-choice-if-init-system.

In case you also lack an executive summary of that: The last GR was not 
which-init-system, but which-system-by-default.

This GR is not anti-last-GR but refining -what-else-than-default with 
-and-more-than-default-must-be-supported.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Nikolaus Rath]

Ian Jackson  writes:
> Nikolaus Rath writes ("Re: Alternative proposal: support for alternative init 
> systems is desirable but not mandatory"):
>> I just don't understand why you consider uselessd a "trick" that I came
>> up with (leaving alone the fact that David brought it up here, and that
>> yet another guy started the project).
>
> When I read someone mention uselessd before, I thought it was a
> hypothetical fork of systemd which was nearly identical to systemd.
>
> I think uselessd, if it is successful, deals squarely with many of the
> actual reasons why people don't like systemd: systemd's tendency to
> try to be everything.  That is the real coupling threat - not the lack
> of ability to continue to use init scripts.
>
> So I think in practice there aren't going to be many packages that
> would want to couple specifically to systemd _or_ uselessd, but where
> support for other init systems is hard to provide.

So just to be clear: A package requiring either uselessd or systemd
would be acceptable in Debian if your GR proposal passes?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjcqtftj@vostro.rath.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Joey Hess]

Sam Hartman wrote:
> > "Joey" == Joey Hess  writes:
> 
> Joey> Why not just make your proposal be something along the lines
> Joey> of reaffirming the technical decision-making process as it
> Joey> currently stands, from the package maintainers, to the policy,
> Joey> to the TC.  It could implicitly or explicitly reaffirm both
> Joey> recent TC decisions on init systems.
> 
> I'd support very strongly something like this, no more than one or two
> more paragraphs like the above.

I consider Charles Plessy's proposal to do this, more or less.
(Enough that I don't think another proposal would be worthwhile.)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Sam Hartman]

> "Joey" == Joey Hess  writes:

Joey> Why not just make your proposal be something along the lines
Joey> of reaffirming the technical decision-making process as it
Joey> currently stands, from the package maintainers, to the policy,
Joey> to the TC.  It could implicitly or explicitly reaffirm both
Joey> recent TC decisions on init systems.

I'd support very strongly something like this, no more than one or two
more paragraphs like the above.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/01492ee2524a-68f800f4-1794-43fe-b81a-c3f9f5d55221-000...@email.amazonses.com

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Martinx - ジェームズ]

+1 keep `sysvint-core` in Debian *at a reliable level*, is a wise thing to
do. For at least, 2018~2020.

On 19 October 2014 18:40, Jonas Smedegaard  wrote:

> Quoting Nikolaus Rath (2014-10-19 20:16:37)
> > Jonas Smedegaard  writes:
> >> Quoting David Weinehall (2014-10-19 16:13:18)
> >>> On Sun, Oct 19, 2014 at 02:28:02PM +0100, Ian Jackson wrote:
> >>> [snip]
> >>>
>  The wording in my resolution comes from the TC discussion and
>  specifies `at least one' or `some alternative'.  To represent that
>  as `all' is IMO misleading.
> 
>  One important difference between `all' and `at least one' is this:
>  suppose there is some init system that does not support the common
>  interface you suppose in your point (2).  Saying `all' suggests
>  that it is somehow the fault of the packages which deal with the
>  common interface.  This point was raised in the TC discussion.
> 
>  Saying `all' gives the impression that every package must do work
>  for each init system.  That is why my proposal's wording simply
>  says that packages are forbidden from requiring `a specific' init
>  system.
> >>>
> >>> OK, so packaging uselessd (thus providing another init system that
> >>> provides -- most of -- the systemd interfaces) would solve all your
> >>> worries?
> >>
> >> There are many ways to twist words, yes.
> >
> > I think this deserves a better answer.
> >
> > Do you consider uselessd to be the same init system as systemd? To me
> > this looks like a legitimate fork.
> >
> > Or are you saying that "at least one" is really meant to mean "at least
> > one not-systemd derived"?
>
> My concern is not systemd specifically - on the contrary I find it great
> if it brings more choice to Debian, which seems to be the status
> currently.
>
> My concern is also not the risk that Debian could be locked into "only
> two" or "only three" init systems - I believe we need not deal with that
> until the risk of such scenario eventually becomes realistic - if we
> then concider such scenario a concern.
>
> My concern now is to ensure that Debian supports more than a single init
> system.
>
> I sincerely hope that I made myself more clear this time, and that you
> found my response adequate and we can move on.
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Jonas Smedegaard]

Quoting Nikolaus Rath (2014-10-20 05:29:10)
> Jonas Smedegaard  writes:
>> Quoting Nikolaus Rath (2014-10-19 20:21:59)
>>> Ian Jackson  writes:
>>>> David Weinehall writes ("Re: Alternative proposal: support for alternative 
>>>> init systems is desirable but not mandatory"):
>>>>> OK, so packaging uselessd (thus providing another init system that 
>>>>> provides -- most of -- the systemd interfaces) would solve all 
>>>>> your worries?
>>>>
>>>> This resolution will be interpreted by humans, specifically 
>>>> individual maintainers, the TC, and the release team - not by 
>>>> robots.
>>>
>>> Presumably some maintainers would consider uselessd an alternate 
>>> init system - and others will not. In that case the GR seems have 
>>> achieved effectively nothing.
>>
>> If there was a secret agenda e.g. to annoy systemd then you are right 
>> that such trick that you now thought up would mean that this GR was a 
>> waste of time.
>
> I just don't understand why you consider uselessd a "trick" that I 
> came up with (leaving alone the fact that David brought it up here, 
> and that yet another guy started the project).

For the record: I don't consider uselessd a trick¹.  On the contrary, I 
agree with Russ that it might be a quite interesting init system.

You are right that I confused you and David.  Sorry about that!

 - Jonas

¹ What I reflected on was how a question was phrased which included this 
project, not the project itself.

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Ian Jackson]

Nikolaus Rath writes ("Re: Alternative proposal: support for alternative init 
systems is desirable but not mandatory"):
> I just don't understand why you consider uselessd a "trick" that I came
> up with (leaving alone the fact that David brought it up here, and that
> yet another guy started the project).

When I read someone mention uselessd before, I thought it was a
hypothetical fork of systemd which was nearly identical to systemd.

I think uselessd, if it is successful, deals squarely with many of the
actual reasons why people don't like systemd: systemd's tendency to
try to be everything.  That is the real coupling threat - not the lack
of ability to continue to use init scripts.

So I think in practice there aren't going to be many packages that
would want to couple specifically to systemd _or_ uselessd, but where
support for other init systems is hard to provide.

Ian.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21573.16685.235428.467...@chiark.greenend.org.uk

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Russ Allbery]

Nikolaus Rath  writes:

> I just don't understand why you consider uselessd a "trick" that I came
> up with (leaving alone the fact that David brought it up here, and that
> yet another guy started the project).

Indeed, I think uselessd is a very interesting project.  I hope it
succeeds at its goals and offers another interesting alternative
implementation.  At the least, even if it doesn't succeed, it can provide
some practical experience with exactly what sort of coupling is and isn't
present or needed, grounded in running code rather than speculation.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjcq93xc@hope.eyrie.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Jonas Smedegaard]

Quoting Nikolaus Rath (2014-10-20 05:19:03)
> Jonas Smedegaard  writes:
>> Quoting Nikolaus Rath (2014-10-19 20:16:37)
>>> Do you consider uselessd to be the same init system as systemd? To 
>>> me this looks like a legitimate fork.
>>>
>>> Or are you saying that "at least one" is really meant to mean "at 
>>> least one not-systemd derived"?
>>
>> My concern is not systemd specifically - on the contrary I find it 
>> great if it brings more choice to Debian, which seems to be the 
>> status currently.
>>
>> My concern is also not the risk that Debian could be locked into 
>> "only two" or "only three" init systems - I believe we need not deal 
>> with that until the risk of such scenario eventually becomes 
>> realistic - if we then concider such scenario a concern.
>>
>> My concern now is to ensure that Debian supports more than a single 
>> init system.
>>
>> I sincerely hope that I made myself more clear this time, and that 
>> you found my response adequate and we can move on.
>
> Not really, I'm afraid (although you're of course free to move on). I 
> am still wondering, if Debian would support only uselessd and systemd, 
> would you consider that "more than one init system" or not? And if 
> not, why not?

I don't know:

I do know from our recent experience of bugs appearing and getting fixed 
too!) that "whoa, let's preserve more than one init system in Debian".

Maybe an experience with systemd + uselessd will not make me react 
"whoa, let's preserve more than two init systems in Debian", or maybe 
even "whoa, let's preserve at least one conservative init system in 
Debian" - I don't know.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Nikolaus Rath]

Jonas Smedegaard  writes:
> Quoting Nikolaus Rath (2014-10-19 20:16:37)
>> Jonas Smedegaard  writes:
>>> Quoting David Weinehall (2014-10-19 16:13:18)
 On Sun, Oct 19, 2014 at 02:28:02PM +0100, Ian Jackson wrote:
 [snip]

> The wording in my resolution comes from the TC discussion and 
> specifies `at least one' or `some alternative'.  To represent that 
> as `all' is IMO misleading.
>
> One important difference between `all' and `at least one' is this: 
> suppose there is some init system that does not support the common 
> interface you suppose in your point (2).  Saying `all' suggests 
> that it is somehow the fault of the packages which deal with the 
> common interface.  This point was raised in the TC discussion.
>
> Saying `all' gives the impression that every package must do work 
> for each init system.  That is why my proposal's wording simply 
> says that packages are forbidden from requiring `a specific' init 
> system.

 OK, so packaging uselessd (thus providing another init system that 
 provides -- most of -- the systemd interfaces) would solve all your 
 worries?
>>>
>>> There are many ways to twist words, yes. 
>>
>> I think this deserves a better answer.
>>
>> Do you consider uselessd to be the same init system as systemd? To me
>> this looks like a legitimate fork.
>>
>> Or are you saying that "at least one" is really meant to mean "at least
>> one not-systemd derived"?
>
> My concern is not systemd specifically - on the contrary I find it great 
> if it brings more choice to Debian, which seems to be the status 
> currently.
>
> My concern is also not the risk that Debian could be locked into "only 
> two" or "only three" init systems - I believe we need not deal with that 
> until the risk of such scenario eventually becomes realistic - if we 
> then concider such scenario a concern.
>
> My concern now is to ensure that Debian supports more than a single init 
> system.
>
> I sincerely hope that I made myself more clear this time, and that you 
> found my response adequate and we can move on.

Not really, I'm afraid (although you're of course free to move on). I am
still wondering, if Debian would support only uselessd and systemd,
would you consider that "more than one init system" or not? And if not,
why not?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87iojfctso@vostro.rath.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Nikolaus Rath]

Jonas Smedegaard  writes:
> Quoting Nikolaus Rath (2014-10-19 20:21:59)
>> Ian Jackson  writes:
>>> David Weinehall writes ("Re: Alternative proposal: support for alternative 
>>> init systems is desirable but not mandatory"):
>>>> OK, so packaging uselessd (thus providing another init system that 
>>>> provides -- most of -- the systemd interfaces) would solve all your 
>>>> worries?
>>>
>>> This resolution will be interpreted by humans, specifically 
>>> individual maintainers, the TC, and the release team - not by robots.
>>
>> Presumably some maintainers would consider uselessd an alternate init 
>> system - and others will not. In that case the GR seems have achieved 
>> effectively nothing.
>
> If there was a secret agenda e.g. to annoy systemd then you are right 
> that such trick that you now thought up would mean that this GR was a 
> waste of time.

I just don't understand why you consider uselessd a "trick" that I came
up with (leaving alone the fact that David brought it up here, and that
yet another guy started the project).


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fvejctbt@vostro.rath.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Jonathan Dowland]

On Sun, Oct 19, 2014 at 11:16:37AM -0700, Nikolaus Rath wrote:
> Do you consider uselessd to be the same init system as systemd? To me
> this looks like a legitimate fork.

Albeit one that isn't in the archive; there's an RFP bug[1] but noone
has taken ownership of it / created an ITP.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141019212140.ga20...@chew.redmars.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Jonas Smedegaard]

Quoting Nikolaus Rath (2014-10-19 20:21:59)
> Ian Jackson  writes:
>> David Weinehall writes ("Re: Alternative proposal: support for alternative 
>> init systems is desirable but not mandatory"):
>>> OK, so packaging uselessd (thus providing another init system that 
>>> provides -- most of -- the systemd interfaces) would solve all your 
>>> worries?
>>
>> This resolution will be interpreted by humans, specifically 
>> individual maintainers, the TC, and the release team - not by robots.
>
> Presumably some maintainers would consider uselessd an alternate init 
> system - and others will not. In that case the GR seems have achieved 
> effectively nothing.

If there was a secret agenda e.g. to annoy systemd then you are right 
that such trick that you now thought up would mean that this GR was a 
waste of time.

If, however, we are genuinely vote about Debian not being monolithic 
about init systems, then yet another init system is just great.

...or not so great if really not another init system but practically the 
same - but let's deal with that if it ever becomes relevant.

Whether we wants to ensure "more than one" is relevant to decide on now.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Jonas Smedegaard]

Quoting Nikolaus Rath (2014-10-19 20:16:37)
> Jonas Smedegaard  writes:
>> Quoting David Weinehall (2014-10-19 16:13:18)
>>> On Sun, Oct 19, 2014 at 02:28:02PM +0100, Ian Jackson wrote:
>>> [snip]
>>>
 The wording in my resolution comes from the TC discussion and 
 specifies `at least one' or `some alternative'.  To represent that 
 as `all' is IMO misleading.

 One important difference between `all' and `at least one' is this: 
 suppose there is some init system that does not support the common 
 interface you suppose in your point (2).  Saying `all' suggests 
 that it is somehow the fault of the packages which deal with the 
 common interface.  This point was raised in the TC discussion.

 Saying `all' gives the impression that every package must do work 
 for each init system.  That is why my proposal's wording simply 
 says that packages are forbidden from requiring `a specific' init 
 system.
>>>
>>> OK, so packaging uselessd (thus providing another init system that 
>>> provides -- most of -- the systemd interfaces) would solve all your 
>>> worries?
>>
>> There are many ways to twist words, yes. 
>
> I think this deserves a better answer.
>
> Do you consider uselessd to be the same init system as systemd? To me
> this looks like a legitimate fork.
>
> Or are you saying that "at least one" is really meant to mean "at least
> one not-systemd derived"?

My concern is not systemd specifically - on the contrary I find it great 
if it brings more choice to Debian, which seems to be the status 
currently.

My concern is also not the risk that Debian could be locked into "only 
two" or "only three" init systems - I believe we need not deal with that 
until the risk of such scenario eventually becomes realistic - if we 
then concider such scenario a concern.

My concern now is to ensure that Debian supports more than a single init 
system.

I sincerely hope that I made myself more clear this time, and that you 
found my response adequate and we can move on.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Matthias Urlichs]

Hi,

Ian Jackson:
> or it might be that all
> our daemon packages end up adopting some common startup framework
> whose implementation in the sysvinit package is buggy or defective, or
> something.
> 
Mmh. s/all/many/ s/adopting some common startup framework/using socket
activation/, which *surprise* is only implemented by systemd. (Disregarding
upstart's defective version of same for the moment.)

> I think naming any particular init in this GR is not a good idea.

So we should use convoluted wording instead, and leave it to every DD to
mentally substitute the convolutions with systemd / sys5rc as appropriate?

I don't know what that's supposed to achieve, but then I don't know what
your GR is supposed to achieve either, so I suppose that's all right. :-P

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Ian Jackson]

Aigars Mahinovs writes ("Re: Alternative proposal: support for alternative init 
systems is desirable but not mandatory"):
> I am inclined to agree with Lucas here - requirement of 'at least one'
> or 'some alternative' are quite imprecise, especially if multiple
> forks of one init system are present in the archive.

Firstly, I don't think it very likely that this is going to be a
problem in practice.

Secondly, this GR does not bind the policy editors, the release team,
or the technical committee.  It does not prevent them from adjusting
the wording of policy, or their interpretation of it, if it becomes
necessary to do so in the light of developments.  I have confidence
that all of these teams would give proper effect to the intent behind
any GR.

In combination these two factors mean that, if this GR passes, it is
not going to be defeated by such technicalities.  If it passes, it
will take effect through its clear demonstration of the views of the
project's governing members.


Looking at this question the from other end, dealing with this
interpretation problem by trying to clarify the wording to explain
what counts as a single init system, seems very unwise.  The GR
process is unsuited to that kind of detailed work.

I don't want to deal with this problem by specifically naming
sysvinit.  sysvinit itself might be forked, or it might be that all
our daemon packages end up adopting some common startup framework
whose implementation in the sysvinit package is buggy or defective, or
something.

I think naming any particular init in this GR is not a good idea.


Ian.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21572.4945.914183.446...@chiark.greenend.org.uk

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Nikolaus Rath]

Ian Jackson  writes:
> David Weinehall writes ("Re: Alternative proposal: support for alternative 
> init systems is desirable but not mandatory"):
>> OK, so packaging uselessd (thus providing another init system that
>> provides -- most of -- the systemd interfaces) would solve all your
>> worries?
>
> This resolution will be interpreted by humans, specifically individual
> maintainers, the TC, and the release team - not by robots.

Presumably some maintainers would consider uselessd an alternate init
system - and others will not. In that case the GR seems have achieved
effectively nothing.


Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lhobdins@vostro.rath.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Nikolaus Rath]

Jonas Smedegaard  writes:
> Quoting David Weinehall (2014-10-19 16:13:18)
>> On Sun, Oct 19, 2014 at 02:28:02PM +0100, Ian Jackson wrote:
>> [snip]
>>
>>> The wording in my resolution comes from the TC discussion and 
>>> specifies `at least one' or `some alternative'.  To represent that as 
>>> `all' is IMO misleading.
>>>
>>> One important difference between `all' and `at least one' is this: 
>>> suppose there is some init system that does not support the common 
>>> interface you suppose in your point (2).  Saying `all' suggests that 
>>> it is somehow the fault of the packages which deal with the common 
>>> interface.  This point was raised in the TC discussion.
>>>
>>> Saying `all' gives the impression that every package must do work for 
>>> each init system.  That is why my proposal's wording simply says that 
>>> packages are forbidden from requiring `a specific' init system.
>>
>> OK, so packaging uselessd (thus providing another init system that 
>> provides -- most of -- the systemd interfaces) would solve all your 
>> worries?
>
> There are many ways to twist words, yes. 

I think this deserves a better answer.

Do you consider uselessd to be the same init system as systemd? To me
this looks like a legitimate fork.

Or are you saying that "at least one" is really meant to mean "at least
one not-systemd derived"?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oat7diwq@vostro.rath.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Aigars Mahinovs]

On 19 October 2014 18:27, Lucas Nussbaum  wrote:
> On 19/10/14 at 14:28 +0100, Ian Jackson wrote:
>> > So I think that we are down to two solutions that really preserve the 
>> > 'freedom'
>> > to choose an init system:
>>
>> I mostly agree with your technical analysis.
>>
>> > 2) packages MUST work with a specific interface, which is basic enough to
>> > enable all alternative init systems to support it. The most natural such
>> > interface is currently sysvinit: if a package works with sysvinit as PID 
>> > 1, it
>> > currently also works with upstart, openrc, etc.
>>
>> The wording in my resolution comes from the TC discussion and
>> specifies `at least one' or `some alternative'.  To represent that as
>> `all' is IMO misleading.
>
> I don't follow you here.
>
> Your main goal is to preserve the ability to switch between init
> systems.
[snip]
> Requiring support for sysvinit sounds exactly like what you really want,
> since users could then switch to any sysvinit-compatible init system.
> Why not say so explicitely?

I am inclined to agree with Lucas here - requirement of 'at least one'
or 'some alternative' are quite imprecise, especially if multiple
forks of one init system are present in the archive. The requirement
to work with some minimal common API, such as the one provided by
sysvinit, would be more precise and will cause less discussions later
on. If the bug severity scaling is carried over from Ians original
proposal [1], then that would be the best option (to vote on) so far.

[1] Midified to: functionality degradation with sysvinit is a bug and
the severity of that bug must be identical to what the severity would
have been if such functionality degradation affected all users.

-- 
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
  #--#
 | .''`.Debian GNU/Linux (http://www.debian.org)|
 | : :' :   Latvian Open Source Assoc. (http://www.laka.lv) |
 | `. `'Linux Administration and Free Software Consulting   |
 |   `- (http://www.aiteki.com) |
 #--#


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CABpYwDWVWoNe1sJnEopNY37sp7zmYYey1R3E4UCpFP3bw2=9...@mail.gmail.com

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Lucas Nussbaum]

On 19/10/14 at 14:28 +0100, Ian Jackson wrote:
> > So I think that we are down to two solutions that really preserve the 
> > 'freedom'
> > to choose an init system:
> 
> I mostly agree with your technical analysis.
> 
> > 2) packages MUST work with a specific interface, which is basic enough to
> > enable all alternative init systems to support it. The most natural such
> > interface is currently sysvinit: if a package works with sysvinit as PID 1, 
> > it
> > currently also works with upstart, openrc, etc.
> 
> The wording in my resolution comes from the TC discussion and
> specifies `at least one' or `some alternative'.  To represent that as
> `all' is IMO misleading.
> 
> One important difference between `all' and `at least one' is this:
> suppose there is some init system that does not support the common
> interface you suppose in your point (2).  Saying `all' suggests that
> it is somehow the fault of the packages which deal with the common
> interface.  This point was raised in the TC discussion.
> 
> Saying `all' gives the impression that every package must do work for
> each init system.  That is why my proposal's wording simply says that
> packages are forbidden from requiring `a specific' init system.

I don't follow you here.

Your main goal is to preserve the ability to switch between init
systems.

Your proposal, even modified with "one specific init system", doesn't
fully preserve that ability: as pointed out by David Weinehall in
<20141019141318.gc8...@hirohito.acc.umu.se>, one could introduce another
init system that shares systemd's interfaces, thus enabling packages to
statisfy your condition (they would require systemd and one alternative:
that systemd-compatible init system) while breaking the ability to
switch to sysvinit or upstart.

Requiring support for sysvinit sounds exactly like what you really want,
since users could then switch to any sysvinit-compatible init system.
Why not say so explicitely?

Thanks,

Lucas


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Ian Jackson]

David Weinehall writes ("Re: Alternative proposal: support for alternative init 
systems is desirable but not mandatory"):
> OK, so packaging uselessd (thus providing another init system that
> provides -- most of -- the systemd interfaces) would solve all your
> worries?

This resolution will be interpreted by humans, specifically individual
maintainers, the TC, and the release team - not by robots.

Ian.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21571.52393.941097.319...@chiark.greenend.org.uk

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Jonas Smedegaard]

Quoting David Weinehall (2014-10-19 16:13:18)
> On Sun, Oct 19, 2014 at 02:28:02PM +0100, Ian Jackson wrote:
> [snip]
>
>> The wording in my resolution comes from the TC discussion and 
>> specifies `at least one' or `some alternative'.  To represent that as 
>> `all' is IMO misleading.
>>
>> One important difference between `all' and `at least one' is this: 
>> suppose there is some init system that does not support the common 
>> interface you suppose in your point (2).  Saying `all' suggests that 
>> it is somehow the fault of the packages which deal with the common 
>> interface.  This point was raised in the TC discussion.
>>
>> Saying `all' gives the impression that every package must do work for 
>> each init system.  That is why my proposal's wording simply says that 
>> packages are forbidden from requiring `a specific' init system.
>
> OK, so packaging uselessd (thus providing another init system that 
> provides -- most of -- the systemd interfaces) would solve all your 
> worries?

There are many ways to twist words, yes.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[David Weinehall]

On Sun, Oct 19, 2014 at 02:28:02PM +0100, Ian Jackson wrote:
[snip]

> The wording in my resolution comes from the TC discussion and
> specifies `at least one' or `some alternative'.  To represent that as
> `all' is IMO misleading.
> 
> One important difference between `all' and `at least one' is this:
> suppose there is some init system that does not support the common
> interface you suppose in your point (2).  Saying `all' suggests that
> it is somehow the fault of the packages which deal with the common
> interface.  This point was raised in the TC discussion.
> 
> Saying `all' gives the impression that every package must do work for
> each init system.  That is why my proposal's wording simply says that
> packages are forbidden from requiring `a specific' init system.

OK, so packaging uselessd (thus providing another init system that
provides -- most of -- the systemd interfaces) would solve all your
worries?

[snip]


Regards: David Weinehall
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141019141318.gc8...@hirohito.acc.umu.se

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Ian Jackson]

Wouter Verhelst writes ("Re: Alternative proposal: support for alternative init 
systems is desirable but not mandatory"):
> I would like to see the above clause modified like this:
> 
> "There may be some loss of functionality under sysvinit if the package
> is still basically functional."

The question of tolerable degradation is IMO dealt with much better in
my proposed text.  This aspect was discussed in the TC discussion,
which is how the wording there came to be.

Ian.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21571.48373.106848.942...@chiark.greenend.org.uk

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Ian Jackson]

Thijs Kinkhorst writes ("Re: Alternative proposal: support for alternative init 
systems is desirable but not mandatory"):
> Does the constituion has a concept of hats? You're either the DPL or
> you're not. It seems Lucas is the DPL. If Lucas proposes an amendment, the
> DPL has proposed an amendment, right?

Yes, I think so.

Ian.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21571.48247.910565.242...@chiark.greenend.org.uk

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Ian Jackson]

Lucas Nussbaum writes ("Re: Alternative proposal: support for alternative init 
systems is desirable but not mandatory"):
> I don't think that it's useful to change this rule to:
>   packages MUST work with at least one alternative init system as PID 1
> or
>   packages MUST work with some alternative init systems as PID 1

Your Q&A is helpful but I don't think it belongs in the GR text.
I agree with Jonas's objection on this specific question, even after
reading your mail here.

> So I think that we are down to two solutions that really preserve the 
> 'freedom'
> to choose an init system:

I mostly agree with your technical analysis.

> 2) packages MUST work with a specific interface, which is basic enough to
> enable all alternative init systems to support it. The most natural such
> interface is currently sysvinit: if a package works with sysvinit as PID 1, it
> currently also works with upstart, openrc, etc.

The wording in my resolution comes from the TC discussion and
specifies `at least one' or `some alternative'.  To represent that as
`all' is IMO misleading.

One important difference between `all' and `at least one' is this:
suppose there is some init system that does not support the common
interface you suppose in your point (2).  Saying `all' suggests that
it is somehow the fault of the packages which deal with the common
interface.  This point was raised in the TC discussion.

Saying `all' gives the impression that every package must do work for
each init system.  That is why my proposal's wording simply says that
packages are forbidden from requiring `a specific' init system.

> Ian, do you agree that this correctly captures your opinion and the set of
> available options?

There are various ways of systematising the questions in this area.
Your analysis is, I think, helpful, but I don't want to privilege it.

The text in my proposal is taken directly from the TC discussion where
its details were extensively debated.

> What do you think of withdrawing both your and my proposal, and
> designing a ballot based on the above set of options (re-adding all
> the small details that I left out for clarity, e.g. what amount of
> degraded operation is acceptable, what are the exceptions, etc)?

So I'm afraid I don't want to do that.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21571.48226.818607.308...@chiark.greenend.org.uk

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Thijs Kinkhorst]

On Fri, October 17, 2014 19:42, Kurt Roeckx wrote:
> On Fri, Oct 17, 2014 at 01:44:06PM +0100, Neil McGovern wrote:
>> On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
>> > I am therefore bringing forward an alternative proposal
>>
>> Recieved, and verified. Note, this has been proposed by the current
>> Project Leader, and thus does not require seconds, but will record those
>> seconding anyway.
>
> I don't see him doing it with his DPL hat on, so Lucas can you
> clarify that you do this as DPL or not?  (But there seem to be
> enough seconds, so it doesn't seem to matter.)

Does the constituion has a concept of hats? You're either the DPL or
you're not. It seems Lucas is the DPL. If Lucas proposes an amendment, the
DPL has proposed an amendment, right?


Thijs


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/d08288dcef825ddc6f2d2b5c88850600.squir...@aphrodite.kinkhorst.nl

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Lucas Nussbaum]

On 18/10/14 at 04:14 +0200, Jonas Smedegaard wrote:
> Thanks a lot for your analysis, Lucas.  I find it _very_ helpful!
> 
> Quoting Lucas Nussbaum (2014-10-17 22:23:14)
> > Q2: support for alternative init systems as PID 1
> > =
> > A2.1: packages MUST work with all alternative init systems as PID 1.
> >   (that's Ian's proposal)
> 
> I disagree with your interpretation that _all_ alternative init systems 
> are mandatory to support.  Remove the "all" in the sentence, and it fits 
> my interpretation of the proposal.
> 
> @Ian: Probably wise to rephrase to avoid ambiguity here!

[ Disclaimer: I put forward another proposal, but I don't care which one wins
in the end provided it is what is best for Debian; I also disagree with the use
of 'freedom' to characterize the technical ability to switch between init
systems, but for clarity, I'm using 'freedom' in this email ]

Given the motivations for the original proposal:
> This GR seeks to preserve the freedom of our users now to select an
> init system of their choice, and the project's freedom to select a
> different init system in the future. It will avoid Debian becoming
> accidentally locked in to a particular init system (for example,
> because so much unrelated software has ended up depending on a
> particular init system that the burden of effort required to change
> init system becomes too great). A number of init systems exist, and
> it is clear that there is not yet broad consensus as to what the
> best init system might look like.

I don't think that it's useful to change this rule to:
  packages MUST work with at least one alternative init system as PID 1
or
  packages MUST work with some alternative init systems as PID 1

We could end up with different packages choosing different alternative init
systems, or with a systemd-fork-with-the-same-interfaces-and-formats init
system that makes it possible to satisfy the rule, while still effectively
removing the 'freedom' to choose an init system that isn't looking like
systemd.

So I think that we are down to two solutions that really preserve the 'freedom'
to choose an init system:
1) packages MUST work with all alternative init systems as PID 1.
That's difficult. It means that if someone introduces a new init system with
incompatible interfaces, it requires all maintainers to adjust their packages.
So that rule would only make sense with many additional restrictions.

2) packages MUST work with a specific interface, which is basic enough to
enable all alternative init systems to support it. The most natural such
interface is currently sysvinit: if a package works with sysvinit as PID 1, it
currently also works with upstart, openrc, etc.


If we agree with the mostly uncontroversial answers:
- packages MUST work with the default init system on Linux (Q1)
- maintainers should be encouraged to accept patches that add or improve
  support for alternative init systems (Q4), especially when that alternative
  init system is the default on a non-Linux port (Q5)


Then I think that the central question in this GR could be reduced to the
following options:

a) we say nothing about alternative init systems. wheezy->jessie upgrades
   might require switching to systemd, rebooting, and then upgrading other
   packages to keep a functional system

b.1) sysvinit must be supported in jessie by packages that were in wheezy
   (that is what is closest to my original proposal)

b.2) sysvinit must be supported in jessie by all packages; we don't say
   anything for jessie+1
   (that is the minimum proposal that preserves freedom to choose init
   system in jessie)

b.3) sysvinit must be supported by all packages (in jessie, but also in the 
future)
   (that is the minimum proposal that preserves freedom to choose init system
on the longer term, which I understand is Ian's motivation for having that 
vote
now, according to <21569.19669.726247.130...@chiark.greenend.org.uk>)

c.1) all init systems must be supported by all packages in jessie (nothing said
 about jessie+1)

c.2) all init systems must be supported by all packages (in jessie, but also
 in the future)


I believe that if we voted with those options, it would give us a good idea of
how much we value the 'freedom' to choose an alternative init system, compared 
to the
additional work required for supporting them.

Options (a), (b.1), (b.2), (c.1) would not incur any additional work,
given that they are limited to jessie, and the current state of jessie
is fine AFAIK.

An additional option, addressing answer A1.2 to Q1, could be required:
  @) support for the default init system is not mandatory
But I suspect that it is so controversial that it's not worth putting on
the ballot.


Ian, do you agree that this correctly captures your opinion and the set of
available options?

What do you think of withdrawing both your and my proposal, and designing a
ballot based on the above set of options (re-ad

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Jonas Smedegaard]

Thanks a lot for your analysis, Lucas.  I find it _very_ helpful!

Quoting Lucas Nussbaum (2014-10-17 22:23:14)
> Q2: support for alternative init systems as PID 1
> =
> A2.1: packages MUST work with all alternative init systems as PID 1.
>   (that's Ian's proposal)

I disagree with your interpretation that _all_ alternative init systems 
are mandatory to support.  Remove the "all" in the sentence, and it fits 
my interpretation of the proposal.

@Ian: Probably wise to rephrase to avoid ambiguity here!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Lisandro Damián Nicanor Pérez Meyer]

On Friday 17 October 2014 23:03:37 Wouter Verhelst wrote:
[snip] 
> I would like to see the above clause modified like this:
> 
> "There may be some loss of functionality under sysvinit if the package
> is still basically functional."
> 
> Rationale: I don't think that "the maintainer believes the loss of
> functionality is acceptable" is a good test for whether the cost is
> worth the benefit. Rather, that test should be about "how hard is it for
> a maintainer to support the alternative init system". If a maintainer
> thinks that, say, a power manager written to read /sys/power directly
> but control things through systemd is useless without the ability to
> suspend the system, they might well remove all support for non-systemd
> systems; if someone else believes otherwise and sends in a patch, under
> the proposed language the maintainer would be able to reject such
> patches.
> 
> As such, in the spirit of §2.1.1 of the consitution, I would therefore
> like to see something along the lines of "in the absense of patches,
> it's okay for a maintainer to remove support for non-default init
> systems if they have no desire to maintain that support themselves, but
> maintainers should not reject patches implementing such support without
> a sound technical reason".

I do partly agree with you in here. The part that I do not agree with is: 
supposing Mike the maintainer receives a patch from Peter the patcher to 
support $foo then Mike would be forced to ship the patch most possibly as a 
delta from upstream.

Now a new version of the software arrives and the patch does not applies 
anymore, needing a big refactoring. Peter doesn't shows up and Mike is forced 
to either drop the support (would that become RC bugs?) or do the refactoring 
himself. All I can see is problems for Mike, added to what he already has.

We could also add broken API/ABIs if the package in question is a lib, big 
deltas from upstream, etc.

I think we should still leave that to the maintainer unless overridden by the 
TC.

-- 
I am two fools, I know, for loving, and for saying so.
  John Donne

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Wouter Verhelst]

On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> Hi,
> 
> It is now clear that we will have a vote on this issue. I think that we
> should use this opportunity to clarify the Project's position, and that's
> not something that would be achieved if "Further Discussion" were to
> win.
> 
> I am therefore bringing forward an alternative proposal, deeply inspired
> from the "Advice: sysvinit compatibility in jessie and multiple init
> support" option of the TC resolution on init system coupling[1], which
> was originally written by Russ Allbery[2] and was then amended by many
> participants to the discussion in February 2014.
> 
> [1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html
> [2] https://lists.debian.org/debian-ctte/2014/02/msg00447.html
> 
> - begin proposal ->8
> Debian has decided (via the technical committee) to change its default
> init system for the next release. The technical committee decided not to
> decide about the question of "coupling" i.e. whether other packages in
> Debian may depend on a particular init system.  However, the technical
> committee stated in #746715 that "[it] expects maintainers to continue to
> support the multiple available init systems in Debian.  That includes
> merging reasonable contributions, and not reverting existing support
> without a compelling reason."
> 
> The Debian Project states that:
> 
>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

I would like to see the above clause modified like this:

"There may be some loss of functionality under sysvinit if the package
is still basically functional."

Rationale: I don't think that "the maintainer believes the loss of
functionality is acceptable" is a good test for whether the cost is
worth the benefit. Rather, that test should be about "how hard is it for
a maintainer to support the alternative init system". If a maintainer
thinks that, say, a power manager written to read /sys/power directly
but control things through systemd is useless without the ability to
suspend the system, they might well remove all support for non-systemd
systems; if someone else believes otherwise and sends in a patch, under
the proposed language the maintainer would be able to reject such
patches.

As such, in the spirit of §2.1.1 of the consitution, I would therefore
like to see something along the lines of "in the absense of patches,
it's okay for a maintainer to remove support for non-default init
systems if they have no desire to maintain that support themselves, but
maintainers should not reject patches implementing such support without
a sound technical reason".

This will allow Debian to support non-default init systems if someone
steps forward and does the work, but should not stand in the way of
people who just don't care and don't want to see their work doubled (or
tripled, or quadrupled, or ...) by alternative init systems.

>requirement to support smooth upgrades from wheezy to jessie still
>applies, even when the system is booted with sysvinit.
> 
> The Debian Project makes no statement at this time on sysvinit support
> beyond the jessie release.
> 
> 
> This resolution is a Position Statement about Issues of the Day
> (Constitution 4.1.5), triggering the General Resolution override clause
> in the TC's resolution of the 11th of February.
> 
> The TC's decision on the default init system for Linux in jessie stands

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Lucas Nussbaum]

Hi,

On 17/10/14 at 13:02 +0200, Lucas Nussbaum wrote:
> Actually, I wonder if both proposals shouldn't be rewritten using RFC 2119 to
> make them clearer.

I did not really do that, but instead rewrote both proposals as a set of
Q&A that make it easier to understand the differences and the possible
additional alternatives.

I think that there are 5 different questions, but only Q2 seems to be
really controversial.

For reference, Ian's proposal refers to:
https://lists.debian.org/21567.57029.724173.958...@chiark.greenend.org.uk
Mine refers to:
https://lists.debian.org/20141017074416.ga2...@xanadu.blop.info


Q1: support for the default init system on Linux

A1.1: packages MUST work with the default init system on Linux as PID 1.
  (this is the case in both Ian's and my proposal)

A1.2: not proposed yet: no mandatory support for the default init system?
  choice on a per-package/per-maintainer basis?
  (Luca Falavigna's proposal would fit here, I think)


Q2: support for alternative init systems as PID 1
=
A2.1: packages MUST work with all alternative init systems as PID 1.
  (that's Ian's proposal)
  To the user, that brings the freedom to choose any init system,
  with the guarantee that it won't break some packages.
  But it requires the maintainer to support all init systems,
  possibly without upstream cooperation.
  Lack of support is a policy violation (severity >= serious, RC).
  Bugs about degraded operation on some init systems follow the
  normal bug severity rules.

A2.2: packages SHOULD work with alternative init systems as PID 1.
  (that's my proposal)
  This is a recommendation. Lack of support is not a policy
  violation (bug severity < serious, not RC).

A2.3: not proposed yet: say nothing about alternative inits?
  (lack of support would be a wishlist bug?)


Q3: special rule for sysvinit to ease wheezy->jessie upgrades
=
(only relevant for A2.2)
A3.1: continue support for sysvinit (that's my proposal)
  For the jessie release, all software available in Debian 'wheezy'
  that supports being run under sysvinit should continue to support
  sysvinit unless there is no technically feasible way to do so.

A3.2: not proposed yet: require two-step upgrades, i.e. first reboot
  with systemd, then upgrade other packages?


Q4: non-binding recommendation to maintainers
=
A4.1: recommend that maintainers accept patches that add or improve
  support for alternative init systems. (both Ian's and my proposal
  have something like this, with a different wording)

A4.2: not proposed yet: say nothing


Q5: support for init systems with are the default on non-Linux ports

(only relevant for A2.2)
A5.1: non-binding recommendation to add/improve support with a
  high priority (in my proposal)

A5.2: not proposed yet: say nothing


Hoping this helps someone besides me :-)

Lucas


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Lucas Nussbaum]

On 17/10/14 at 19:42 +0200, Kurt Roeckx wrote:
> On Fri, Oct 17, 2014 at 01:44:06PM +0100, Neil McGovern wrote:
> > On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> > > I am therefore bringing forward an alternative proposal
> > 
> > Recieved, and verified. Note, this has been proposed by the current
> > Project Leader, and thus does not require seconds, but will record those
> > seconding anyway.
> 
> I don't see him doing it with his DPL hat on, so Lucas can you
> clarify that you do this as DPL or not?  (But there seem to be
> enough seconds, so it doesn't seem to matter.)

I don't mind either way.
Let's say that I did not do this as DPL.
 
Lucas


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Ian Jackson]

Ansgar Burchardt writes ("Re: Alternative proposal: support for alternative 
init systems is desirable but not mandatory"):
> However it implicitly allowed changing the details later without a GR by
> just setting "inital policy".
> 
> Maybe something similar could be done here?

I think that if the TC wanted to, it could update or change the
policy set by this GR.  After all the GR works by exercising the TC's
powers pursuant to the February TC resolution.  And the TC can amend
its own decisions.

Ian.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21569.26822.818511.602...@chiark.greenend.org.uk

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Ansgar Burchardt]

Hi,

Joey Hess  writes:
> Lucas Nussbaum wrote:
>> I am therefore bringing forward an alternative proposal, deeply inspired
>> from the "Advice: sysvinit compatibility in jessie and multiple init
>> support" option of the TC resolution on init system coupling[1], which
>> was originally written by Russ Allbery[2] and was then amended by many
>> participants to the discussion in February 2014.
>
> I am very uncomfortable with GRs being used to set technical policy. 
> We have never before has a GR that did so. It can lock us into technical
> decisions which we then need a whole other GR process to get us out of.
> And mass voting on technical minutia is no way to run a distribution.

The GR about DMs[1] did set technical policy in so far as it prescribed
technical details of the initial implementation, including for example
the "DM-Upload-Allowed: yes" field.

However it implicitly allowed changing the details later without a GR by
just setting "inital policy".

Maybe something similar could be done here?

Ansgar

  [1] 


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a94uedqk@deep-thought.43-1.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Joey Hess]

Lucas Nussbaum wrote:
> It is now clear that we will have a vote on this issue. I think that we
> should use this opportunity to clarify the Project's position, and that's
> not something that would be achieved if "Further Discussion" were to
> win.
> 
> I am therefore bringing forward an alternative proposal, deeply inspired
> from the "Advice: sysvinit compatibility in jessie and multiple init
> support" option of the TC resolution on init system coupling[1], which
> was originally written by Russ Allbery[2] and was then amended by many
> participants to the discussion in February 2014.

I am very uncomfortable with GRs being used to set technical policy. 
We have never before has a GR that did so. It can lock us into technical
decisions which we then need a whole other GR process to get us out of.
And mass voting on technical minutia is no way to run a distribution.

Why not just make your proposal be something along the lines of
reaffirming the technical decision-making process as it currently
stands, from the package maintainers, to the policy, to the TC.
It could implicitly or explicitly reaffirm both recent TC decisions on
init systems.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Kurt Roeckx]

On Fri, Oct 17, 2014 at 01:44:06PM +0100, Neil McGovern wrote:
> On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> > I am therefore bringing forward an alternative proposal
> 
> Recieved, and verified. Note, this has been proposed by the current
> Project Leader, and thus does not require seconds, but will record those
> seconding anyway.

I don't see him doing it with his DPL hat on, so Lucas can you
clarify that you do this as DPL or not?  (But there seem to be
enough seconds, so it doesn't seem to matter.)


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017174252.gb10...@roeckx.be

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Daniel Kahn Gillmor]

On 10/17/2014 03:44 AM, Lucas Nussbaum wrote:
> Hi,
> 
> It is now clear that we will have a vote on this issue. I think that we
> should use this opportunity to clarify the Project's position, and that's
> not something that would be achieved if "Further Discussion" were to
> win.
> 
> I am therefore bringing forward an alternative proposal, deeply inspired
> from the "Advice: sysvinit compatibility in jessie and multiple init
> support" option of the TC resolution on init system coupling[1], which
> was originally written by Russ Allbery[2] and was then amended by many
> participants to the discussion in February 2014.
> 
> [1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html
> [2] https://lists.debian.org/debian-ctte/2014/02/msg00447.html
> 
> - begin proposal ->8
> Debian has decided (via the technical committee) to change its default
> init system for the next release. The technical committee decided not to
> decide about the question of "coupling" i.e. whether other packages in
> Debian may depend on a particular init system.  However, the technical
> committee stated in #746715 that "[it] expects maintainers to continue to
> support the multiple available init systems in Debian.  That includes
> merging reasonable contributions, and not reverting existing support
> without a compelling reason."
> 
> The Debian Project states that:
> 
>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 Debian Project makes no statement at this time on sysvinit support
> beyond the jessie release.
> 
> 
> This resolution is a Position Statement about Issues of the Day
> (Constitution 4.1.5), triggering the General Resolution override clause
> in the TC's resolution of the 11th of February.
> 
> The TC's decision on the default init system for Linux in jessie stands
> undisturbed.
> 
> However, the TC resolution is altered to add the additional text above.
> -- end proposal -->8

My understanding is that Lucas clarified "currently" to mean "in wheezy".

I second this proposal.

Thanks for writing it up, Lucas.

--dkg




signature.asc
Description: OpenPGP digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Lucas Nussbaum]

On 17/10/14 at 16:12 +0200, Matthias Urlichs wrote:
> Hi,
> 
> Lucas Nussbaum:
> > For example, Ian's "software may not require a specific init system to be 
> > pid
> > 1" could be abused by introducing a systemd-clone package in the archive
> 
> Please try to ignore maleficial intent and similar failure modes.
> 
> If we'd go that way, not only would we need to define (and capitalize)
> every second word, but the GR proposals would be a lot longer – and
> correspondingly harder to understand / apply correctly.

Oh, yes, sure. I'm just pointing out that the current proposals are
quite long and complex (and yes, I'm guilty for that as well), and that
it might be quite hard to understand what they mean in practice.

When proposals will have stabilized, it could be useful to write an
unofficial FAQ to explain what each option really means in practice.

Lucas


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017151516.ga27...@xanadu.blop.info

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Matthias Urlichs]

Hi,

Lucas Nussbaum:
> For example, Ian's "software may not require a specific init system to be pid
> 1" could be abused by introducing a systemd-clone package in the archive

Please try to ignore maleficial intent and similar failure modes.

If we'd go that way, not only would we need to define (and capitalize)
every second word, but the GR proposals would be a lot longer – and
correspondingly harder to understand / apply correctly.

-- 
-- Matthias Urlichs


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017141256.ga12...@smurf.noris.de

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Neil McGovern]

On Fri, Oct 17, 2014 at 03:25:03PM +0200, Lucas Nussbaum wrote:
> On 17/10/14 at 13:59 +0100, Neil McGovern wrote:
> > On Fri, Oct 17, 2014 at 01:05:31PM +0200, Lucas Nussbaum wrote:
> > > On 17/10/14 at 11:38 +0200, Michael Banck wrote:
> > > > On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> > > > >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.
> > > > 
> > > > I believe "currently" needs to be clarified - are you talking about the
> > > > current state of jessie, of wheezy, or something else?
> > > 
> > > I tried to keep changes from the original text (as voted on by the TC)
> > > to the bare minimum.
> > > But, since the intend here is to allow swift upgrades between stable
> > > releases, it should read:
> > > 
> > >   For the jessie release, all software available in Debian 'wheezy' that
> > >   supports being run under sysvinit should continue to support sysvinit
> > >   unless there is no technically feasible way to do so.
> > > 
> > 
> > Hi Lucas,
> > 
> > For clarity, are you formally amending your own text here?
> 
> Yes.
> 
> I am expecting other fine-tunings during the next hours/days, so I
> initially wanted to gather those changes in a single amended version.
> But now that you asked the question, yes, please amend the proposal with
> the above change.
> 

Thanks, updated. I want to get the web pages etc updated asap, and post
to DDA. I look forward to any more changes :)

Neil
-- 


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Dimitri John Ledkov]

On 17 October 2014 13:44, Neil McGovern  wrote:
> On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
>> I am therefore bringing forward an alternative proposal
>
> Recieved, and verified. Note, this has been proposed by the current
> Project Leader, and thus does not require seconds, but will record those
> seconding anyway.

Phf, did not know that =) probably something that ought to be fixed as well as
the TC super-majority bug. And thus to pre-empt pointless votes of no
confidence,
if DPL can't even get enough seconds (which I'm sure will not be the
case with this
proposal)

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/canbhluibnqcczommvn_pawu-h81os4yfasa_gngz7vnndny...@mail.gmail.com

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Lucas Nussbaum]

On 17/10/14 at 13:59 +0100, Neil McGovern wrote:
> On Fri, Oct 17, 2014 at 01:05:31PM +0200, Lucas Nussbaum wrote:
> > On 17/10/14 at 11:38 +0200, Michael Banck wrote:
> > > On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> > > >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.
> > > 
> > > I believe "currently" needs to be clarified - are you talking about the
> > > current state of jessie, of wheezy, or something else?
> > 
> > I tried to keep changes from the original text (as voted on by the TC)
> > to the bare minimum.
> > But, since the intend here is to allow swift upgrades between stable
> > releases, it should read:
> > 
> >   For the jessie release, all software available in Debian 'wheezy' that
> >   supports being run under sysvinit should continue to support sysvinit
> >   unless there is no technically feasible way to do so.
> > 
> 
> Hi Lucas,
> 
> For clarity, are you formally amending your own text here?

Yes.

I am expecting other fine-tunings during the next hours/days, so I
initially wanted to gather those changes in a single amended version.
But now that you asked the question, yes, please amend the proposal with
the above change.

Thanks,

Lucas


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Neil McGovern]

On Fri, Oct 17, 2014 at 01:05:31PM +0200, Lucas Nussbaum wrote:
> On 17/10/14 at 11:38 +0200, Michael Banck wrote:
> > On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> > >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.
> > 
> > I believe "currently" needs to be clarified - are you talking about the
> > current state of jessie, of wheezy, or something else?
> 
> I tried to keep changes from the original text (as voted on by the TC)
> to the bare minimum.
> But, since the intend here is to allow swift upgrades between stable
> releases, it should read:
> 
>   For the jessie release, all software available in Debian 'wheezy' that
>   supports being run under sysvinit should continue to support sysvinit
>   unless there is no technically feasible way to do so.
> 

Hi Lucas,

For clarity, are you formally amending your own text here?

Neil
-- 


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Neil McGovern]

On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> I am therefore bringing forward an alternative proposal

Recieved, and verified. Note, this has been proposed by the current
Project Leader, and thus does not require seconds, but will record those
seconding anyway.

Neil
-- 


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Lucas Nussbaum]

On 17/10/14 at 12:00 +0100, Iain Lane wrote:
> Hi,
> 
> On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> > […]
> >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.
> 
> The first sentence seems strong to me. There's (almost) always going to
> be a technically feasible way to achieve this, given a large enough
> changeset. "Reasonable changes" is right. I suggest replacing the quoted
> section with something like
> 
>   For the jessie release, maintainers should not remove support for
>   running under sysvinit from software which already possesses this
>   support, unless it would be unreasonably difficult to preserve in the
>   face of other changes the maintainer reasonably desires for jessie.
>   Reasonable contributions to re-add or improve sysvinit support should
>   be accepted through the jessie release.

I would agree in principle.

However, we are freezing in two weeks, and the current status is that
(AFAIK) all software that supported sysvinit in wheezy continues to
support sysvinit in jessie (thanks to systemd-shim).

So this is a strong requirement, but one that is already met in practice
in the archive, and the current status is unlikely to change by the time
we release. So I don't really see a point in lightening that
requirement.

Lucas


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Iain Lane]

On Fri, Oct 17, 2014 at 12:00:03PM +0100, Iain Lane wrote:
> Also, what does "currently" ("already" in my text) mean? In stable or
> testing?

Okay, I see <20141017110531.ga11...@xanadu.blop.info> now.

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Iain Lane]

Hi,

On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> […]
>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.

The first sentence seems strong to me. There's (almost) always going to
be a technically feasible way to achieve this, given a large enough
changeset. "Reasonable changes" is right. I suggest replacing the quoted
section with something like

  For the jessie release, maintainers should not remove support for
  running under sysvinit from software which already possesses this
  support, unless it would be unreasonably difficult to preserve in the
  face of other changes the maintainer reasonably desires for jessie.
  Reasonable contributions to re-add or improve sysvinit support should
  be accepted through the jessie release.

Also, what does "currently" ("already" in my text) mean? In stable or
testing?

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Lucas Nussbaum]

On 17/10/14 at 11:38 +0200, Michael Banck wrote:
> On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> >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.
> 
> I believe "currently" needs to be clarified - are you talking about the
> current state of jessie, of wheezy, or something else?

I tried to keep changes from the original text (as voted on by the TC)
to the bare minimum.
But, since the intend here is to allow swift upgrades between stable
releases, it should read:

  For the jessie release, all software available in Debian 'wheezy' that
  supports being run under sysvinit should continue to support sysvinit
  unless there is no technically feasible way to do so.

Lucas


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017110531.ga11...@xanadu.blop.info

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Lucas Nussbaum]

On 17/10/14 at 09:44 +0200, Lucas Nussbaum wrote:
> I am therefore bringing forward an alternative proposal, deeply inspired
> from the "Advice: sysvinit compatibility in jessie and multiple init
> support" option of the TC resolution on init system coupling[1], which
> was originally written by Russ Allbery[2] and was then amended by many
> participants to the discussion in February 2014.

It was pointed out that a TL;DR version might be useful. Here is an attempt,
using RFC 2119 MUST/SHOULD/MAY/etc (note that the meaning of SHOULD in RFC 2119
is stronger than a simple advice). I've also simplified the statements, which
of course hides some details and adds some possible loopholes.

"Ian's":

Packages MUST NOT require a specific init system to be PID 1.
(exceptions: alternative init systems; special-use packages such as
managers for init systems; cooperating groups of packages intended for
use with specific init systems -- but only if not required by other
software whose main purpose is not the operation of a specific init
system)
But packages MAY provide degraded operation with some init systems.
(normal rules about bugs severity apply, no worse)

Maintainers SHOULD accept technically sound patches to improve
interoperation with various init systems.

"my's":
===
Packages SHOULD support the default init system on all architectures for
which they are built. [there are examples of circumstances where this can
be ignored in the proposal]
For jessie, all software currently supporting sysvinit MUST continue
to support sysvinit (exception: there is no technically feasible way to do
so). Degraded operation is acceptable as long as the package is basically
functional.

Maintainers SHOULD merge any contributions for support of any init system.
Maintainers SHOULD merge, with high priority, changes to support any init
system which is the default on one of Debian's non-Linux ports.
Maintainers MAY add that support themselves.


Actually, I wonder if both proposals shouldn't be rewritten using RFC 2119 to
make them clearer.

For example, Ian's "software may not require a specific init system to be pid
1" could be abused by introducing a systemd-clone package in the archive, so
that packages require "systemd or one of its clones", which isn't really "a
specific init system". What this proposal means is not very clear if it's not
"software MUST work with all init systems in Debian".

Lucas


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Matthias Urlichs]

Seconded.

> - begin proposal ->8
> Debian has decided (via the technical committee) to change its default
> init system for the next release. The technical committee decided not to
> decide about the question of "coupling" i.e. whether other packages in
> Debian may depend on a particular init system.  However, the technical
> committee stated in #746715 that "[it] expects maintainers to continue to
> support the multiple available init systems in Debian.  That includes
> merging reasonable contributions, and not reverting existing support
> without a compelling reason."
> 
> The Debian Project states that:
> 
>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 Debian Project makes no statement at this time on sysvinit support
> beyond the jessie release.
> 
> 
> This resolution is a Position Statement about Issues of the Day
> (Constitution 4.1.5), triggering the General Resolution override clause
> in the TC's resolution of the 11th of February.
> 
> The TC's decision on the default init system for Linux in jessie stands
> undisturbed.
> 
> However, the TC resolution is altered to add the additional text above.
> -- end proposal -->8

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Michael Banck]

On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
>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.

I believe "currently" needs to be clarified - are you talking about the
current state of jessie, of wheezy, or something else?


Michael


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141017093813.ga13...@raptor.chemicalconnection.dyndns.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Marco d'Itri]

Seconded.

On Oct 17, Lucas Nussbaum  wrote:

>It is now clear that we will have a vote on this issue. I think that we
>should use this opportunity to clarify the Project's position, and that's
>not something that would be achieved if "Further Discussion" were to
>win.
>
>I am therefore bringing forward an alternative proposal, deeply inspired
>from the "Advice: sysvinit compatibility in jessie and multiple init
>support" option of the TC resolution on init system coupling[1], which
>was originally written by Russ Allbery[2] and was then amended by many
>participants to the discussion in February 2014.
>
>[1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html
>[2] https://lists.debian.org/debian-ctte/2014/02/msg00447.html
>
>- begin proposal ->8
>Debian has decided (via the technical committee) to change its default
>init system for the next release. The technical committee decided not to
>decide about the question of "coupling" i.e. whether other packages in
>Debian may depend on a particular init system.  However, the technical
>committee stated in #746715 that "[it] expects maintainers to continue to
>support the multiple available init systems in Debian.  That includes
>merging reasonable contributions, and not reverting existing support
>without a compelling reason."
>
>The Debian Project states that:
>
>   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 Debian Project makes no statement at this time on sysvinit support
>beyond the jessie release.
>
>
>This resolution is a Position Statement about Issues of the Day
>(Constitution 4.1.5), triggering the General Resolution override clause
>in the TC's resolution of the 11th of February.
>
>The TC's decision on the default init system for Linux in jessie stands
>undisturbed.
>
>However, the TC resolution is altered to add the additional text above.
>-- end proposal -->8
>
>Lucas

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Vincent Cheng]

Hi,

On 17/10/14 12:44 AM, Lucas Nussbaum wrote:
> Hi,
> 
> It is now clear that we will have a vote on this issue. I think that we
> should use this opportunity to clarify the Project's position, and that's
> not something that would be achieved if "Further Discussion" were to
> win.
> 
> I am therefore bringing forward an alternative proposal, deeply inspired
> from the "Advice: sysvinit compatibility in jessie and multiple init
> support" option of the TC resolution on init system coupling[1], which
> was originally written by Russ Allbery[2] and was then amended by many
> participants to the discussion in February 2014.
> 
> [1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html
> [2] https://lists.debian.org/debian-ctte/2014/02/msg00447.html
> 
> - begin proposal ->8
> Debian has decided (via the technical committee) to change its default
> init system for the next release. The technical committee decided not to
> decide about the question of "coupling" i.e. whether other packages in
> Debian may depend on a particular init system.  However, the technical
> committee stated in #746715 that "[it] expects maintainers to continue to
> support the multiple available init systems in Debian.  That includes
> merging reasonable contributions, and not reverting existing support
> without a compelling reason."
> 
> The Debian Project states that:
> 
>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 Debian Project makes no statement at this time on sysvinit support
> beyond the jessie release.
> 
> 
> This resolution is a Position Statement about Issues of the Day
> (Constitution 4.1.5), triggering the General Resolution override clause
> in the TC's resolution of the 11th of February.
> 
> The TC's decision on the default init system for Linux in jessie stands
> undisturbed.
> 
> However, the TC resolution is altered to add the additional text above.
> -- end proposal -->8

Seconded.

Thanks for writing a counter-proposal Lucas!

Regards,
Vincent



signature.asc
Description: OpenPGP digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Holger Levsen]

Hi,

On Freitag, 17. Oktober 2014, Lucas Nussbaum wrote:
> I am therefore bringing forward an alternative proposal, deeply inspired
> from the "Advice: sysvinit compatibility in jessie and multiple init
> support" option of the TC resolution on init system coupling[1], which
> was originally written by Russ Allbery[2] and was then amended by many
> participants to the discussion in February 2014.
> 
> [1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html
> [2] https://lists.debian.org/debian-ctte/2014/02/msg00447.html
> 
> - begin proposal ->8
> Debian has decided (via the technical committee) to change its default
> init system for the next release. The technical committee decided not to
> decide about the question of "coupling" i.e. whether other packages in
> Debian may depend on a particular init system.  However, the technical
> committee stated in #746715 that "[it] expects maintainers to continue to
> support the multiple available init systems in Debian.  That includes
> merging reasonable contributions, and not reverting existing support
> without a compelling reason."
> 
> The Debian Project states that:
> 
>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 Debian Project makes no statement at this time on sysvinit support
> beyond the jessie release.
> 
> 
> This resolution is a Position Statement about Issues of the Day
> (Constitution 4.1.5), triggering the General Resolution override clause
> in the TC's resolution of the 11th of February.
> 
> The TC's decision on the default init system for Linux in jessie stands
> undisturbed.
> 
> However, the TC resolution is altered to add the additional text above.
> -- end proposal -->8

seconded.

Thanks, Lucas.


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Andrey Rahmatullin]

On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> - begin proposal ->8
> Debian has decided (via the technical committee) to change its default
> init system for the next release. The technical committee decided not to
> decide about the question of "coupling" i.e. whether other packages in
> Debian may depend on a particular init system.  However, the technical
> committee stated in #746715 that "[it] expects maintainers to continue to
> support the multiple available init systems in Debian.  That includes
> merging reasonable contributions, and not reverting existing support
> without a compelling reason."
> 
> The Debian Project states that:
> 
>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 Debian Project makes no statement at this time on sysvinit support
> beyond the jessie release.
> 
> 
> This resolution is a Position Statement about Issues of the Day
> (Constitution 4.1.5), triggering the General Resolution override clause
> in the TC's resolution of the 11th of February.
> 
> The TC's decision on the default init system for Linux in jessie stands
> undisturbed.
> 
> However, the TC resolution is altered to add the additional text above.
> -- end proposal -->8
Seconded.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Alternative proposal: support for alternative init systems is desirable but not mandatory

[Lucas Nussbaum]

Hi,

It is now clear that we will have a vote on this issue. I think that we
should use this opportunity to clarify the Project's position, and that's
not something that would be achieved if "Further Discussion" were to
win.

I am therefore bringing forward an alternative proposal, deeply inspired
from the "Advice: sysvinit compatibility in jessie and multiple init
support" option of the TC resolution on init system coupling[1], which
was originally written by Russ Allbery[2] and was then amended by many
participants to the discussion in February 2014.

[1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html
[2] https://lists.debian.org/debian-ctte/2014/02/msg00447.html

- begin proposal ->8
Debian has decided (via the technical committee) to change its default
init system for the next release. The technical committee decided not to
decide about the question of "coupling" i.e. whether other packages in
Debian may depend on a particular init system.  However, the technical
committee stated in #746715 that "[it] expects maintainers to continue to
support the multiple available init systems in Debian.  That includes
merging reasonable contributions, and not reverting existing support
without a compelling reason."

The Debian Project states that:

   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 Debian Project makes no statement at this time on sysvinit support
beyond the jessie release.


This resolution is a Position Statement about Issues of the Day
(Constitution 4.1.5), triggering the General Resolution override clause
in the TC's resolution of the 11th of February.

The TC's decision on the default init system for Linux in jessie stands
undisturbed.

However, the TC resolution is altered to add the additional text above.
-- end proposal -->8

Lucas


signature.asc
Description: Digital signature