Hi,
Bdale Garbee:
I'm not comfortable with a mandate that packages may not require a
specific init system as pid 1.
Could we (or rather, the CTTE) compromise on packages may mandate
the default init system?
--
-- Matthias Urlichs
--
To UNSUBSCRIBE, email to
On Sat, 01 Feb 2014, Steve Langasek wrote:
Where would this ballot option rank vis-à-vis FD, for those TC members
who are opposed to the loose coupling option?
I'm planning on ranking everything above FD. However, I would rank this
particular option at the same level as L.
== dependencies
Steve Langasek writes (Re: Bug#727708: multiple init systems - formal
resolution proposal):
As things stand, it seems that each set of dependency rider options will
have some members of the TC voting them below FD. Which means I don't think
we've actually gotten to the bottom of this issue
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Steve Langasek writes:
Where would this ballot option rank vis-à-vis FD, for those TC members
who are opposed to the loose coupling option?
[...]
AFAICT neither Russ or Bdale have directly answered your question.
I thought I did, sorry.
Plus sysvinit support isn't
forever, since eventually it will be deprecated as more and more parts
of the system drop support for it.
Why? There is nothing wrong with sysv init for most of us.
Why is there insistance (or seemingly triumphal predictions)
that those of us who are happy with the
The point that is being made is not you can't run software with shell
scripts if you want, it's don't expect developers to write or maintain
them for you.
Regards, James Rhodes.
On 3 February 2014 12:48, Thilos Rich thilos.r...@aol.com wrote:
Plus sysvinit support isn't
forever, since
, 2014 2:00 am
Subject: Re: Bug#727708: multiple init systems - formal resolution proposal
The point that is being made is not you can't run software with shell scripts
if you want, it's don't expect developers to write or maintain them for you.
Regards, James Rhodes.
On 3 February 2014
we will not help you
If you want to run a configuration that is not supported by a developer,
then no, I would not expect them to help you.
Free software does not entitle you to free help, nor does it entitle you to
demand others do or don't do things a particular way.
On Sun, Feb 02, 2014 at 09:30:36PM -0500, Thilos Rich wrote:
Don't be facetious. The point that is being made is:
Thilos, James, this is not the appropriate place for you to have this
conversation. Please leave this bug for its intended purpose, which is the
technical commitee's discussion
On Sun, Feb 02, 2014 at 09:30:36PM -0500, Thilos Rich wrote:
Don't be facetious. The point that is being made is:
F U C K system v init. F U C K anyone who relies on it,
uses it, likes it, we will not help you, we will not
continue on with it, F U C K U N I X, F U C K old sys
admins.
No,
On Wed, Jan 29, 2014 at 10:13:25PM +0200, Adrian Bunk wrote:
No, Josselin was making the technical claim that GNOME 3.10 would need a
working logind even for basic functionality.
So if it is possible to get the basic functionality of GNOME 3.10
without a working logind, his claim is just
Steve Langasek writes (Bug#727708: multiple init systems - formal resolution
proposal):
Thus, for me, all of the T variants in Ian's latest draft
(21226.41292.366504.997...@chiark.greenend.org.uk) rank below FD.
Note that there is a difference, of course, between GR and FD, in the
voting
Steve Langasek writes (Bug#727708: multiple init systems - formal resolution
proposal):
[stuff]
Thanks for that, which I mostly agree with.
On Wed, Jan 29, 2014 at 10:13:25PM +0200, Adrian Bunk wrote:
Thus, for me, all of the T variants in Ian's latest draft
(21226.41292.366504.997
Steve Langasek vor...@debian.org writes:
And so I am greatly dismayed by the position Russ and Bdale have taken
in this discussion with respect to packages being allowed to depend on a
specific init system. Both have expressed the opinion that Debian
should remain open to alternative init
On Sat, Feb 01, 2014 at 07:28:49PM +, Ian Jackson wrote:
Steve Langasek writes (Bug#727708: multiple init systems - formal resolution
proposal):
Thus, for me, all of the T variants in Ian's latest draft
(21226.41292.366504.997...@chiark.greenend.org.uk) rank below FD.
In my mail
Steve Langasek vor...@debian.org writes:
Where would this ballot option rank vis-à-vis FD, for those TC members who
are opposed to the loose coupling option?
== dependencies rider version S (split-the-init) ==
This decision is limited to selecting a default initsystem; we
continue to
Russ Allbery wrote:
Steve Langasek vor...@debian.org writes:
And so I am greatly dismayed by the position Russ and Bdale have taken
in this discussion with respect to packages being allowed to depend on a
specific init system. Both have expressed the opinion that Debian
should remain
Josh Triplett j...@joshtriplett.org writes:
It should be completely trivial to introduce a virtual
org-freedesktop-login1 package (modulo any complexities introduced by
interface versioning for new methods added to that interface). However,
it also seems pointless until there's a prospective
On Sat, Feb 01, 2014 at 01:21:19PM -0800, Russ Allbery wrote:
Josh Triplett j...@joshtriplett.org writes:
It should be completely trivial to introduce a virtual
org-freedesktop-login1 package (modulo any complexities introduced by
interface versioning for new methods added to that
On Sat, Feb 01, 2014 at 01:12:34PM -0800, Josh Triplett wrote:
In particular, in the case of GNOME, I don't see any package in the
archive yet for a fork of logind that depends on systemd-shim instead of
systemd, so there's no alternative available for GNOME to depend on.
There is no fork of
On Sat, Feb 01, 2014 at 05:23:11PM -0500, Steve Langasek wrote:
On Sat, Feb 01, 2014 at 01:12:34PM -0800, Josh Triplett wrote:
In particular, in the case of GNOME, I don't see any package in the
archive yet for a fork of logind that depends on systemd-shim instead of
systemd, so there's no
On Sat, Feb 01, 2014 at 11:25:01AM -0500, Steve Langasek wrote:
Josselin has asserted not only that he considers systemd-as-init a hard
dependency for GNOME in jessie, but that he expects the release team to side
with him over the Technical Committee if the TC does not agree with him.
This is
On Sat, Feb 1, 2014 at 11:25 AM, Steve Langasek wrote:
On Wed, Jan 29, 2014 at 10:13:25PM +0200, Adrian Bunk wrote:
And that does matter a lot, since such claims seem to be the basis
of all these GNOME in jessie needs systemd or with multiple init
systems, GNOME will need a dependency on
Le jeudi 30 janvier 2014 à 22:43 +0400, Sergey B Kirpichev a écrit :
https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv
Since you forgot to paste the first sentence, let me add it here.
“Sysvinit was never designed to cope with the dynamic/event-based
architecture of the
On Wed, Jan 29, 2014 at 03:18:46PM -0800, Russ Allbery wrote:
Given that, your opinions about the quality of GNOME upstream development
don't seem relevant to the problem we're trying to resolve. If you don't
like the software, don't use it.
Unfortunately, it doesn't save us, as the set of
Matthias Klumpp dixit:
2014-01-30 ChaosEsque Team chaosesquet...@yahoo.com:
[bullshit]
This was actually *not* bullshit. The delivery of most of the
content could use some polishing, but the content is a(n inconvenient)
truth.
Wasn't there some kind of a ban applied here?
Apparently not, but
On Thu, Jan 30, 2014 at 12:05:05PM +, Thorsten Glaser wrote:
This was actually *not* bullshit. The delivery of most of the
content could use some polishing, but the content is a(n inconvenient)
truth.
Man, if someone was spouting garbage like that in support of systemd,
you bet your mksh
Putting it another way, then, I expect there are some people who will
not want systemd on their GNU/Linux systems. I don't think it matters
if their reasons are technical, political, irrational fear or personal
dislike of the creator; I'd like them to have that choice and for it to
work as well
2014-01-30 Thorsten Glaser t...@mirbsd.de:
Matthias Klumpp dixit:
2014-01-30 ChaosEsque Team chaosesquet...@yahoo.com:
[bullshit]
This was actually *not* bullshit. The delivery of most of the
content could use some polishing, but the content is a(n inconvenient)
truth.
Wasn't there some
Matthias Klumpp dixit:
What would happen if we adopted systemd?
The project would lose (a different set of) contributors and users.
The OSS ecosystem would lose, vendor-lock-in would ensue in a way
even worse than the FSF does, and the remnants of Unix/GNU in Debian
would die, to be replaced by
Matthias Klumpp writes (Bug#727708: multiple init systems - formal resolution
proposal - Don't like software, don't use it. Absolutely.):
What would be the effecr if we decided to drop GNOME, because it
depends on systemd?
In this hypothetical scenario:
It would be fairly easy
On 30/01/14 17:01, Thorsten Glaser wrote:
And the GNOME/systemd people are invited to make their dream
of the FLOS GNOME OS into a Debian derivate or Pure Blend.
If the chosen default is something other than systemd, and if the TC
resolution does not prevent GNOME having a hard dependency on
On Thu, Jan 30, 2014 at 05:30:04PM +0100, Matthias Klumpp wrote:
What would be the effecr if we decided to drop GNOME, because it
depends on systemd?
Of course, Debian would have played with it's muscles, but in the end
we would have lost GNOME users, all GNOME developers and many
motivated
Le jeudi 30 janvier 2014 à 21:38 +0400, Sergey B Kirpichev a écrit :
[Lots of crap]
Where is the list of problems for sysvinit we intend to solve?
https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv
--
.''`.Josselin Mouette
: :' :
`. `'
`-
--
To
Matthias Klumpp writes (Bug#727708: multiple init systems - formal
resolution proposal - Don't like software, don't use it.
Absolutely.):
What would be the effecr if we decided to drop GNOME, because it
depends on systemd?
In this hypothetical scenario:
It would be fairly easy
On Thu, Jan 30, 2014 at 06:47:02PM +0100, Josselin Mouette wrote:
Le jeudi 30 janvier 2014 à 21:38 +0400, Sergey B Kirpichev a écrit :
[Lots of crap]
Nice argumentation, as usual...
Where is the list of problems for sysvinit we intend to solve?
On Thu, Jan 30, 2014 at 6:38 PM, Sergey B Kirpichev
skirpic...@gmail.com wrote:
On Thu, Jan 30, 2014 at 05:30:04PM +0100, Matthias Klumpp wrote:
GNOME upstream won't really change
Why? There are non-Linux GNOME users, for example. If the GNOME
developers don't care even about such popular
On Thu, Jan 30, 2014 at 12:04 PM, Ian Jackson wrote:
What would be the effecr if we decided to drop GNOME, because it
depends on systemd?
In this hypothetical scenario:
It would be fairly easy for a downstream of Debian to mandate systemd
for their users, and provide Gnome.
It would not
Sergey B Kirpichev skirpic...@gmail.com writes:
Are X-people indeed sacrifice portability, or there is something
different (e.g. these dependencies are optional)?
Speaking as the X server release manager, the systemd patches exist
solely to provide for interoperation with systemd or other
2014-01-31 Keith Packard kei...@keithp.com:
Sergey B Kirpichev skirpic...@gmail.com writes:
[...]
Where is the list of problems for sysvinit we intend to solve?
For X, the problem is running X as a user other than root, which should
provide for increased system security as we'll be reducing
Matthias Klumpp matth...@tenstral.net writes:
Of course it does not exclude implementing that stuff in a different,
non-systemd tool, but to my knowledge nobody has done that yet.
Exactly so. I have ideas on how this might work in a simpler and more
general fashion, but people rarely listen to
Le mardi 28 janvier 2014 à 19:34 +0200, Adrian Bunk a écrit :
On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote:
On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette j...@debian.org wrote:
Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
No. My question isn't
On Wed, Jan 29, 2014 at 10:05:22AM +0100, Josselin Mouette wrote:
Le mardi 28 janvier 2014 à 19:34 +0200, Adrian Bunk a écrit :
On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote:
On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette j...@debian.org wrote:
Le mardi 28 janvier 2014
On Tue, Jan 28, 2014 at 10:50:00PM +0100, Olav Vitters wrote:
...
Further, in my
experience it was *way* more stable to either go for full systemd or
always rely on the reduced functionality. The runtime detection of is
systemd running as PID 1 was IMO not very stable (and that wasn't just
Le mercredi 29 janvier 2014 à 19:03 +0200, Adrian Bunk a écrit :
No, you are not. There are several features in systemd that GNOME uses.
One of them is user sessions, for which there will indeed be a fallback
in place. But it is not the only one.
Can you provide a list of features
On Wed, Jan 29, 2014 at 06:41:11PM +0100, Josselin Mouette wrote:
Le mercredi 29 janvier 2014 à 19:03 +0200, Adrian Bunk a écrit :
...
Assuming jessie will support multiple init systems, why would GNOME need
a dependency on systemd?
Because it needs logind.
Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit :
What *basic functionality* exactly is missing in GNOME 3.10 without logind?
Note that I am not referring to bugs that are not yet sorted out like
* Switch from consolekit to systemd-logind sessions. For some reason
On Wed, Jan 29, 2014 at 07:17:29PM +0100, Josselin Mouette wrote:
Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit :
What *basic functionality* exactly is missing in GNOME 3.10 without logind?
Note that I am not referring to bugs that are not yet sorted out like
* Switch
Le mercredi 29 janvier 2014 à 20:43 +0200, Adrian Bunk a écrit :
You have the answer to your own question above. Unlocking the screen
sounds like pretty basic functionality.
Your statement was
I also have to insist that GNOME 3.10+ *needs* a working logind even for
basic functionality
Adrian Bunk b...@stusta.de writes:
On Wed, Jan 29, 2014 at 07:17:29PM +0100, Josselin Mouette wrote:
Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit :
What *basic functionality* exactly is missing in GNOME 3.10 without
logind?
Note that I am not referring to bugs that are
On Wed, Jan 29, 2014 at 11:27:53AM -0800, Russ Allbery wrote:
Adrian Bunk b...@stusta.de writes:
On Wed, Jan 29, 2014 at 07:17:29PM +0100, Josselin Mouette wrote:
Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit :
What *basic functionality* exactly is missing in GNOME 3.10
2014-01-29 Adrian Bunk b...@stusta.de:
[...]
I do fully acknowledge that there are issues with ConsoleKit being
unmaintained and many non-systemd codepath in GNOME being unmaintained
and with GNOME missing some non-basic functionality without systemd.
But claims that even basic functionality
Matthias Klumpp dixit:
No, Josselin is right: GNOME *does not* work without services provided
by systemd. He never said that - given some amount of work - it can't
Hum, we can always add “remove GNOME (3) from Debian” to the
list of GR or TC points to consider (this *has* been suggested
earlier,
On Wed, Jan 29, 2014 at 09:24:16PM +0100, Matthias Klumpp wrote:
2014-01-29 Adrian Bunk b...@stusta.de:
[...]
I do fully acknowledge that there are issues with ConsoleKit being
unmaintained and many non-systemd codepath in GNOME being unmaintained
and with GNOME missing some non-basic
Adrian Bunk b...@stusta.de writes:
On Wed, Jan 29, 2014 at 11:27:53AM -0800, Russ Allbery wrote:
I'm still wondering if maybe there's just a communication failure here, so
let me try one more round.
My understanding of what Josselin is saying is that GNOME's ConsoleKit
support is
On Wed, Jan 29, 2014 at 08:45:32PM +, Thorsten Glaser wrote:
Matthias Klumpp dixit:
No, Josselin is right: GNOME *does not* work without services provided
by systemd. He never said that - given some amount of work - it can't
Hum, we can always add “remove GNOME (3) from Debian” to the
Hello,
On Wed, 29 Jan 2014 19:17:29 +0100
Josselin Mouette j...@debian.org wrote:
Gnome-shell uses GDM for screen locking, and GDM heavily relies on
logind nowadays. There is fallback code that uses ConsoleKit, but it
has been untested for several major releases, and now fails even for
On Wed, Jan 29, 2014 at 11:54:11PM +0100, Andrew Shadura wrote:
On Wed, 29 Jan 2014 19:17:29 +0100
Josselin Mouette j...@debian.org wrote:
Gnome-shell uses GDM for screen locking, and GDM heavily relies on
logind nowadays. There is fallback code that uses ConsoleKit, but it
has been
On 30 January 2014 09:54, Andrew Shadura and...@shadura.me wrote:
Hello,
On Wed, 29 Jan 2014 19:17:29 +0100
Josselin Mouette j...@debian.org wrote:
Gnome-shell uses GDM for screen locking, and GDM heavily relies on
logind nowadays. There is fallback code that uses ConsoleKit, but it
Andrew Shadura and...@shadura.me writes:
Josselin Mouette j...@debian.org wrote:
Gnome-shell uses GDM for screen locking, and GDM heavily relies on
logind nowadays. There is fallback code that uses ConsoleKit, but it
has been untested for several major releases, and now fails even for
This sounds like a good solution, since MATE is the gnome we all knew, and the
Gnome of today is a different beast entirely (though it gets to keep the name).
::
Hum, we can always add “remove GNOME (3) from Debian” to the
list of GR or TC points to consider (this *has* been suggested
earlier,
If you don't like the software, don't use it.
Absolutely. But that is not really an option that is to be afforded to all of
us if
the systemd guys successfully have their way with linux.
It would be nice if they afforded us such a freedom, but their statements
and their actions suggest that
2014-01-30 ChaosEsque Team chaosesquet...@yahoo.com:
[bullshit]
Wasn't there some kind of a ban applied here?
I am confused.
Cheers,
Matthias
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
Adrian Bunk b...@stusta.de writes:
You are forgetting the best technical solution, which is what
gnome-session is actually implementing at the moment:
session_tracking=systemd (with fallback to ConsoleKit) [1]
No.
On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette j...@debian.org wrote:
Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
No. My question isn't about logind, but about using a user systemd
session to supervise processes started by the session. IIRC both GNOME
and KDE were
Michael Gilbert dixit:
Why not avoid impeding progress and just let gnome do what it needs to
work the way it wants, which would involve depending on the right
Excuse me, why is GNOME, specifically, being allowed to “do what it
wants”, in this case? Imagine other software with a more-or-less
Olav Vitters dixit:
IMO other init systems should provide the interfaces which GNOME
requires. It is not up to GNOME to provide these. That or takeup
There is a lot wrong with that statement.
Imagine you’re working on/with a software FOO that is not yet
packaged in Debian. Say it comes from the
On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote:
On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette j...@debian.org wrote:
Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
No. My question isn't about logind, but about using a user systemd
session to supervise
Ian Jackson writes (multiple init systems - formal resolution proposal):
I hereby propose the following resolution:
1. Support for sysvinit is mandatory in jessie.
2. Debian intends to support multiple init systems, for the
foreseeable future, and so long as their respective
On Tue, Jan 28, 2014 at 07:34:56PM +0200, Adrian Bunk wrote:
On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote:
On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette j...@debian.org wrote:
Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
No. My question isn't
On Tue, Jan 28, 2014 at 9:57 AM, Thorsten Glaser wrote:
Michael Gilbert dixit:
Why not avoid impeding progress and just let gnome do what it needs to
work the way it wants, which would involve depending on the right
Excuse me, why is GNOME, specifically, being allowed to “do what it
wants”,
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I hereby propose the following resolution:
1. Support for sysvinit is mandatory in jessie.
2. Debian intends to support multiple init systems, for the
foreseeable future, and so long as their respective communities
and
Hi,
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Ian Jackson writes (Bug#727708: multiple init systems - formal resolution
proposal):
I hereby propose the following resolution:
1. Support for sysvinit is mandatory in jessie.
I hereby propose and accept an amendment to add a new
On Mon, Jan 27, 2014 at 11:59 AM, Ian Jackson wrote:
2. Debian intends to support multiple init systems, for the
foreseeable future, and so long as their respective communities
and code remain healthy. Nothing outside of an init system's
implementation may require a
On Tue, Jan 28, 2014 at 12:18:09AM +0100, Ansgar Burchardt wrote:
...
== version multiple only ==
2. Debian intends to support multiple init systems, for the
foreseeable future, and so long as their respective communities
and code remain healthy. Nothing outside of an
On Mon, Jan 27, 2014 at 08:54:13PM -0500, Michael Gilbert wrote:
On Mon, Jan 27, 2014 at 11:59 AM, Ian Jackson wrote:
2. Debian intends to support multiple init systems, for the
foreseeable future, and so long as their respective communities
and code remain healthy. Nothing
On Tue, Jan 28, 2014 at 08:40:01AM +0200, Adrian Bunk wrote:
...
[1] That's ignoring the possibility that a non-systemd logind
replacement with sufficient functionality for all software following
the latest logind features might show up one day - but
,,,
Please ignore this part of
❦ 28 janvier 2014 07:23 CET, Adrian Bunk b...@stusta.de :
You are forgetting the best technical solution, which is what
gnome-session is actually implementing at the moment:
session_tracking=systemd (with fallback to ConsoleKit) [1]
Sure, the best technical solution is to rely on an
Adrian Bunk b...@stusta.de writes:
On Tue, Jan 28, 2014 at 12:18:09AM +0100, Ansgar Burchardt wrote:
...
== version multiple only ==
2. Debian intends to support multiple init systems, for the
foreseeable future, and so long as their respective communities
and code
I hereby propose the following resolution:
1. Support for sysvinit is mandatory in jessie.
2. Debian intends to support multiple init systems, for the
foreseeable future, and so long as their respective communities
and code remain healthy. Nothing outside of an init system's
Ian Jackson writes (multiple init systems - formal resolution proposal):
I hereby propose the following resolution:
1. Support for sysvinit is mandatory in jessie.
2. Debian intends to support multiple init systems, for the
foreseeable future, and so long as their respective
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I hereby propose the following resolution:
1. Support for sysvinit is mandatory in jessie.
I agree with this in principle, but I think this loses quite a bit of
nuance and is likely, phrased in that way, to be used as a stick to beat
Russ Allbery writes (Bug#727708: multiple init systems - formal resolution
proposal):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I hereby propose the following resolution:
1. Support for sysvinit is mandatory in jessie.
I agree with this in principle, but I think this loses
Le lundi 27 janvier 2014 à 16:59 +, Ian Jackson a écrit :
I hereby propose the following resolution:
1. Support for sysvinit is mandatory in jessie.
2. Debian intends to support multiple init systems, for the
foreseeable future, and so long as their respective communities
Josselin Mouette writes (Bug#727708: multiple init systems - formal resolution
proposal):
Le lundi 27 janvier 2014 à 16:59 +, Ian Jackson a écrit :
I hereby propose the following resolution:
1. Support for sysvinit is mandatory in jessie.
2. Debian intends to support
Le lundi 27 janvier 2014 à 17:48 +, Ian Jackson a écrit :
Josselin Mouette writes (Bug#727708: multiple init systems - formal
resolution proposal):
Since this resolution would override the will of each maintainer to make
his package depend on whatever init system the software depends
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Russ Allbery writes:
2. Debian intends to support multiple init systems, for the
foreseeable future, and so long as their respective communities
and code remain healthy. Nothing outside of an init system's
Ian Jackson writes (Bug#727708: multiple init systems - formal resolution
proposal):
I hereby propose the following resolution:
1. Support for sysvinit is mandatory in jessie.
I hereby propose and accept an amendment to add a new rubric paragraph
0, and I also propose and do NOT accept
88 matches
Mail list logo
