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 debian-ctte-requ...@list
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.
> == dependencie
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.
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
> 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.
: 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.
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 wrote:
> >Plus sysvinit support isn't
> >forever, since eventually it wil
>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 s
Ian Jackson writes:
> Steve Langasek writes:
>> Where would this ballot option rank vis-à-vis FD, for those TC members
>> who are opposed to the "loose coupling" option?
[...]
> AFAICT neither Russ or Bdale have directly answered your question.
I thought I did, sorry. I would rank those optio
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
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 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
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
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 01:21:19PM -0800, Russ Allbery wrote:
> Josh Triplett 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). Howeve
Josh Triplett writes:
> It should be completely trivial to introduce a virtual
> "org-freedesktop-login1" package (modulo any complexities introduced by
> interface versioning for new methods added to that interface). However,
> it also seems pointless until there's a prospective provider of tha
Russ Allbery wrote:
> Steve Langasek 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 alte
Steve Langasek writes:
> Where would this ballot option rank vis-à-vis FD, for those TC members who
> are opposed to the "loose coupling" option?
> == dependencies rider version S (split-the-init) ==
>This decision is limited to selecting a default initsystem; we
>continue to welcome co
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...
Steve Langasek writes:
> And so I am greatly dismayed by the position Russ and Bdale have taken
> in this discussion with respect to packages being allowed to depend on a
> specific init system. Both have expressed the opinion that Debian
> should remain open to alternative init implementations
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,
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 d
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
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
Matthias Klumpp writes:
> Of course it does not exclude implementing that stuff in a different,
> non-systemd tool, but to my knowledge nobody has done that yet.
Exactly so. I have ideas on how this might work in a simpler and more
general fashion, but people rarely listen to ideas without also
2014-01-31 Keith Packard :
> Sergey B Kirpichev writes:
> [...]
>> Where is the list of problems for sysvinit we intend to solve?
>
> For X, the problem is running X as a user other than root, which should
> provide for increased system security as we'll be reducing the amount of
> root code subst
Sergey B Kirpichev writes:
> Are X-people indeed sacrifice portability, or there is something
> different (e.g. these dependencies are optional)?
Speaking as the X server release manager, the systemd patches exist
solely to provide for interoperation with systemd or other similar
device manageme
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 w
On Thu, Jan 30, 2014 at 6:38 PM, Sergey B Kirpichev
wrote:
> On Thu, Jan 30, 2014 at 05:30:04PM +0100, Matthias Klumpp wrote:
>> GNOME upstream won't really change
>
> Why? There are non-Linux GNOME users, for example. If the GNOME
> developers don't care even about such popular distribution as
On Thu, Jan 30, 2014 at 06:47:02PM +0100, Josselin Mouette wrote:
> Le jeudi 30 janvier 2014 à 21:38 +0400, Sergey B Kirpichev a écrit :
> > [Lots of crap]
Nice argumentation, as usual...
> > Where is the list of problems for sysvinit we intend to solve?
>
> https://wiki.debian.org/Debate/initsy
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 scenar
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 UNSUBSCRI
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
> motivat
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 s
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
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
2014-01-30 Thorsten Glaser :
> Matthias Klumpp dixit:
>
>>2014-01-30 ChaosEsque Team :
>>> [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
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 a
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
Matthias Klumpp dixit:
>2014-01-30 ChaosEsque Team :
>> [bullshit]
This was actually *not* bullshit. The delivery of most of the
content could use some polishing, but the content is a(n inconvenient)
truth.
>Wasn't there some kind of a ban applied here?
Apparently not, but it’s better that way
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
2014-01-30 ChaosEsque Team :
> [bullshit]
Wasn't there some kind of a ban applied here?
I am confused.
Cheers,
Matthias
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debi
>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 t
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,
Andrew Shadura writes:
> Josselin Mouette wrote:
>> Gnome-shell uses GDM for screen locking, and GDM heavily relies on
>> logind nowadays. There is fallback code that uses ConsoleKit, but it
>> has been untested for several major releases, and now fails even for
>> trivial things. Add to that th
On 30 January 2014 09:54, Andrew Shadura wrote:
> Hello,
>
> On Wed, 29 Jan 2014 19:17:29 +0100
> Josselin Mouette 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 se
On Wed, Jan 29, 2014 at 11:54:11PM +0100, Andrew Shadura wrote:
> On Wed, 29 Jan 2014 19:17:29 +0100
> Josselin Mouette 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 fo
Hello,
On Wed, 29 Jan 2014 19:17:29 +0100
Josselin Mouette wrote:
> Gnome-shell uses GDM for screen locking, and GDM heavily relies on
> logind nowadays. There is fallback code that uses ConsoleKit, but it
> has been untested for several major releases, and now fails even for
> trivial things. A
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”
Adrian Bunk writes:
> On Wed, Jan 29, 2014 at 11:27:53AM -0800, Russ Allbery wrote:
>> I'm still wondering if maybe there's just a communication failure here, so
>> let me try one more round.
>> My understanding of what Josselin is saying is that GNOME's ConsoleKit
>> support is effectively unma
On Wed, Jan 29, 2014 at 09:24:16PM +0100, Matthias Klumpp wrote:
> 2014-01-29 Adrian Bunk :
> > [...]
> > 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 functiona
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
2014-01-29 Adrian Bunk :
> [...]
> I do fully acknowledge that there are issues with ConsoleKit being
> unmaintained and many non-systemd codepath in GNOME being unmaintained
> and with GNOME missing some non-basic functionality without systemd.
>
> But claims that even basic functionality in GNOME
On Wed, Jan 29, 2014 at 11:27:53AM -0800, Russ Allbery wrote:
> Adrian Bunk 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 with
Adrian Bunk writes:
> On Wed, Jan 29, 2014 at 07:17:29PM +0100, Josselin Mouette wrote:
>> Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit :
>>> What *basic functionality* exactly is missing in GNOME 3.10 without
>>> logind?
>>> Note that I am not referring to bugs that are not y
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 functi
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
> >
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
> g
On Wed, Jan 29, 2014 at 06:41:11PM +0100, Josselin Mouette wrote:
> Le mercredi 29 janvier 2014 à 19:03 +0200, Adrian Bunk a écrit :
>...
> > Assuming jessie will support multiple init systems, why would GNOME need
> > a dependency on systemd?
>
> Because it needs logind.
> https://lists.debian.
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 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 ju
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 wrote:
> > > > Le mardi 28 janvier 2014 à 08:
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 wrote:
> > > Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
> > >> No. My question isn't about lo
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
> w
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 wrote:
> > > Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
> > >> No. My question isn't about logi
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 respec
On Tue, Jan 28, 2014 at 01:24:12PM +0100, Olav Vitters wrote:
> On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette 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 processe
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 th
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
le
On Tue, Jan 28, 2014 at 9:52 AM, Josselin Mouette wrote:
> Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
>> No. My question isn't about logind, but about using a user systemd
>> session to supervise processes started by the session. IIRC both GNOME
>> and KDE were mentioned to
Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit :
> Adrian Bunk 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.
Adrian Bunk 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
❦ 28 janvier 2014 07:23 CET, Adrian Bunk :
> You are forgetting the best technical solution, which is what
> gnome-session is actually implementing at the moment:
>
> session_tracking="systemd (with fallback to ConsoleKit)" [1]
Sure, the best technical solution is to rely on an unmaintained
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 o
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. No
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 outs
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 sp
Hi,
Ian Jackson 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
Ian Jackson writes:
> I hereby propose the following resolution:
>
>1. Support for sysvinit is mandatory in jessie.
>
>2. Debian intends to support multiple init systems, for the
> foreseeable future, and so long as their respective communities
> and code remain healthy. Noth
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
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 whate
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.
&
Ian Jackson writes:
> Russ Allbery writes:
>>>2. Debian intends to support multiple init systems, for the
>>> foreseeable future, and so long as their respective communities
>>> and code remain healthy. Nothing outside of an init system's
>>> implementation may require a sp
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 communi
Ian Jackson writes:
> I hereby propose the following resolution:
>1. Support for sysvinit is mandatory in jessie.
I agree with this in principle, but I think this loses quite a bit of
nuance and is likely, phrased in that way, to be used as a stick to beat
maintainers with in ways that aren
Russ Allbery writes ("Bug#727708: multiple init systems - formal resolution
proposal"):
> Ian Jackson writes:
> > I hereby propose the following resolution:
> >1. Support for sysvinit is mandatory in jessie.
>
> I agree with this in principle, but I think thi
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 respec
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
88 matches
Mail list logo
