Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Simon Richter
Hi, the main problem I see with this GR is that it is in essence a rehash of the GR[1] we had in 2014, with pretty much the same options minus the one that won, "A GR is not required." > Choice 1: Affirm Init Diversity The way this is worded is even stronger than in the 2014 GR, which made allow

Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Andrey Rahmatullin
On Sat, Nov 09, 2019 at 06:08:54PM +0100, Simon Richter wrote: > the main problem I see with this GR is that it is in essence a rehash of > the GR[1] we had in 2014, with pretty much the same options minus the one > that won, "A GR is not required." The option that won is worded like this: """ The

Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Russ Allbery
Simon Richter writes: > the main problem I see with this GR is that it is in essence a rehash of > the GR[1] we had in 2014, with pretty much the same options minus the > one that won, "A GR is not required." I voted that option in 2014 and definitely will not be voting that option today, for th

Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Holger Levsen
On Sat, Nov 09, 2019 at 06:08:54PM +0100, Simon Richter wrote: > (Option 1.1.1) > > Automated variant transitions shall be supported. > > [Rationale: moving from systemd to sysvinit is currently an involved manual > process, so unavailable to anyone not already skilled in Unix > administration, c

Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Wouter Verhelst
Hi Martin, On Sat, Nov 09, 2019 at 01:37:13PM +0100, Martin Pitt wrote: > Hello Wouter, > > Wouter Verhelst [2019-11-09 10:32 +0200]: > > > Choice 1: Affirm Init Diversity > > > > > > Being able to run Debian systems with init systems other than systemd > > > continues to be something that the p

Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Simon Richter
Hi, On Sat, Nov 09, 2019 at 10:01:27AM -0800, Russ Allbery wrote: > > (Option 1) > > The Debian Project aims at providing the greatest configuration flexibility > > while maintaining a sensible default installation for end users. To that > > end, we document functional dependencies in a machine-

Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Mike Gabriel
On Sa 09 Nov 2019 19:09:35 CET, Holger Levsen wrote: On Sat, Nov 09, 2019 at 06:08:54PM +0100, Simon Richter wrote: (Option 1.1.1) Automated variant transitions shall be supported. [Rationale: moving from systemd to sysvinit is currently an involved manual process, so unavailable to anyone n

Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Mike Gabriel
Hi, On Do 07 Nov 2019 19:59:49 CET, Sam Hartman wrote: No, the difference intended between choice 2 and 3 is about how we handle technologies like elogind, or a mythical technology that parsed sysusers files, rather than how we handle starting daemons. I'd suggest leaving elogind entirely ou

Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Simon Richter
Hi Holger, On Sat, Nov 09, 2019 at 06:09:35PM +, Holger Levsen wrote: > > [Rationale: moving from systemd to sysvinit is currently an involved manual > > process, so unavailable to anyone not already skilled in Unix > > administration, creating an artificial barrier.] > please clarify what y

Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Simon Richter
Hi Mike, On Sat, Nov 09, 2019 at 09:48:03PM +, Mike Gabriel wrote: > root@minobo:~# apt-rdepends -r systemd | wc -l > 6598 It's not as bad as you think: the important package is systemd-sysv. In buster: $ apt-cache rdepends systemd-sysv In bullseye: systemd-sysv Reverse Depends: system

Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Matthias Klumpp
Am Sa., 9. Nov. 2019 um 23:01 Uhr schrieb Mike Gabriel : > [...] > Isn't as side-question that is on the table with this GR: what about > the future of non-Linux variants of Debian. If systemd becomes _the_ > init system of focus in Debian (by vote, not only de facto), kFreeBSD > and Hurd will cert

Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Bernd Zeimetz
On 11/9/19 11:24 PM, Simon Richter wrote: > Yes, that would be my desired outcome: an affirmation that Debian wants to > be "universal". This has been our greatest strength for years. Its a strength that wasted an enormous amount of ressources. See kfreebsd (which was actually really nice!) a

Re: ***UNCHECKED*** Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Simon Richter
Hi, On Sun, Nov 10, 2019 at 12:19:24AM +0100, Bernd Zeimetz wrote: > > Yes, that would be my desired outcome: an affirmation that Debian wants to > > be "universal". This has been our greatest strength for years. > Its a strength that wasted an enormous amount of ressources. See > kfreebsd (whi

Re: Init Systems GR Timeline

2019-11-09 Thread Holger Levsen
On Fri, Nov 08, 2019 at 06:46:53PM -0500, Sam Hartman wrote: > I think you may be mishearing what I'm proposing for a timeline. [...] thanks for clarifying, Sam, much appreciated. -- cheers, Holger ---

Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Wouter Verhelst
On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote: > > This is a draft GR. I hope to be at a point where I could formally > propose a GR in a week, assuming discussion converges that fast. You can formally propose a GR today, and I recommend you do -- otherwise we end up discussing thi

Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Martin Pitt
Hello all, Sam Hartman [2019-11-07 13:04 -0500]: > I hope my actions demonstrate that I've tried to work with and understand the > needs of all sides here; that has been my intent. Many thanks! (Again, in public now :-) ) Full disclosure: I discussed that with Sam in private before, as represent

Re: [draft] Draft text on Init Systems GR

2019-11-09 Thread Martin Pitt
Hello Wouter, Wouter Verhelst [2019-11-09 10:32 +0200]: > > Choice 1: Affirm Init Diversity > > > > Being able to run Debian systems with init systems other than systemd > > continues to be something that the project values. With one > > exception, the Debian Project affirms the current policy o