Keith Packard writes (Re: Bug#727708: init system coupling etc.):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Perhaps you would like to change this to something like:
The TC chooses to not pass a resolution at the current time
about whether software may require specific init
]] Colin Watson
So, in my amendment, I intended this to be the cooperating groups of
packages intended for use with specific init systems, which language I
think I borrowed from your proposal. If logind-208 Depends: systemd (or
indeed if it's part of systemd), then that's fine, as long as
* Russ Allbery (r...@debian.org) [140219 19:24]:
Andreas Barth a...@ayous.org writes:
* Russ Allbery (r...@debian.org) [140214 04:36]:
That's a much stronger statement than we've made about support for the
non-Linux ports in the past, where they're treated at most like another
release
Andreas Barth writes (Bug#727708: init system coupling etc.):
So I propose to change the text:
The Technical Committee offers no advice at this time on requirements
or package dependencies on specific init systems after the jessie
release. There are too many variables
Andreas Barth writes (Bug#727708: init system coupling etc.):
Russ Allbery (r...@debian.org) [140219 19:24]:
How does this sound to you?
Packages should normally support the default init system on all
architectures for which they are built. There are some exceptional
cases
Andreas Barth writes (Bug#727708: init system coupling etc.):
Russ Allbery (r...@debian.org) [140219 19:24]:
So I propose to change the text:
The Technical Committee offers no advice at this time on requirements
or package dependencies on specific init systems after the jessie
On Thu, Feb 20, 2014 at 05:20:22AM +0100, Tollef Fog Heen wrote:
]] Colin Watson
So, in my amendment, I intended this to be the cooperating groups of
packages intended for use with specific init systems, which language I
think I borrowed from your proposal. If logind-208 Depends: systemd
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I've done so, thanks.
Looks good.
--
keith.pack...@intel.com
pgp6pLZwyhYsw.pgp
Description: PGP signature
* Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 13:37]:
Andreas Barth writes (Bug#727708: init system coupling etc.):
Russ Allbery (r...@debian.org) [140219 19:24]:
How does this sound to you?
Packages should normally support the default init system on all
* Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 13:41]:
Andreas Barth writes (Bug#727708: init system coupling etc.):
Russ Allbery (r...@debian.org) [140219 19:24]:
So I propose to change the text:
The Technical Committee offers no advice at this time on requirements
Andreas Barth writes (Re: Bug#727708: init system coupling etc.):
Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 13:41]:
Looking at Russ's draft, he has already made an effectively identical
change. Russ's wording is:
The Technical Committee offers no advice at this time
For Andi's version of Russ's text I have written this summary line
into the git repo:
B Advice: sysvinit compatibility in jessie and multi init, arch, support
The difference between Russ's (A) and Andi's (B) is precisely this:
Software should normally support the default init system on
Ian Jackson ijack...@chiark.greenend.org.uk writes:
For Andi's version of Russ's text I have written this summary line
into the git repo:
B Advice: sysvinit compatibility in jessie and multi init, arch, support
The difference between Russ's (A) and Andi's (B) is precisely this:
Russ Allbery writes (Re: Bug#727708: init system coupling etc.):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
If Russ does not accept this amendment then both A and B will be on
the ballot.
I accept this amendment.
I have removed the unamended version from the git repo. I've
Russ Allbery writes (Bug#727708: init system coupling etc.):
If you do mean that all packages with init system configuration have to
ship sysvinit scripts, I wish the wording would actually say that. This
potentially matters in the long run. For example, consider a hypothetical
future world
I'm writing here in a purely secretarial capacity.
Russ Allbery writes (Bug#727708: init system coupling etc.):
Colin Watson cjwat...@debian.org writes:
I agree. Russ, how about this amendment?
Is that a formal proposal ?
diff --git a/727708_initsystem/coupling-russ.txt
b
Ian Jackson writes (Bug#727708: init system coupling etc.):
Steve Langasek writes (Bug#727708: init system coupling etc.):
So I don't think a 24 hour period between draft CfV and CfV is
adequate here. There have been a lot of proposals discussed in
this thread, and it's not at all clear
On Wed, Feb 19, 2014 at 06:55:31PM -0800, Russ Allbery wrote:
Colin Watson cjwat...@debian.org writes:
What I mean by this is that software (with all the exceptions above) may
not be shipped in a configuration where you can only use it with certain
init systems. For service startup, that
Colin Watson writes (Bug#727708: init system coupling etc.):
Would it improve things if we added an informative paragraph such as
this? (I'm not necessarily asking whether it would lead you to rank
this option higher, just whether it makes the intent clearer.)
This policy is intended
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Perhaps you would like to change this to something like:
The TC chooses to not pass a resolution at the current time
about whether software may require specific init systems.
I don't formally propose this because I see no point on
Colin Watson cjwat...@debian.org writes:
Also, after rereading your proposal, I notice you have a post-jessie
sunset clause where we would have to renew our advice if we wanted it to
continue to be effective (is this very meaningful in an informative
context?).
This was just an error on my
On Wed, Feb 19, 2014 at 09:37:50AM -0700, Bdale Garbee wrote:
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I'm going to try to go through this thread and produce a draft Call
for Votes based on the proposals, amendments etc. which have been
emailed so far.
That would be good,
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I think we should probably take that as you proposing and accepting an
amendment to your formal proposal. I'm going to prepare the draft CFV
on that basis.
But it would really help to be more explicit.
Right, I know, I wasn't expecting
Andreas Barth writes (Re: Bug#727708: init system coupling etc.):
* Russ Allbery (r...@debian.org) [140212 19:00]:
Packages should normally support the default Linux init system. There
I would drop the word Linux here - Packages should support our
default init systems
Andreas Barth a...@ayous.org writes:
* Russ Allbery (r...@debian.org) [140214 04:36]:
That's a much stronger statement than we've made about support for the
non-Linux ports in the past, where they're treated at most like another
release architecture, which means that packages that have never
Steve Langasek writes (Bug#727708: init system coupling etc.):
On Wed, Feb 19, 2014 at 09:37:50AM -0700, Bdale Garbee wrote:
That would be good, since I at least have sort of lost track of what you
think the ballot options will be at this point.
Likewise, I've lost the thread of what has
On Thu, Feb 13, 2014 at 06:51:13PM +, Ian Jackson wrote:
In the spirit of my response to Noah Meyerhans:
In general, software may not require a specific init system to be
pid 1. The exceptions to this are as follows:
* alternative init system implementations
*
Colin Watson writes (Bug#727708: init system coupling etc.):
On Thu, Feb 13, 2014 at 06:51:13PM +, Ian Jackson wrote:
Is this a clearer line to draw ?
This is largely clearer, thank you, but I find myself tripping over the
repetition of tolerable - it looks tautologous to me until about
On Thu, Feb 20, 2014 at 01:31:02AM +, Ian Jackson wrote:
I think this is a useful clarification and I accept this amendment.
Colin, since you already have it to hand in git I see, could you
commit it directly there to the same file ?
Sure, thanks - done.
--
Colin Watson
Colin Watson cjwat...@debian.org writes:
What I mean by this is that software (with all the exceptions above) may
not be shipped in a configuration where you can only use it with certain
init systems. For service startup, that just means shipping sysvinit
scripts. For other interfaces, that
* Russ Allbery (r...@debian.org) [140214 04:36]:
Andreas Barth a...@ayous.org writes:
* Russ Allbery (r...@debian.org) [140212 19:00]:
Packages should normally support the default Linux init system. There
I would drop the word Linux here - Packages should support our default
init
On Fri, Feb 14, 2014 at 03:31:41PM +0100, Josselin Mouette wrote:
Le vendredi 14 février 2014 à 13:50 +, Ian Jackson a écrit :
Josselin Mouette writes (Bug#727708: init system coupling etc.):
In all cases, it is unacceptable to put the burden of implementing
logind on non-systemd
* Russ Allbery (r...@debian.org) [140212 19:00]:
Packages should normally support the default Linux init system. There
I would drop the word Linux here - Packages should support our
default init systems.
If you do that then you have killed all non-linux architectures, is
that
Svante Signell svante.sign...@gmail.com writes:
* Russ Allbery (r...@debian.org) [140212 19:00]:
Packages should normally support the default Linux init system. There
I would drop the word Linux here - Packages should support our
default init systems.
If you do that then you have
On 2014-02-14 15:46:18 +, Ian Jackson wrote:
Ansgar Burchardt writes (Bug#727708: init system coupling etc.):
Don't you mean drop GNOME, KDE and others? It's not only GNOME that
plans to depend on logind...
logind is a red herring because AIUI we already have a technical
Debian is digging their own grave with respect to Free Software (not
FOSS or FOS), why don't you align with M$soft, Apple or especially
RedHat :( Debian will just be a memory in a few years, RedHat will be
the solution for everybody (TM).
Please take this sort of thing to some other
Josselin Mouette writes (Bug#727708: init system coupling etc.):
In all cases, it is unacceptable to put the burden of implementing
logind on non-systemd systems on maintainers of packages that just need
the logind interfaces. If it is not available, software such as gdm3
will depend, directly
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Firstly, I think the scenario where the required integration work is
not done is unlikely. But in that scenario, we have two choices:
(a) Effectively, drop all init systems other than systemd
(b) Effectively, drop GNOME
Of these, (b) is
Ian Jackson wrote:
Josselin Mouette writes (Bug#727708: init system coupling etc.):
In all cases, it is unacceptable to put the burden of implementing
logind on non-systemd systems on maintainers of packages that just need
the logind interfaces. If it is not available, software such as gdm3
Ian Jackson writes (Bug#727708: init system coupling etc.):
In the spirit of my response to Noah Meyerhans:
In general, software may not require a specific init system to be
pid 1. The exceptions to this are as follows:
* alternative init system implementations
Josselin Mouette writes (Bug#727708: init system coupling etc.):
Le jeudi 13 février 2014 à 23:47 -0800, Russ Allbery a écrit :
Depending on how this is written, it may depend on the package providing
journalctl or it may depend on some shared library that implements the
journal reading
Ian Jackson wrote:
I suppose what I mean is that a problem which occurs due to wrong
init system is a real problem and should not be reduced in severity or
excused on the grounds that the particular init system is defined as
required (whether via a dependency or otherwise).
So if the
On 2014-02-14 15:46:18 +, Ian Jackson wrote:
Ansgar Burchardt writes (Bug#727708: init system coupling etc.):
Don't you mean drop GNOME, KDE and others? It's not only GNOME that
plans to depend on logind...
logind is a red herring because AIUI we already have a technical
solution
Hi,
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Ansgar Burchardt writes (Bug#727708: init system coupling etc.):
Don't you mean drop GNOME, KDE and others? It's not only GNOME that
plans to depend on logind...
logind is a red herring because AIUI we already have a technical
solution
Josselin Mouette j...@debian.org writes:
Le vendredi 14 février 2014 à 13:50 +, Ian Jackson a écrit :
Josselin Mouette writes (Bug#727708: init system coupling etc.):
In all cases, it is unacceptable to put the burden of implementing
logind on non-systemd systems on maintainers
Josselin Mouette j...@debian.org writes:
So either Steve and his cronies commit to maintain a separate systemd204
package (with all the switching issues that scenario involves),
Hi Josselin,
I realize that passions are running high here, and there has been a great
deal of bad blood on both
On Fri, Feb 14, 2014 at 04:59:34PM +0100, Andres Freund wrote:
On 2014-02-14 15:46:18 +, Ian Jackson wrote:
Ansgar Burchardt writes (Bug#727708: init system coupling etc.):
Don't you mean drop GNOME, KDE and others? It's not only GNOME that
plans to depend on logind...
logind
On 02/14/2014 12:14 PM, Steve Langasek wrote:
On Fri, Feb 14, 2014 at 04:59:34PM +0100, Andres Freund wrote:
On 2014-02-14 15:46:18 +, Ian Jackson wrote:
Ansgar Burchardt writes (Bug#727708: init system coupling etc.):
Don't you mean drop GNOME, KDE and others? It's not only GNOME
On 2014-02-14 10:14:54 -0800, Steve Langasek wrote:
On Fri, Feb 14, 2014 at 04:59:34PM +0100, Andres Freund wrote:
On 2014-02-14 15:46:18 +, Ian Jackson wrote:
Ansgar Burchardt writes (Bug#727708: init system coupling etc.):
Don't you mean drop GNOME, KDE and others? It's not only
On Fri, Feb 14, 2014 at 07:49:32PM +0100, Andres Freund wrote:
I am not so sure it's there. The current version runs without systemd
but doesn't support everything
Based on what? There is only one new interface in logind between v204 and
v208, an
On 02/14/2014 01:52 PM, Steve Langasek wrote:
On Fri, Feb 14, 2014 at 07:49:32PM +0100, Andres Freund wrote:
I am not so sure it's there. The current version runs without systemd
but doesn't support everything
Based on what? There is only one new interface in logind between v204 and
v208, an
Lucas Nussbaum writes (Bug#727708: init system coupling etc.):
If you really want to have that discussion now, rather than wait for
actual, concrete problems to discuss, I'd suggest that you build a few
hypothetical scenarios, and discuss them. And then build a resolution
that represents
Keith Packard writes (Bug#727708: init system coupling etc.):
I agree with you that this is an important issue which needs to be
resolved within the Debian project. I also want to make it clear that I
support the goal of having the project provide a clear policy statement
about this issue
Ian Jackson ijack...@chiark.greenend.org.uk writes:
[...]
I don't find Sjoerd Simons's comments very reassuring. In the context
of the whole discussion I think Adrian's interpretation is much more
likely to reflect the true sentiment.
I wouldn't give Adrian too much credit. Please read some
Hi!
AIUI GNOME in sid right now can't lock the screen unless you're using
systemd.
When I asked about this [0], I got one reply (by Bdale) saying that
a missing functionality like this is fine as long as there is no hard
dependency on systemd and things somehow load. If your opinion is
On Wed, Feb 12, 2014 at 10:35:12PM +, Ian Jackson wrote:
Software outside of an init system's implementation may not require
a specific init system to be pid 1, although degraded operation is
tolerable.
This is super vague. What does being outside of an init system's
* Russ Allbery (r...@debian.org) [140212 19:00]:
Packages should normally support the default Linux init system. There
I would drop the word Linux here - Packages should support our
default init systems.
are some exceptional cases where lack of support for the default init
system
Noah Meyerhans writes (Bug#727708: init system coupling etc.):
On Wed, Feb 12, 2014 at 10:35:12PM +, Ian Jackson wrote:
Yes. I agree that it's vague. I'm open to better and clearer
suggestions. When I wrote this I was hoping that the policy process
would be able to refine the details
On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote:
I propose the following text as an amendment to this option. It would
replace this text in its entirety, including the [GR rider] section. (I
don't see any need for or purpose served by cancelling technical advice to
the project
Colin Watson writes (Bug#727708: init system coupling etc.):
Ian, you said that you don't agree with this amendment. I am guessing
based on your previous statements that you mainly disagree with the
force of it, rather than the substance, but I'm cautious of making
unwarranted inferences
On Feb 12, Russ Allbery wrote:
Packages should normally support the default Linux init system.
[..]
Package maintainers are strongly encouraged to merge any contributions
for support of init systems other than the Linux default, and to add
that support themselves if they're
On Thu, Feb 13, 2014 at 06:01:56PM +, Ian Jackson wrote:
I suppose what I mean is that a problem which occurs due to wrong
init system is a real problem and should not be reduced in severity or
excused on the grounds that the particular init system is defined as
required (whether via a
Colin Watson writes (Bug#727708: init system coupling etc.):
To start with, I therefore propose the following amendment to L. I
think it is no weaker except in ways that we would agree were in fact OK
if we found ourselves needing to rule on them specifically, and this
addresses points
* Colin Watson (cjwat...@debian.org) [140213 19:09]:
To start with, I therefore propose the following amendment to L. I
think it is no weaker except in ways that we would agree were in fact OK
if we found ourselves needing to rule on them specifically, and this
addresses points that people
On Thu, Feb 13, 2014 at 08:56:44PM +0100, Andreas Barth wrote:
* Colin Watson (cjwat...@debian.org) [140213 19:09]:
To start with, I therefore propose the following amendment to L. I
think it is no weaker except in ways that we would agree were in fact OK
if we found ourselves needing to
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I don't think this is likely but I can see why you would want to try
that.
Thanks. Being new to the TC, I may feel more reluctant to exercise it's
process than people more familiar to the role.
And it is different from FD in that if enough
Andreas Barth a...@ayous.org writes:
* Russ Allbery (r...@debian.org) [140212 19:00]:
Packages should normally support the default Linux init system. There
I would drop the word Linux here - Packages should support our default
init systems.
That's a much stronger statement than we've
Colin Watson cjwat...@debian.org writes:
I'm currently undecided about whether I prefer the approach of setting
technical policy under 6.1.1 or offering advice under 6.1.5. Bearing in
mind all the process discussions we've had, I can see that it might be
better to take the approach of
Uwe Storbeck u...@ibr.ch writes:
On Feb 12, Russ Allbery wrote:
Packages should normally support the default Linux init system.
[..]
Package maintainers are strongly encouraged to merge any contributions
for support of init systems other than the Linux default, and to add
Ian Jackson ijack...@chiark.greenend.org.uk writes:
[loose coupling]
Software outside of an init system's implementation may not require
a specific init system to be pid 1, although degraded operation is
tolerable.
Maintainers are encouraged to accept technically sound patches
Ian Jackson ijack...@chiark.greenend.org.uk writes:
FORMAL ACTION: I therefore hereby formally propose the following
resolution (init system coupling v2), but do not yet call for votes.
[rationale]
The default init system decision is limited to selecting a default
initsystem for
Russ Allbery r...@debian.org writes:
The following is technical advice offered to the project by the
Technical Committee under section 6.1.5 of the constitution. It does
not constitute an override of maintainer decisions past or future:
Thanks for making this clear -- operating
On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote:
...
All packages should support
smooth upgrades from wheezy to jessie, including upgrades done on a
system booted with sysvinit.
...
This sounds like a statement by the TC that smooth upgrades from wheezy
to jessie will
Adrian Bunk b...@stusta.de writes:
On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote:
...
All packages should support
smooth upgrades from wheezy to jessie, including upgrades done on a
system booted with sysvinit.
...
This sounds like a statement by the TC that
When I've found myself trying to avoid normative language in situations
like this I end up with statements like:
It is important that all packages support smoothe upgrades from Wheezy
to Jessie , even when the system is booted with sysvinit.
--
To UNSUBSCRIBE, email to
Hi,
...
All packages should support
smooth upgrades from wheezy to jessie, including upgrades done on a
system booted with sysvinit.
...
If there is an alternative wording that fits those constraints that people
would prefer, I'm certainly happy to consider it for
On Wed, Feb 12, 2014 at 11:35:11AM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote:
...
All packages should support
smooth upgrades from wheezy to jessie, including upgrades done on a
system booted
On Wed, Feb 12, 2014 at 06:09:38PM +0100, Lucas Nussbaum wrote:
Hi,
I must admit that I only followed this part of the discussion from a
distance.
However, one thing really strikes me:
On 12/02/14 at 14:08 +, Ian Jackson wrote:
[loose coupling]
Software outside of an init
On Wed, 2014-02-12 at 23:30 +0200, Adrian Bunk wrote:
On Wed, Feb 12, 2014 at 06:09:38PM +0100, Lucas Nussbaum wrote:
Hi,
I must admit that I only followed this part of the discussion from a
distance.
However, one thing really strikes me:
On 12/02/14 at 14:08 +, Ian Jackson
On Wed, Feb 12, 2014 at 6:56 PM, Russ Allbery r...@debian.org wrote:
Please note that I personally am currently leaning towards voting Keith's
proposal above the one that I'm proposing in this message for the reasons
that he states in that message.
Given the overall heat in the prior debate,
80 matches
Mail list logo
