Hi,
On 20/10/14 at 14:47 -0400, Sam Hartman wrote:
Joey == Joey Hess jo...@debian.org 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,
Lucas Nussbaum lu...@debian.org 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
Quoting Nikolaus Rath (2014-10-21 02:41:12)
Ian Jackson ijack...@chiark.greenend.org.uk 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
Jonas Smedegaard d...@jones.dk writes:
Quoting Nikolaus Rath (2014-10-19 20:21:59)
Ian Jackson ijack...@chiark.greenend.org.uk writes:
David Weinehall writes (Re: Alternative proposal: support for alternative
init systems is desirable but not mandatory):
OK, so packaging uselessd (thus
Jonas Smedegaard d...@jones.dk writes:
Quoting Nikolaus Rath (2014-10-19 20:16:37)
Jonas Smedegaard d...@jones.dk 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
Quoting Nikolaus Rath (2014-10-20 05:19:03)
Jonas Smedegaard d...@jones.dk 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
Nikolaus Rath nikol...@rath.org 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
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
Quoting Nikolaus Rath (2014-10-20 05:29:10)
Jonas Smedegaard d...@jones.dk writes:
Quoting Nikolaus Rath (2014-10-19 20:21:59)
Ian Jackson ijack...@chiark.greenend.org.uk writes:
David Weinehall writes (Re: Alternative proposal: support for alternative
init systems is desirable
+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 d...@jones.dk wrote:
Quoting Nikolaus Rath (2014-10-19 20:16:37)
Jonas Smedegaard d...@jones.dk writes:
Quoting David Weinehall (2014-10-19
Joey == Joey Hess jo...@debian.org 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
Sam Hartman wrote:
Joey == Joey Hess jo...@debian.org 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
Ian Jackson ijack...@chiark.greenend.org.uk 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
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
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
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
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:
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
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
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
Jonas Smedegaard d...@jones.dk 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
Ian Jackson ijack...@chiark.greenend.org.uk 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
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
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*
Quoting Nikolaus Rath (2014-10-19 20:16:37)
Jonas Smedegaard d...@jones.dk 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
Quoting Nikolaus Rath (2014-10-19 20:21:59)
Ian Jackson ijack...@chiark.greenend.org.uk 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
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
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
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
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
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
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
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
Seconded.
On Oct 17, Lucas Nussbaum lu...@debian.org 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
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 -
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
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
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
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
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
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
--
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
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
On 17 October 2014 13:44, Neil McGovern ne...@debian.org 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
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
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
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
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
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
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
Hi,
Joey Hess jo...@debian.org 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
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
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
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
QA that make it easier to understand the differences and the possible
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
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
56 matches
Mail list logo
