Re: Re-Proposal - preserve freedom of choice of init systems
I vote about freedom of choice init system -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546a5db2.9070...@lucylaika.ovh
Re: Re-Proposal - preserve freedom of choice of init systems
goli...@riseup.net wrote: I came to Linux for FREEDOM and for configurability. Finally, I could http://islinuxaboutchoice.com/ Thank you for your contribute. Next! -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3e287$oq9$1...@posted-at.bofh.it
Re: Re: Re-Proposal - preserve freedom of choice of init systems
m...@linux.it wrote: goli...@riseup.net wrote: I came to Linux for FREEDOM and for configurability. Finally, I could http://islinuxaboutchoice.com/ Thank you for your contribute. Next! It might be your opinion that GNU/Linux is not about choice, but it is often said and the reason why many people use it. Besides that one can choose between different solutions for quite a lot of problems (GUI's, editors, compilers, etc). Else update-alternatives wouldn't make any sense at all. I assume you are aware of that. No need for that sharp an answer. I couldn't say it any better: http://blowingupbits.com/2014/11/thoughts-systemd-freedom-choose/ and especially: If Debian’s leadership is even half awake at the helm they will realize just how many new users they can gain if they continue to offer freedom of choice where init is concerned It will work the other way around too, of course. signature.asc Description: PGP signature
Re: Re-Proposal - preserve freedom of choice of init systems
Seconded I completely back the idea to avoid a fork when ever possible. It's possible to maintain systemd and just let it to do the init stuff. Syslog and other daemons can be implemented independently, as for example in a classic Unix way. SuSE Linux Enterprise 12 has gone this way just now. Please, Debian folks, consider it! It's worth the struggle. Thanks for your efforts! -- André Kiepe Systems Engineer Training Consultant
Re: Re-Proposal - preserve freedom of choice of init systems
I agree with the proposal.
Calling for the vote (Re: Re-Proposal - preserve freedom of choice of init systems)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ian Jackson writes (Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)): For the avoidance of any doubt, I currently intend to not accept any further amendments. That means that the minimum discussion period will not be extended any further (unless the DPL intervenes). I currently intend to call for a vote when the minimum discussion period elapses, 2 weeks from now. That was at `Date: Sun, 19 Oct 2014 14:59:16 +0100'. $ date -d 'Sun, 19 Oct 2014 14:59:16 +0100 +14 days' Sun Nov 2 13:59:16 GMT 2014 $ So by my calculations the minimum discussion period (which has not been varied by the Project Leader) expired about half an hour ago. I hereby call for a vote on my proposal and all related amendments (Constitution A.2(2)). NB: Only Debian Developers are able to vote, and in any case no-one can vote by replying to this message. This message of mine is a request to the Project Secretary to organise and conduct a vote; the Secretary will then send out a Call for Votes, in response to which Debian Developers can vote. So please don't reply to this message with `votes'. Ian. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUVkDYAAoJEOPjOSNItQ05n8IIAIjg0+bI2i02hJwiUFJQwI2I mkibJ3Lh15Bx1/iSL5sh5x8eXwipVx4XTXgMhQ7XZWosllcs6Lm8RDDjsEg8bIiT 9JWymKeKjooc1A+ZtZJ6/q/mDo0pjKkr0wZOOYu++htRavdlEQe2Thbb2EoZpzWZ pHBSAxz6LuSUEiOc2cs4W2H4rCLCizaNQpFM3l0EIrsm6yRC9OWANfFA3djxDSdA hsL1HCDEogJu2mtqfuRUqLi0rXyhzVtVRkx+CqMbrobGj7sAxibm/kytWQgCnmnC Wcak/z+5LF+zXvGAScfiirkQ/vkTluY/lP8czCYh/F2ybS7+AzH2KNuCMg2MY04= =Cy9v -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21590.16645.519816.91...@chiark.greenend.org.uk
Re: Calling for the vote (Re: Re-Proposal - preserve freedom of choice of init systems)
Hi, Ian Jackson ijack...@chiark.greenend.org.uk writes: Ian Jackson writes (Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)): For the avoidance of any doubt, I currently intend to not accept any further amendments. That means that the minimum discussion period will not be extended any further (unless the DPL intervenes). I currently intend to call for a vote when the minimum discussion period elapses, 2 weeks from now. That was at `Date: Sun, 19 Oct 2014 14:59:16 +0100'. $ date -d 'Sun, 19 Oct 2014 14:59:16 +0100 +14 days' Sun Nov 2 13:59:16 GMT 2014 $ So by my calculations the minimum discussion period (which has not been varied by the Project Leader) expired about half an hour ago. There was a later change to an amendment[1]. As this was done under A.1.5 and not under A.1.6 this does reset the discussion period as far as I understand. The earliest Call for Votes would thus be possible on Wed, 22 Oct 2014 07:45:39 +0900 + 2 weeks, that is in about two more days. Ansgar [1] https://lists.debian.org/debian-vote/2014/10/msg00296.html -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oaspfm7b@deep-thought.43-1.org
Re: Calling for the vote (Re: Re-Proposal - preserve freedom of choice of init systems)
On Sun, Nov 02, 2014 at 02:34:45PM +, Ian Jackson wrote: Ian Jackson writes (Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)): For the avoidance of any doubt, I currently intend to not accept any further amendments. That means that the minimum discussion period will not be extended any further (unless the DPL intervenes). I currently intend to call for a vote when the minimum discussion period elapses, 2 weeks from now. That was at `Date: Sun, 19 Oct 2014 14:59:16 +0100'. $ date -d 'Sun, 19 Oct 2014 14:59:16 +0100 +14 days' Sun Nov 2 13:59:16 GMT 2014 $ As far as I know, amendment C was at least 1 day later, according to the vote page, but I haven't been keeping track of things. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141102213128.ga20...@roeckx.be
Re: Calling for the vote (Re: Re-Proposal - preserve freedom of choice of init systems)
Kurt Roeckx writes (Re: Calling for the vote (Re: Re-Proposal - preserve freedom of choice of init systems)): On Sun, Nov 02, 2014 at 02:34:45PM +, Ian Jackson wrote: That was at `Date: Sun, 19 Oct 2014 14:59:16 +0100'. $ date -d 'Sun, 19 Oct 2014 14:59:16 +0100 +14 days' Sun Nov 2 13:59:16 GMT 2014 $ As far as I know, amendment C was at least 1 day later, according to the vote page, but I haven't been keeping track of things. I did not accept amendment C. Therefore it does not reset the clock. Constitution A.2(4): 4. The minimum discussion period is counted from the time the last formal amendment was accepted, or since the whole resolution was proposed if no amendments have been proposed and accepted. Here, `accepted' refers to Constitution A.1(2): 2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match. The last (and only) formal amendment I accepted was my own, on Sunday the 19th. As I wrote there: For the avoidance of any doubt, I currently intend to not accept any further amendments. That means that the minimum discussion period will not be extended any further (unless the DPL intervenes). I currently intend to call for a vote when the minimum discussion period elapses, 2 weeks from now. Neil replied to that email with `Received and valid' and neither you nor he contradicted my comments about the discussion period. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21590.46924.415612.840...@chiark.greenend.org.uk
Re: Calling for the vote (Re: Re-Proposal - preserve freedom of choice of init systems)
On Sun, Nov 02, 2014 at 10:59:24PM +, Ian Jackson wrote: Kurt Roeckx writes (Re: Calling for the vote (Re: Re-Proposal - preserve freedom of choice of init systems)): On Sun, Nov 02, 2014 at 02:34:45PM +, Ian Jackson wrote: That was at `Date: Sun, 19 Oct 2014 14:59:16 +0100'. $ date -d 'Sun, 19 Oct 2014 14:59:16 +0100 +14 days' Sun Nov 2 13:59:16 GMT 2014 $ As far as I know, amendment C was at least 1 day later, according to the vote page, but I haven't been keeping track of things. I did not accept amendment C. Therefore it does not reset the clock. Ian's interpretation seems correct and straightforward to me. (Every so often I do think the secretary's role in managing votes should be replaced by a moderately large shell script, so decisions like these are a matter of coded constraints rather than ad hoc interpretation...) Cheers, aj -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141102231328.ga18...@master.debian.org
Re: Calling for the vote (Re: Re-Proposal - preserve freedom of choice of init systems)
On Sun, Nov 02, 2014 at 10:59:24PM +, Ian Jackson wrote: Kurt Roeckx writes (Re: Calling for the vote (Re: Re-Proposal - preserve freedom of choice of init systems)): On Sun, Nov 02, 2014 at 02:34:45PM +, Ian Jackson wrote: That was at `Date: Sun, 19 Oct 2014 14:59:16 +0100'. $ date -d 'Sun, 19 Oct 2014 14:59:16 +0100 +14 days' Sun Nov 2 13:59:16 GMT 2014 $ As far as I know, amendment C was at least 1 day later, according to the vote page, but I haven't been keeping track of things. I did not accept amendment C. Therefore it does not reset the clock. Constitution A.2(4): 4. The minimum discussion period is counted from the time the last formal amendment was accepted, or since the whole resolution was proposed if no amendments have been proposed and accepted. Here, `accepted' refers to Constitution A.1(2): 2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match. The last (and only) formal amendment I accepted was my own, on Sunday the 19th. It looks like you're right. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141102232018.ga23...@roeckx.be
Re: Calling for the vote (Re: Re-Proposal - preserve freedom of choice of init systems)
Kurt Roeckx writes (Re: Calling for the vote (Re: Re-Proposal - preserve freedom of choice of init systems)): On Sun, Nov 02, 2014 at 10:59:24PM +, Ian Jackson wrote: The last (and only) formal amendment I accepted was my own, on Sunday the 19th. It looks like you're right. Great, thanks. I'll look forward to the CFV. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21590.48494.851615.601...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
On 23 October 2014 18:28, Vittorio Beggi (Gmail) vittorio.be...@gmail.com wrote: Ian Jackson's proposal to preserve freedom of choice of init systems. I definitely agree with the proposal. -- Vittorio Beggi Me too. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJSM8J2qYiSt7+T=6X8bfH5J0-QGnBS906_Q33wP=jcsgvx...@mail.gmail.com
Re: Re: Re-Proposal - preserve freedom of choice of init systems
(unfortunately this mail will probably not result in the correct thread order. Don't know if the cause is my MUA evolution, or the web interface of the debian-vote list archives) On 2014-10-17 09:35, Hörmetjan Yiltiz wrote: Users still cannot vote? No. Hello, It is well known that the users are second class citizens with respect to Debian. The same applies to many upstream developers, they develop software mainly for themselves, not the users, see for example the latest development of Gnome. The only way to change this is by creating a large enough user group taking side by refusing to use software that is going in the wrong direction and promote alternatives. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1414058134.15088.112.ca...@g3620.my.own.domain
Re: Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, Oct 23, 2014 at 11:55:34AM +0200, Svante Signell wrote: The same applies to many upstream developers, they develop software mainly for themselves, not the users, see for example the latest development of Gnome. The only way to change this is by creating a large enough user group taking side by refusing to use software that is going in the wrong direction and promote alternatives. This is not a I don't like the GNOME developers mailing list. Going in the wrong direction: opinion, not fact. Obviously you can use something other than GNOME, I'd appreciate not generalizing the hundreds people who contribute to GNOME. Similarly, turning not being able to vote into Debian doesn't care for it's users: You're free to make your case. Convince others. That'll probably be appreciated way more than negativity. -- Regards, Olav -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141023123823.ga7...@bkor.dhs.org
Re: Re-Proposal - preserve freedom of choice of init systems
On Thursday 23 October 2014 06:08 PM, Olav Vitters wrote: On Thu, Oct 23, 2014 at 11:55:34AM +0200, Svante Signell wrote: The same applies to many upstream developers, they develop software mainly for themselves, not the users, see for example the latest development of Gnome. The only way to change this is by creating a large enough user group taking side by refusing to use software that is going in the wrong direction and promote alternatives. This is not a I don't like the GNOME developers mailing list. Going in the wrong direction: opinion, not fact. Obviously you can use something other than GNOME, I'd appreciate not generalizing the hundreds people who contribute to GNOME. Similarly, turning not being able to vote into Debian doesn't care for it's users: You're free to make your case. Convince others. That'll probably be appreciated way more than negativity. What was wrong with Svante's post ? He was just giving an example, quoting Gnome. I'd give a similar example for KDE. We believe Debian is more than just a Desktop. And for Desktop too, more than just Gnome _or_ KDE. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: OpenPGP digital signature
Re: Re: Re-Proposal - preserve freedom of choice of init systems
Hi, Svante, I fear your wonderfully terse phrasing may cause some people to react more negatively to what you said than you perhaps intended. Please forgive me for the boldness of suggsting alternate phrasings below, in the hope of clarifying things for everyone. Svante Signell: It is well known that the users are second class citizens with respect to Debian. I suggest, instead: It is well known that in Debian, most of the time, those who do the work get to make the decisions. Since almost all work in Debian is done by volunteers in their free time, it would indeed be strange to require that other people could dictate what they do. It would not be fun for long to be a Debian contributor, if any random person on the Internet could order them to do something, at the random person's whim, on pain of insults and harrassment. Users are very important to Debian developers, and it even says so in the social contract the Debian project has published. Its users can have a big impact on how Debian gets developed in the future, when they join development discussions to explain their use cases, needs, and individual situations, and engage the project in a constructive way. Despite this, Debian quite sensibly sticks to the principle of those who do, decide and only counts votes for those who've contributed enough to become formal members of the project. That's a bit longer, and not nearly as pithy, but I hope it conveys your intention better. The same applies to many upstream developers, they develop software mainly for themselves, not the users, see for example the latest development of Gnome. The only way to change this is by creating a large enough user group taking side by refusing to use software that is going in the wrong direction and promote alternatives. I would phrase this like this, instead: The same thing applies to everyone who works on free software in their free time: they'll work on what they want to work on, and if that is to a random person's liking and benefit, that's a very lucky random person. Most developers do listen to their users, and even random passers-by with an opinion, but they don't let them decide things. However, the developers get a big ego boost from making something that people like. A similar thing applies to those who get paid to work on free software: they work on things their employer wants them to work on, and perhaps make decisions that benefit their employer more than a random person. This tends to mean they keep getting paid. One can imagine a hypothetical situation where random people show up and demand and insist that they get to decide on what developers work on, what they do, how they do it, etc. These people might even be long-time users of the software, who feel they such a long history with the software, they're entitled to some decision making power. To make the situation even more ridiculous, the random people could use really inflammatory language, such as substituting wrong for I don't like. This situation would be really stressful and depressing for the developers, and one would wonder why they would put up with it. It would be much easier for them to just quit and go demand other people do what they want. It's a good thing that's a hypothetical situation, and not reality. Free software would die if it were reality. Again, this is a bit long, but sometimes clarity overweights brevity. If I've managed to misunderstand, or misrepresent, what you meant, Svante, please forgive me, and post a explanation to correct me. -- http://gtdfh.branchable.com/ -- GTD for hackers http://obnam.org/ -- HAVE YOU BACKED UP TODAY? -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141023155900.gd4...@exolobe1.liw.fi
Re: Re-Proposal - preserve freedom of choice of init systems
Ian Jackson's proposal to preserve freedom of choice of init systems https://lists.debian.org/debian-vote/2014/10/msg1.html. I definitely agree with the proposal. -- Vittorio Beggi PHX di Beggi Vittorio via Cirenaica, 6 35141 Padova PD Tel/Fax: 049 8756276 Mobile: 340 4871253 mailto: vittorio.be...@gmail.com www.prontosoccorsopc.biz
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, Oct 23, 2014 at 08:38:36PM +0530, Ritesh Raj Sarraf wrote: On Thursday 23 October 2014 06:08 PM, Olav Vitters wrote: On Thu, Oct 23, 2014 at 11:55:34AM +0200, Svante Signell wrote: The same applies to many upstream developers, they develop software mainly for themselves, not the users, see for example the latest development of Gnome. The only way to change this is by creating a large enough user group taking side by refusing to use software that is going in the wrong direction and promote alternatives. This is not a I don't like the GNOME developers mailing list. Going in the wrong direction: opinion, not fact. Obviously you can use something other than GNOME, I'd appreciate not generalizing the hundreds people who contribute to GNOME. Similarly, turning not being able to vote into Debian doesn't care for it's users: You're free to make your case. Convince others. That'll probably be appreciated way more than negativity. What was wrong with Svante's post ? He was just giving an example, quoting Gnome. I'd give a similar example for KDE. Users aren't second class citizens in GNOME. Contributors have more influence. Read e.g. https://en.wikipedia.org/wiki/Second-class_citizen are often subject to mistreatment or neglect at the hands of their putative superiors If that wasn't the intention, ok, but that is what was written and I assumed it the writer knew the meaning. -- Regards, Olav -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141023212200.gc32...@bkor.dhs.org
Re: Re-Proposal - preserve freedom of choice of init systems
Hi Neil, I realized that myself afterwards, please forgive my ignorance. Indeed, I'm not a registered Debian developer, so my vote cannot be accepted. Sergey On 22 October 2014 13:39, Neil McGovern n...@halon.org.uk wrote: Hi Sergey, On Tue, Oct 21, 2014 at 04:38:49PM +0300, Sergey Vlasov wrote: Seconded. I say no to systemd dependency. I want to be able to choose myself what init system to use in my Debian setup. This mail isn't signed, nor do I seem to be able to find you in db.debian.org. Unfortunately, only Debian Developers may sponsor resolutions in this way. Neil -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabtsbto1zb+iqj0dfr4err_gujjlhno2lygnwbmsswc1g6n...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
Hi Sergey, On Tue, Oct 21, 2014 at 04:38:49PM +0300, Sergey Vlasov wrote: Seconded. I say no to systemd dependency. I want to be able to choose myself what init system to use in my Debian setup. This mail isn't signed, nor do I seem to be able to find you in db.debian.org. Unfortunately, only Debian Developers may sponsor resolutions in this way. Neil -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141022103926.gq18...@halon.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
Joey Hess writes (Re: Re-Proposal - preserve freedom of choice of init systems): Ian Jackson wrote: The technical committee decided not to decide about the question of coupling i.e. whether other packages in Debian may depend on a particular init system. What, then was #746715? It was non-binding advice asking maintainers to accept reasonable patches. IMO it does not answer the question addressed by my GR. This resolution is a Position Statement about Issues of the Day (Constitution 4.1.5), triggering the General Resolution override clause in the TC's resolution of the 11th of February. How can you use 4.1.5, which is Issue, supersede and withdraw **nontechnical** policy documents and statements (emphasis mine) for a technical decision like this? Why does this not come under 4.1.4, and so require a 2:1 majority? I think that this coupling question is actually mostly a political rather than a technical problem. The TC explicitly decided to allow their init system decision to be amended or supplemented by a 1:1 GR and it would be wrong to subvert that. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21574.15584.843492.552...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
Hi, On 16.10.2014 17:05, Ian Jackson wrote: I wish to propose the following general resolution, and hereby call for seconds. [...] ** Begin Proposal ** 0. Rationale 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 Debian may depend on a particular init system. This GR seeks to preserve the freedom of our users now to select an init system of their choice, and the project's freedom to select a different init system in the future. It will avoid Debian becoming accidentally locked in to a particular init system (for example, because so much unrelated software has ended up depending on a particular init system that the burden of effort required to change init system becomes too great). A number of init systems exist, and it is clear that there is not yet broad consensus as to what the best init system might look like. This GR does not make any comment on the relative merits of different init systems; the technical committee has decided upon the default init system for Linux for jessie. 1. Exercise of the TC's power to set policy For jessie and later releases, the TC's power to set technical policy (Constitution 6.1.1) is exercised as follows: 2. Loose coupling of init systems 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 * special-use packages such as managers for init systems * cooperating groups of packages intended for use with specific init systems provided that these are not themselves required by other software whose main purpose is not the operation of a specific init system. Degraded operation with some init systems is tolerable, so long as the degradation is no worse than what the Debian project would consider a tolerable (non-RC) bug even if it were affecting all users. So the lack of support for a particular init system does not excuse a bug nor reduce its severity; but conversely, nor is a bug more serious simply because it is an incompatibility of some software with some init system(s). Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems. 3. Notes and rubric This resolution is a Position Statement about Issues of the Day (Constitution 4.1.5), triggering the General Resolution override clause in the TC's resolution of the 11th of February. The TC's decision on the default init system for Linux in jessie stands undisturbed. However, the TC resolution is altered to add the additional text in sections (1) and (2) above. ** End Proposal ** Seconded. I say no to systemd dependency. I want to be able to choose myself what init system to use in my Debian setup. Regads, Sergey -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabtsbtp+bxpxwf8o23r1hxdftbsu_kvhhah5m2_rkdznquq...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
-- L.S.C.A. Francisco González Flores Redes y Comunicaciones CDE PRI Chihuahua
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, 2014-10-16 at 16:05 +0100, Ian Jackson wrote: I wish to propose the following general resolution, and hereby call for seconds. This GR resolution proposal is identical to that proposed by Matthew Vernon in March: https://lists.debian.org/debian-vote/2014/03/msg0.html and the substantive text is that which was drafted for the purposes of the technical committee's vote (where they decided not to pass a resolution on the subject). IMO developments since March show that the concerns put forward then were well-founded. Following discussions elsewhere including -devel I have received enough offers of seconds by private email. As Matthew said, I don't think further lengthy discussion of the issues is likely to be productive, and therefore hope we can bring this swiftly to a vote. This is particularly true given the impact on the jessie release. Thanks, Ian. ** Begin Proposal ** 0. Rationale 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 Debian may depend on a particular init system. This GR seeks to preserve the freedom of our users now to select an init system of their choice, and the project's freedom to select a different init system in the future. It will avoid Debian becoming accidentally locked in to a particular init system (for example, because so much unrelated software has ended up depending on a particular init system that the burden of effort required to change init system becomes too great). A number of init systems exist, and it is clear that there is not yet broad consensus as to what the best init system might look like. This GR does not make any comment on the relative merits of different init systems; the technical committee has decided upon the default init system for Linux for jessie. 1. Exercise of the TC's power to set policy For jessie and later releases, the TC's power to set technical policy (Constitution 6.1.1) is exercised as follows: 2. Loose coupling of init systems 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 * special-use packages such as managers for init systems * cooperating groups of packages intended for use with specific init systems provided that these are not themselves required by other software whose main purpose is not the operation of a specific init system. Degraded operation with some init systems is tolerable, so long as the degradation is no worse than what the Debian project would consider a tolerable (non-RC) bug even if it were affecting all users. So the lack of support for a particular init system does not excuse a bug nor reduce its severity; but conversely, nor is a bug more serious simply because it is an incompatibility of some software with some init system(s). Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems. 3. Notes and rubric This resolution is a Position Statement about Issues of the Day (Constitution 4.1.5), triggering the General Resolution override clause in the TC's resolution of the 11th of February. The TC's decision on the default init system for Linux in jessie stands undisturbed. However, the TC resolution is altered to add the additional text in sections (1) and (2) above. ** End Proposal ** -- Seconded. signature.asc Description: This is a digitally signed message part
Re: Re-Proposal - preserve freedom of choice of init systems
Andy, Thank you for the email. You can currently use Debian without systemd as long as no package you use depends on systemd. That depends on systemd hook is a primary objection for those of us who know better. Why should a non-init package depend on a particular init system? Only systemd initialization-related packages should depend on systemd. Non-systemd packages currently depend on systemd due to the direct efforts of systemd supporters. Lennart Poettering himself is pushing to get packages dependent on systemd: https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html The reason why Mr. Pottering resorts to such tactics is because: 1. locking packages upstream FORCES the use of systemd by anyone wanting to use that package; 2. systemd would surely fall flat on its face, were it to attempt to advance on merit alone. Sorry, but such unscrupulous manipulation has to stop before things get out of hand. I want to install that unnecessarily systemd-dependent package on my non-systemd machine! systemd is not Essential level of priority in Debian. Debian's major (and contentious) switch to systemd indicates otherwise. There are no plans by Debian to change that fact. See http://www.vitavonni.de/blog/201410/2014102101-avoiding-systemd.html for example. Thank you for the link. I love this line from the page: ***However, notice that there are some programs such as login managers (e.g. gdm3) which have an upstream dependency on systemd. gdm3 links against libsystemd0 and depends on libpam-systemd; and the latter depends on systemd-sysv | systemd-shim SO IT IS IN FACT A SOFTWARE SUCH AS GNOME THAT IS PULLING SYSTEMD ONTO YOUR COMPUTER.*** However, the above linked post from Lennart Poettering proves that it was he who initiated Gnome's dependency on systemd. So, on the one hand, the systemd apologists are implying that it is not systemd's fault that upstream software depends on it, while, on the other hand, the systemd supporters are pushing for such upstream dependencies on systemd. That's a slimy, two-faced approach. Those of us not who are not sold on systemd can only assume that the amount of effort that the systemd camp puts into such connivances is inversely related to the amount of effort that they put into proper coding. Also, given the prevalence of such deception above, how can we trust anything that comes from the systemd supporters (including systemd itself)? In regards to steps that your linked page suggests, anything can be hacked (except, perhaps, a non-systemd package's dependency on systemd/pid 1). I can run Debian packages on Slackware, Gentoo, Arch, etc. However, I and many, many others don't want to bother with such rigmarole. I'll tell you what -- why don't we go back SysV init as the Debian default, and then, the systemd users can take steps such as those proposed on your linked site. Don't like that proposal, do you? You be the one to have to do extra work to set-up and maintain your init system. Furthermore, you would probably lose those precious upstream dependencies on systemd, as the upstream developers would have to remove them, given that the major players (Red Hat/Arch, Debian, Slackware, etc.) are using various init systems. And again, if I were to follow the instructions on your linked page, how do I run that systemd-dependent package on my non-systemd machine? Regards, -DM Hello, On Mon, Oct 20, 2014 at 06:55:42AM -0700, ss-compo...@marks.org wrote: In fleeing systemd, I have left Debian and am currently running Slackware. I won't use Debian again, unless I can do so without systemd. You can currently use Debian without systemd as long as no package you use depends on systemd. systemd is not Essential level of priority in Debian. There are no plans by Debian to change that fact. See http://www.vitavonni.de/blog/201410/2014102101-avoiding-systemd.html for example. Spreading the idea that Debian is forcing you to use systemd is spreading falsehoods. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021134644.036e3...@darkstar.example.net
Re: Re-Proposal - preserve freedom of choice of init systems
Hi debian-vote, The below poster redirected their response to my off-list mail back to the list. I explicitly mailed them off-list and with a reply-to of only myself set in order to avoid further list noise, and because they seemed like they were genuinely confused. I now see that they had an agenda and that there's nothing I can say to alter it, so I'll leave it there. I am sorry that this got back onto the list. Cheers, Andy On Tue, Oct 21, 2014 at 01:46:44PM -0700, ss-compo...@marks.org wrote: Andy, Thank you for the email. You can currently use Debian without systemd as long as no package you use depends on systemd. That depends on systemd hook is a primary objection for those of us who know better. Why should a non-init package depend on a particular init system? etc. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021211606.gf27...@bitfolk.com
Re: Re: Re-Proposal - preserve freedom of choice of init systems
On Sat, Oct 18, 2014 at 03:26:57AM +0100, Jonathan de Boyne Pollard wrote: Perhaps if you picked something other than runit you'd make your point more effectively. Try using the case of someone who makes a tool that depends from System V init running as process #1. It is hardly farfetched. I've seen at least two people publicly point out in the past several months that they had something set up in /etc/inittab that broke when they switched to an alternative bootstrap system. (A lot of people conflate init with rc. It's not System V init that other bootstrap systems sometimes provide shims and compatibility mechanisms for. It's System V rc, more specifically the /etc/rc?.d/* scripts that it runs.) There's also a Debian bug or two. So the question that you should be asking to make your point is probably this: The resolution says that In general, software may not require a specific init system to be pid 1.. Does this mean that softwares that make use of /etc/inittab, which is peculiar to (in Ian Jackson's own words) a specific init system (its contents, outwith sometimes the run level line, being not processed at all by any of upstart, systemd, runit-init, s6-svscan, the nosh system or service managers, minit, jinit, or finit), are unfit for inclusion in Debian according to Ian Jackson's resolution? Yes, they almost certainly would be unfit for inclusion. Which is actually the status quo today, as inittab is a non-conffile config file with no management interface to permit additional packages to hook into it - making it a policy violation for other packages to edit this file. So I believe the requirements here are symmetric, and there's certainly no reason to think that the requirements are onerous because it would forbid integrating with /etc/inittab. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)
Alessio Treglia writes (Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)): Il giorno dom, 19/10/2014 alle 14.59 +0100, Ian Jackson ha scritto: I hereby formally propose the amendment below (Constitution A.1(1) `directly by proposer'), and, then, immediately accept it (A.1(2)). This resets the minimum discussion period (A.2(4)). ... Seconded. Thanks, but the proposer of a GR does not need seconds for their own amendments. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21572.59918.752013.219...@chiark.greenend.org.uk
Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)
On Mon, Oct 20, 2014 at 11:55 AM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Alessio Treglia writes (Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)): Il giorno dom, 19/10/2014 alle 14.59 +0100, Ian Jackson ha scritto: I hereby formally propose the amendment below (Constitution A.1(1) `directly by proposer'), and, then, immediately accept it (A.1(2)). This resets the minimum discussion period (A.2(4)). ... Seconded. Just noticed that after reviewing the GR procedure once again. Honestly it was not really clear to me. Sorry about that. Thanks. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAMHuwozC8h=h01-omtniwb2mgudake7iooqzpa+2ucrey82...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
Ian Jackson wrote: The technical committee decided not to decide about the question of coupling i.e. whether other packages in Debian may depend on a particular init system. What, then was #746715? This resolution is a Position Statement about Issues of the Day (Constitution 4.1.5), triggering the General Resolution override clause in the TC's resolution of the 11th of February. How can you use 4.1.5, which is Issue, supersede and withdraw **nontechnical** policy documents and statements (emphasis mine) for a technical decision like this? Why does this not come under 4.1.4, and so require a 2:1 majority? -- see shy jo signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
I wholeheartedly support this proposal. I would go further in this proposal and state that no software should require a specific init system in ANY pid. Of course, like many others, I would prefer Debian's default init to be almost anything other than systemd. In fleeing systemd, I have left Debian and am currently running Slackware. I won't use Debian again, unless I can do so without systemd. Kind regards, -D.M. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141020065542.543a9...@darkstar.example.net
Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)
On Sun, Oct 19, 2014 at 02:59:16PM +0100, Ian Jackson wrote: (CC secretary@ to avoid this getting overlooked in the mail flood.) I hereby formally propose the amendment below (Constitution A.1(1) `directly by proposer'), and, then, immediately accept it (A.1(2)). This resets the minimum discussion period (A.2(4)). Received and valid Neil -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141020181427.gi18...@halon.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
Hi, Not sure if I am able to vote on the issue; however, having been a Debian user for two years and a Linux user for nearly six years and having used a number of different distros in my time. I would like to vote in favour of keeping the traditional freedom of choice for init systems in line with Ian's proposal. Regards, John James Managing Director Broken Pixel Limited www.broken-pixel.co.uk Companies House Number 8872682
Re: Re-Proposal - preserve freedom of choice of init systems
Le dim. 19 oct. 2014 à 10:54, John James johnja...@broken-pixel.co.uk a écrit : Hi, Hi John, Not sure if I am able to vote on the issue; however, having been a Debian user for two years and a Linux user for nearly six years and having used a number of different distros in my time. I would like to vote in favour of keeping the traditional freedom of choice for init systems in line with Ian's proposal. Please see https://lists.debian.org/debian-vote/2014/10/msg00147.html Regards, Cheers, Vincent John James Managing Director Broken Pixel Limited www.broken-pixel.co.uk Companies House Number 8872682 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1413717689.2928...@smtp.free.fr
Re: Re-Proposal - preserve freedom of choice of init systems
Ansgar Burchardt writes (Re: Re-Proposal - preserve freedom of choice of init systems): Ian Jackson writes: 2. Loose coupling of init systems In general, software may not require a specific init system to be pid 1. The exceptions to this are as follows: Could you change the formulation here? Several people seem to understand this as must work with *all* init systems; however as far as I understood from earlier discussions you only want to forbid depending on *one* specific init system, that is dependencies like init-A | init-B would still be allowed. I think the language is already clear. But I will change `a' to `one', so we have `In general, software may not require one specific init system' I don't want to further delay matters by making a bigger change which I think would require consultation. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21571.48767.326728.991...@chiark.greenend.org.uk
Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 (CC secretary@ to avoid this getting overlooked in the mail flood.) I hereby formally propose the amendment below (Constitution A.1(1) `directly by proposer'), and, then, immediately accept it (A.1(2)). This resets the minimum discussion period (A.2(4)). For the avoidance of any doubt, I currently intend to not accept any further amendments. That means that the minimum discussion period will not be extended any further (unless the DPL intervenes). I currently intend to call for a vote when the minimum discussion period elapses, 2 weeks from now. The amendment is in two parts: I. In section 2, `Loose coupling of init systems', in the text `may not require a specific init system', replace `a' by `one': - In general, software may not require a specific init system to be + In general, software may not require one specific init system to be Explanation: Some people seem to have understood the previous text as must work with *all* init systems. I want to clarify that we just mean that software should not be tied to one specific init system. II. Insert new numbered section: + 3. As far as we are aware there are currently (17th of October) no +bugs in jessie which would be declared RC by this GR. + +Given the late passage of this resolution, we expect that any +intractable bugs which are RC by virtue only of this resolution +would be tagged by the release team as `jessie-ignore'. + +So this proposal is not thought to add blockers to the jessie +release. And, renumber the already-existing section 3 to be section 4: - 3. Notes and rubric + 3. Notes and rubric Explanation: It has become clear from the discussion that it is necessary to explicitly explain the intended effect for jessie. Comment: The new section 3 does not need any powers of the Technical Committee - indeed, it is purely informational and advisory. So it is not part of the amendment's to the TC's resolution of the 11th of February. Thanks, Ian. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUQ8OQAAoJEOPjOSNItQ05My8H/0LczpoZ+A2tDzrcdPgHv/yG qb0o62lLn/f9heO7+vQ1zNjVsyp0JlsiXSk3TrekKOuWCDiKz9ODtnpFrNefKtg8 iKdrcCvLVQECQZmv93FyxGkinu5X+TPe5fB4R3AsW14lVCYy8nztwArlRiPicFmC /x2ThWpb5AW3UTgwgpxCAaUllUypzCn3N+D3xsstmmrkXDa/xxxyj5xeOwWMIPe3 AD75cPj/RRNczGmoXsH8q6T2tNqiM02x9tRCEiOnG8QNYGlXU/OqtIclgtlcUUWj 8Hl1aOURogRNJyJur1dbyzCHgCa7Czzt00j0v7TO+7cIcBhIiXQcub/atCN9I44= =WwRe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21571.50100.535932.996...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
I'm an end user who normally only reads this list. I'd like to add my perspective to this question though, for what it's worth. I'm on Debian testing, which is using systemd now. The only obvious difference to me is my laptop boots faster, which is nice, but ... 1) Binary logs? No. Even I've used text logs for troubleshooting. They're incredibly useful and wonderfully transparent. Why would anyone want to move away from that? Except if less transparency was actually the point for them. 2) Total dependency of everything on this one process to run? No. Single points of failure are always stupid. Unless somebody is looking for more control. 3) It sounds like the the big or original push behind this is RedHat wants to cloudify everything. Nothing wrong with cloudiness in principle. I even have a little internet accessible server. Very convenient. But when a corp wants to put you on a cloud it's always called Hotel California. Do. Not. Go. There. Quixote. -- Re-imagining Democracy http://www.molvray.com/govforum, Acid Test http://molvray.com/acid-test/
Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)
Hi, Il giorno dom, 19/10/2014 alle 14.59 +0100, Ian Jackson ha scritto: I hereby formally propose the amendment below (Constitution A.1(1) `directly by proposer'), and, then, immediately accept it (A.1(2)). This resets the minimum discussion period (A.2(4)). For the avoidance of any doubt, I currently intend to not accept any further amendments. That means that the minimum discussion period will not be extended any further (unless the DPL intervenes). I currently intend to call for a vote when the minimum discussion period elapses, 2 weeks from now. The amendment is in two parts: I. In section 2, `Loose coupling of init systems', in the text `may not require a specific init system', replace `a' by `one': - In general, software may not require a specific init system to be + In general, software may not require one specific init system to be Explanation: Some people seem to have understood the previous text as must work with *all* init systems. I want to clarify that we just mean that software should not be tied to one specific init system. II. Insert new numbered section: + 3. As far as we are aware there are currently (17th of October) no +bugs in jessie which would be declared RC by this GR. + +Given the late passage of this resolution, we expect that any +intractable bugs which are RC by virtue only of this resolution +would be tagged by the release team as `jessie-ignore'. + +So this proposal is not thought to add blockers to the jessie +release. And, renumber the already-existing section 3 to be section 4: - 3. Notes and rubric + 3. Notes and rubric Explanation: It has become clear from the discussion that it is necessary to explicitly explain the intended effect for jessie. Comment: The new section 3 does not need any powers of the Technical Committee - indeed, it is purely informational and advisory. So it is not part of the amendment's to the TC's resolution of the 11th of February. Seconded. Cheers. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A signature.asc Description: This is a digitally signed message part
Re: Re-Proposal - preserve freedom of choice of init systems
On 17 October 2014 20:07, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Lucas Nussbaum writes (Re: Re-Proposal - preserve freedom of choice of init systems): If you agree that this is only a matter of general technical policy, and that the current state of jessie matches what you would like to see after your proposal, couldn't we just agree to withdraw both proposals now, and discuss what to do for jessie+1 later? If someone makes changes to dependencies between their packages and init systems that break this statu quo in jessie, you could still reintroduce your GR proposal during the freeze. But I think that this threat would be enough to maintain statu quo until we release (also, it is unlikely that the release team would allow such changes to be introduced during the freeze). What do you think? I can see why that is tempting. But this resolution is not only important within Debian, and not only for jessie. It is also important feedback for upstreams, and our peer distros and downstreams. At the moment there is a prevailing rhetoric that systemd is inevitable and everyone will (have to) be using it. What if (purely hypothetically) there was a public announcement from, say, release team that they consider it a RC bug if packages do not work with sysvinit as PID 1 in jessie both for stable upgrades and to maintain ability to switch init systems. And that after jessie release there will be a discussion and a GR to determine what severity such bugs would have for further Debian releases. Could that be enough to drop the current GRs? I *think* that particular statement we can all agree on. This would send a clear message to upstreams right now with another reminder later on. And it would postpone the controversial bit past the release. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDV4tDwXUYL3q1hVdTQ+CX4=NsHKu7Mw=wt1xurqh+j...@mail.gmail.com
Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ian Jackson writes (Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)): And, renumber the already-existing section 3 to be section 4: - 3. Notes and rubric + 3. Notes and rubric Don points out to me in private email that this should read: + 4. Notes and rubric Thanks, Ian. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJURAulAAoJEOPjOSNItQ054qUIAIR+tYnftyuOd+zroeW3KO/J j0wZmuIjKheHs0JNeURZ9+mkwZm5Z/XpsqoKsols7Li/qzLLarhmyYzCaFDjx4fV UR9RgQM0xrmOmmsAmcx8lYL/elmS1UBXLsKQBwzl/ipIgap5vLDRRSr6RCqmtNoq i1E9/THbrkfzH0CfCTgQmklWQGGcyysSLOtmylVT30i6uXjaub2v3S/+gdWRGDTm PKsZVbkM/q/5oFY9hTLdedGCS/kF7bHWX+y5xCohr3NfJmCyNkx3dWuYdu8CqTDP N6EzoMD4GlS3CDP3V2TaWXqs+Jj/xThoGttk9KcmAvW6govp55dT7fLFuvmV3jM= =7zvt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21572.2990.194337.845...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
On Fri, Oct 17, 2014 at 09:14:06PM +0200, Kurt Roeckx wrote: So let's just assume for now that I would come to the same conclusion. When do you think you'll do an authoritative assessment of this matter? Thanks, -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Sat, Oct 18, 2014 at 11:40:49AM +0200, Stefano Zacchiroli wrote: On Fri, Oct 17, 2014 at 09:14:06PM +0200, Kurt Roeckx wrote: So let's just assume for now that I would come to the same conclusion. When do you think you'll do an authoritative assessment of this matter? I did have to come to the same conclusion. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141018103515.ga16...@roeckx.be
Re: Re-Proposal - preserve freedom of choice of init systems
On Sat, Oct 18, 2014 at 4:00 AM, Simon Richter wrote: The technical shortcomings of systemd are the smaller problem here. The way I've been treated (stopping short of directly accusing me to actively look for problems to complain about) whenever I was raising a technical issue suggests to me that this is not a healthy ecosystem that can handle different viewpoints from members of the community. I have only gotten helpful hand-holding when reporting issues in #debian-systemd, even though usually those issues were the result of misconfigurations of my system. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6ENPPNve7af9wiCsJMhVK78733TGQKtZq6fngNM7ut=b...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
On 17 October 2014 01:36, Brian May br...@microcomaustralia.com.au wrote: If people feel strongly that init system XYZ should be supported, then presumably somebody will do the work to make sure it is supported, and it does work. [snip] On another topic, I think we need a GR stating that all software should work 100% with any window manager, especially my favourite window manager, Awesome. Actually that is a *very* similar issue. Apps should be window-manager-neutral as much as they should be init-system-neutral. Imagine if suddenly all Gnome apps stopped working unless you were running Metacity. It should not be up to window managers to implement all the features that all apps use, it should be up to apps to only depend on the common subset of features and to properly handle situations when such features are not available. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabpywdv386fzqkj+agwfuz-mp9y0a+6s1cy35fngbwjjvfe...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
Ian Jackson ijack...@chiark.greenend.org.uk writes: I wish to propose the following general resolution, and hereby call for seconds. This GR resolution proposal is identical to that proposed by Matthew Vernon in March: https://lists.debian.org/debian-vote/2014/03/msg0.html and the substantive text is that which was drafted for the purposes of the technical committee's vote (where they decided not to pass a resolution on the subject). IMO developments since March show that the concerns put forward then were well-founded. Following discussions elsewhere including -devel I have received enough offers of seconds by private email. As Matthew said, I don't think further lengthy discussion of the issues is likely to be productive, and therefore hope we can bring this swiftly to a vote. This is particularly true given the impact on the jessie release. Thanks, Ian. ** Begin Proposal ** 0. Rationale 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 Debian may depend on a particular init system. This GR seeks to preserve the freedom of our users now to select an init system of their choice, and the project's freedom to select a different init system in the future. It will avoid Debian becoming accidentally locked in to a particular init system (for example, because so much unrelated software has ended up depending on a particular init system that the burden of effort required to change init system becomes too great). A number of init systems exist, and it is clear that there is not yet broad consensus as to what the best init system might look like. This GR does not make any comment on the relative merits of different init systems; the technical committee has decided upon the default init system for Linux for jessie. 1. Exercise of the TC's power to set policy For jessie and later releases, the TC's power to set technical policy (Constitution 6.1.1) is exercised as follows: 2. Loose coupling of init systems 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 * special-use packages such as managers for init systems * cooperating groups of packages intended for use with specific init systems provided that these are not themselves required by other software whose main purpose is not the operation of a specific init system. Degraded operation with some init systems is tolerable, so long as the degradation is no worse than what the Debian project would consider a tolerable (non-RC) bug even if it were affecting all users. So the lack of support for a particular init system does not excuse a bug nor reduce its severity; but conversely, nor is a bug more serious simply because it is an incompatibility of some software with some init system(s). Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems. 3. Notes and rubric This resolution is a Position Statement about Issues of the Day (Constitution 4.1.5), triggering the General Resolution override clause in the TC's resolution of the 11th of February. The TC's decision on the default init system for Linux in jessie stands undisturbed. However, the TC resolution is altered to add the additional text in sections (1) and (2) above. ** End Proposal ** -- Seconded. Cheers, -- Arnaud Fontaine pgpjMmHYzeAMV.pgp Description: PGP signature
Re: Re-Proposal - preserve freedom of choice of init systems
Adam D. Barratt a...@adam-barratt.org.uk writes:
Speaking for no-one other than myself, I _am_ very unhappy that given
how long the discussion has been rumbling on for, and how much
opportunity there has been, that anyone thought that two weeks before
the freeze (which has had a fixed date for nearly a year now) was the
right time to raise this.
My understanding is that there were plenty of people interested in
seconding this when I originally raised it, but that they don't
habitually read -vote, and that if I'd spammed -{user,devel} or
similar, we could have had the vote earlier in the year.
I entirely agree that we should have voted when I originally suggested
the idea ( natch ;) ), and I'm sorry that I failed to make that happen
when I could have.
I wonder if, in the circumstances, the DPL should use their power
under 4.2.4 to reduce the discussion period to 1 week. I'd be
surprised if anyone is likely to change their view on the desirability
of choice of init system now - as others have pointed out, the
arguments have been rumbling on for a time.
Regards,
Matthew
--
At least you know where you are with Microsoft.
True. I just wish I'd brought a paddle.
http://www.debian.org
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5bvbnjxi1a@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
Matthew Vernon matt...@debian.org writes: I wonder if, in the circumstances, the DPL should use their power under 4.2.4 to reduce the discussion period to 1 week. I'd be surprised if anyone is likely to change their view on the desirability of choice of init system now - as others have pointed out, the arguments have been rumbling on for a time. The part that worries me about this GR isn't really will systemd win or lose. I'm somewhat worried about the jessie release being disturbed by this, and even more worried that we have moved to creating technical policy by GR without even attempting to use the normal Policy process first. This GR does not override the TC, but it does unnecessarily override the Policy process, and also overrides the authority of the Release Team on deciding what is RC and what isn't. -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wq7zqfrw@kirika.int.wmdata.fi
Re: Re-Proposal - preserve freedom of choice of init systems
On Thursday 16 October 2014 11:56 PM, Ansgar Burchardt wrote: Anyone around for the alternative choice of just one init system? In the same spirit of just one libc? (Yeah, choice of course does not include the C library or the kernel if it's just anti-evil-Red-Hat...) I guess we have one libc because it also serves our other ports. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Thursday 16 October 2014 11:58 PM, Adam D. Barratt wrote: Speaking for no-one other than myself, I _am_ very unhappy that given how long the discussion has been rumbling on for, and how much opportunity there has been, that anyone thought that two weeks before the freeze (which has had a fixed date for nearly a year now) was the right time to raise this. It was not intentional. Ian asked, and I expressed my opinion. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Friday 17 October 2014 12:11 AM, Holger Levsen wrote: And for what exactly? Gnome right now is installable with systemd-shim + sysvinit, why can't this GR wait until after release when the dust has settled? The world isn't just GNOME. This is a GR based on rumors, which is very sad. Now for me. systemd may be a good linux-only tool. But for Debian, as a project, for something as fundamental as an init, sticking to it is not a wise choice. If the project wants to do that, knock off all the non-Linux efforts first. As a base foundation, our choices should be things which are wide enough to embrace all our sub projects. Why didn't we do the same with network-manager ? -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Friday 17 October 2014 12:30 AM, Aigars Mahinovs wrote: If you don't like upstreams choices, *you* should write patches. Not GRs telling other people to do so. We have all kinds of policies about what is fine in a package and what is a Release Critical bug. That is a big part of what makes a distribution. This simply adds - must be able to work with any init system running at PID 1 to those requirements. Seconded. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Ian Jackson dixit: I wish to propose the following general resolution, and hereby call (d-d-a would have been nice, but this time I found it in time.) ** Begin Proposal ** 0. Rationale 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 Debian may depend on a particular init system. This GR seeks to preserve the freedom of our users now to select an init system of their choice, and the project's freedom to select a different init system in the future. It will avoid Debian becoming accidentally locked in to a particular init system (for example, because so much unrelated software has ended up depending on a particular init system that the burden of effort required to change init system becomes too great). A number of init systems exist, and it is clear that there is not yet broad consensus as to what the best init system might look like. This GR does not make any comment on the relative merits of different init systems; the technical committee has decided upon the default init system for Linux for jessie. 1. Exercise of the TC's power to set policy For jessie and later releases, the TC's power to set technical policy (Constitution 6.1.1) is exercised as follows: 2. Loose coupling of init systems 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 * special-use packages such as managers for init systems * cooperating groups of packages intended for use with specific init systems provided that these are not themselves required by other software whose main purpose is not the operation of a specific init system. Degraded operation with some init systems is tolerable, so long as the degradation is no worse than what the Debian project would consider a tolerable (non-RC) bug even if it were affecting all users. So the lack of support for a particular init system does not excuse a bug nor reduce its severity; but conversely, nor is a bug more serious simply because it is an incompatibility of some software with some init system(s). Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems. 3. Notes and rubric This resolution is a Position Statement about Issues of the Day (Constitution 4.1.5), triggering the General Resolution override clause in the TC's resolution of the 11th of February. The TC's decision on the default init system for Linux in jessie stands undisturbed. However, the TC resolution is altered to add the additional text in sections (1) and (2) above. ** End Proposal ** Seconded. bye, //mirabilos - -- diogenese Beware of ritual lest you forget the meaning behind it. igli yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (MirBSD) iQIcBAEBCQAGBQJUQNh+AAoJEHa1NLLpkAfg9x0QAIvGeyKQhtseT3NYo6ySd45h OqISkbeLQnSmCdpbtVlq6PFEaXlNYFnUiXr1//wOrcZAiDocx5iT+jPjULznLoaL BSRO/vFLUkbmix5tIyYiI3AymXb5KYR0c8JUAvyTChuFf0feavXt0Ew0zMxANBma zKTgnC2TJDAwJHu34kE2KwhidQtpKwi8Nyv9FsnMN1e2UvpBnEspgT+y86fS7wxT X7VWSObqpOupTvHV7LTogTP5e6p4AX7E+MC3TOOUtbWzFNd1eSlVxBuQirhlxg1M 0vxgjeb2PhdMGOLpuFtrJdkEcWXOeDwnOKIDRVg01Q1OPLIuMZz9i7aba0gmkc+/ kMp05cV1/pTDuKMZpRB35qmzWbDqRGBdnsQQn0yoEcL4uoXD8Mv/PwpymRExEwMG ODNkm4L1vqQ9NbxNxGzd1HjVIlFut+E+Z4uXysLpLmm+DqwfDEscEsCzaEOWykTt 0l4exBgmZTRNLxXA42ctbpFqISQu0oGBBj8R7U4o3NO6UUlE1MEPIEwAurYBiPFi ykTNARS4rlFwNmAuiIgcBWJMmM96pYgfOMf0SG6Io3uCjkHD2qNnaKqSnDTuChUL 0KKmJQHlOWeYCzZNEuHxk5+2ALTBMlptQhidUXpepg000mBnE+L1ukexbwXYuxQd 0PhxIoMChD2ZDv3YJu8K =f6kG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1410170847590.12...@herc.mirbsd.org
Re: Re-Proposal - preserve freedom of choice of init systems
On Friday 17 October 2014 12:43 AM, Ansgar Burchardt wrote: Aigars Mahinovs aigar...@debian.org writes: We have all kinds of policies about what is fine in a package and what is a Release Critical bug. That is a big part of what makes a distribution. This simply adds - must be able to work with any init system running at PID 1 to those requirements. No, it does not mean packages have to work with *any* init system. It's specifically aimed against a specific init replacement, see [1]. And for the Debian project, that *specific* init system shouldn't be systemd, in my opinion, given the breadth of sub projects we have. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Users still cannot vote? Or if we can, how? Best ， He who is worthy to receive his days and nights is worthy to receive* all else* from you (and me). The Prophet, Gibran Kahlil
Re: Re-Proposal - preserve freedom of choice of init systems
On 2014-10-17 09:35, Hörmetjan Yiltiz wrote: Users still cannot vote? No. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 directhex i have six years of solaris sysadmin experience, from 8-10. i am well qualified to say it is made from bonghits layered on top of bonghits -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/7d8ca7e368fc1ceaead88828a77b4...@hogwarts.powdarrmonkey.net
Re: Re-Proposal - preserve freedom of choice of init systems
On Fri, Oct 17, 2014 at 08:38:25AM +0100, Matthew Vernon wrote: I wonder if, in the circumstances, the DPL should use their power under 4.2.4 to reduce the discussion period to 1 week. I think this is a terrible idea. I agree that there are entrenched people on two sides of the argument, but there are others (myself included) who want to give a well-constructed GR (thus, we need a round of amendments to consider) proper, thorough consideration. If we start messing with the GR process in this way then whoever is on the losing side of the outcome will call the whole process foul. -- Jonathan Dowland -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141017090800.ga3...@chew.redmars.org
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, Oct 16, 2014 at 8:14 PM, Jonas Smedegaard d...@jones.dk wrote: Fine, conspiracy theories might be a bit too much. Let's call it strategic alliances that are a very real threat to Debian that are mediated by shared employment and might also involve corporate alliances. I don't care if monolithic system designs are caused by corporate alliances or not. And me neither. On Thu, Oct 16, 2014 at 4:05 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I wish to propose the following general resolution, and hereby call for seconds. I suspect that if the project members could have originally had the opportunity to vote on *which* init system should be the default on Jessie well, then it could have been handled much better. Cheers. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/camhuwowxc5puy0h2pocdhddmmbuak0um252yilfmmbmfvrf...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
aigar...@debian.org wrote: To be frank, in cases like logind I would expect the logind binary package to be split out and its source patched in such a way to allow it to work without systemd running (however badly) and moving the main systemd package from Dependencies to Recommended. It is quite clear that the real world does not and will not meet your expectations, because logind is not released this way and is not packaged this way. Now what? -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m1qmm3$l72$1...@posted-at.bofh.it
Re: Re-Proposal - preserve freedom of choice of init systems
Hi Ansgar, On Thu, Oct 16, 2014 at 08:26:21PM +0200, Ansgar Burchardt wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: I think that if necessary we might have to delay the release. That would be a matter for the release team. I would be very unhappy if we ditched the ability of people to choose a different init system simply to maintain our release schedule. Hurray, what a great idea to delay everything *now*. And all because some people believe in conspiracy theories about Red Hat... Nope - My feeling is that we are rushing systemd as fast as possible pushed for example by the Gnome ecosystem and every warning voice is beeing shut by we need feature X because Y. We/I have lived with the inadequate init system for 30 years so why are some people pushing _so hard_ to replace it NOW and by something as controversal as the systemd stuff. The arguments to replace the init system were dishonest (We need dependency booting because booting is slow) in the beginning, and the arguments got replaced with complete different feature argumentation now. And controversy with systemd even grew more over time since the TCs decision because of the amount of other software projects or functionality systemd maintainers decided to swallow - its not an init system anymore. Now - after a comparable short time we are already in the position that degradation of the OSes capabilities when not using systemd is beeing acceptable to the some/most/all? of our developers. Is this acceptable to our users? The major systemd proponents dont care. Debian as an institution should care: We will be guided by the needs of our users and the free software community. We already got to the point of no return with systemd - and THIS is something i guess is not something our users asked for, and something the TC did not foresee. If not now - when do people think we can stop and hopefully revert this trend? Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On 2014-10-17 9:45, Ritesh Raj Sarraf wrote: On Thursday 16 October 2014 11:58 PM, Adam D. Barratt wrote: Speaking for no-one other than myself, I _am_ very unhappy that given how long the discussion has been rumbling on for, and how much opportunity there has been, that anyone thought that two weeks before the freeze (which has had a fixed date for nearly a year now) was the right time to raise this. It was not intentional. Ian asked, and I expressed my opinion. That doesn't really disagree with my point. Ian could have asked weeks - in fact _months_ - ago. Regards, Adam -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5042cd3d170a9cc1e19b9003700b4...@mail.adsl.funky-badger.org
Re: Re-Proposal - preserve freedom of choice of init systems
f...@zz.de wrote: for 30 years so why are some people pushing _so hard_ to replace it NOW and by something as controversal as the systemd stuff. A vocal minority and a lot of trolls do not make something controversial. Considering how widely it has been adopted by other distributions I would say that for such a big change it is not controversial at all. We already got to the point of no return with systemd - and THIS is something i guess is not something our users asked for, and something the TC did not foresee. If I'd asked people what they wanted, they would have asked for a better horse. -- ciao, Marco -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m1qoso$ppa$1...@posted-at.bofh.it
Re: Re-Proposal - preserve freedom of choice of init systems
Adam D. Barratt writes (Re: Re-Proposal - preserve freedom of choice of init systems): Speaking for no-one other than myself, I _am_ very unhappy that given how long the discussion has been rumbling on for, and how much opportunity there has been, that anyone thought that two weeks before the freeze (which has had a fixed date for nearly a year now) was the right time to raise this. I'm very unhappy about that too. The right time to raise this was in March when Matthew proposed it and I seconded it. But that doesn't mean that it isn't still important now. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21568.60388.457157.688...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
Adam D. Barratt writes (Re: Re-Proposal - preserve freedom of choice of init systems): That doesn't really disagree with my point. Ian could have asked weeks - in fact _months_ - ago. I did, in March. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21568.60410.278320.24...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
On Fri, Oct 17, 2014 at 09:52:26AM +, Marco d'Itri wrote: f...@zz.de wrote: for 30 years so why are some people pushing _so hard_ to replace it NOW and by something as controversal as the systemd stuff. A vocal minority and a lot of trolls do not make something controversial. I havent found the mentioned minority you speak about? Considering how widely it has been adopted by other distributions I would say that for such a big change it is not controversial at all. Because of pressure of other upstreams going forward everyone adopted it and this makes it non controversial - i dont get it?!? We already got to the point of no return with systemd - and THIS is something i guess is not something our users asked for, and something the TC did not foresee. If I'd asked people what they wanted, they would have asked for a better horse. And even then the invention of the car was controversial and its even 100 years now. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Hi, Kurt Roeckx: Can I ask people to move discussion that is not relevant to the vote to some other place? Please don't. Personally, I do not want -devel to get swamped with yet another discussion about this. Or -release, for that matter. If it passes (which I consider to be sufficiently unlikely to wonder why the *censored* Ian even bothered, but whatever), _then_ these lists are the right places to discuss the implications. Until then, let's keep it here. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On 17 October 2014 13:27, Matthias Urlichs matth...@urlichs.de wrote: If it passes (which I consider to be sufficiently unlikely to wonder why the *censored* Ian even bothered, but whatever), _then_ these lists are the right places to discuss the implications. Until then, let's keep it here. From the discussion so far (and please correct me if I am wrong) the only implication of this passing would be that a failure of init-system-neutrality would now be a serious bug. It appears that with systemd-shim this bug is now fixed for Gnome (any other packages depending on libpam-systemd to get logind functionality). So this should not be a blocker for jessie release. I am not aware of any other issues that could impact this release stemming from this. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDXgCUNjay8=r=drdq6xkzhln-pwh8_c2y8anrrffye...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
On Oct 17, Florian Lohoff f...@zz.de wrote: A vocal minority and a lot of trolls do not make something controversial. I havent found the mentioned minority you speak about? Probably because you appear to be in the middle of it... Considering how widely it has been adopted by other distributions I would say that for such a big change it is not controversial at all. Because of pressure of other upstreams going forward everyone adopted it and this makes it non controversial - i dont get it?!? If you postulate some conspiracy to make everybody use systemd then I do not think that there is much more that we can argue about. But even then, if this alleged pressure has been strong enough to make every non-kooky distribution adopt systemd then it should be obvious that resisting it would be futile for us as well. -- ciao, Marco signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Jonathan Dowland j...@debian.org writes: On Fri, Oct 17, 2014 at 08:38:25AM +0100, Matthew Vernon wrote: I wonder if, in the circumstances, the DPL should use their power under 4.2.4 to reduce the discussion period to 1 week. I think this is a terrible idea. I agree that there are entrenched people on two sides of the argument, but there are others (myself included) who want to give a well-constructed GR (thus, we need a round of amendments to consider) proper, thorough consideration. If we start messing with the GR process in this way then whoever is on the losing side of the outcome will call the whole process foul. Good point. Regards, Matthew -- At least you know where you are with Microsoft. True. I just wish I'd brought a paddle. http://www.debian.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5br3y7x89p@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
On Fri, Oct 17, 2014 at 11:13:56AM +0100, Ian Jackson wrote: I'm very unhappy about that too. The right time to raise this was in March when Matthew proposed it and I seconded it. But that doesn't mean that it isn't still important now. Sure. But the drawbacks of having it now are much more severe. Of the teams I've mentioned in [1], I've already read in this thread opinions from [individual members of] the release team. And they don't seem pleased by having this GR at this point. Even though that's just guess work for now, I suspect other concerned teams will be even *less* pleased. [1]: https://lists.debian.org/debian-vote/2014/10/msg5.html As I've already told you in private mail, I value much more respecting the work (plans) of teams that have a proven record of putting a stellar amount of work in getting Debian releases together, than the technical ability of switching init system --- which, AFAIU, is not even currently undermined in Jessie. Such a position of mine is not merely grounded in abstract principles, it is eminently pragmatic: in a volunteer project performing technical changes is generally easier than refurbishing overworked and frustrated teams (that is so assuming you have enough people power, but high-profile vote-based conflicts are hardly a way to attract volunteers to a technical project). For these reasons, and no matter what went wrong in the past with previous attempts at this GR, I think you should have at the very least included an applies only to jessie + 1 provision in your proposal. Doing so would have disentangled this matter from the upcoming freeze, which, per se, is a well-known cause of stress for the project. The more I think of it, the more I get convinced that the collateral damages of this GR will outweigh any of its potential benefits. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Fri, Oct 17, 2014 at 09:16:49AM +0300, Aigars Mahinovs wrote: Actually that is a *very* similar issue. Apps should be window-manager-neutral as much as they should be init-system-neutral. Imagine if suddenly all Gnome apps stopped working unless you were running Metacity. It should not be up to window managers to implement all the features that all apps use, it should be up to apps to only depend on the common subset of features and to properly handle situations when such features are not available. Turning every bug into a blocker bug severity is a good way ensure it will become buggy. -- Regards, Olav -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141017113454.ga5...@bkor.dhs.org
Re: Re-Proposal - preserve freedom of choice of init systems
On Fri, Oct 17, 2014 at 12:23:15PM +0200, Florian Lohoff wrote: Because of pressure of other upstreams going forward everyone adopted it and this makes it non controversial - i dont get it?!? The adaption in openSUSE and Mageia was not due to this. The discussion is public. If you claim above then provide references. -- Regards, Olav -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141017114513.gc5...@bkor.dhs.org
Re: Re-Proposal - preserve freedom of choice of init systems
On 2014-10-17 12:00, Aigars Mahinovs wrote: On 17 October 2014 13:27, Matthias Urlichs matth...@urlichs.de wrote: If it passes (which I consider to be sufficiently unlikely to wonder why the *censored* Ian even bothered, but whatever), _then_ these lists are the right places to discuss the implications. Until then, let's keep it here. From the discussion so far (and please correct me if I am wrong) the only implication of this passing would be that a failure of init-system-neutrality would now be a serious bug. Note (and this is not splitting hairs) that serious bug is not a direct analogue for release-critical bug. Regards, Adam -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cd3d6102a0b50499dc9017549f59d...@mail.adsl.funky-badger.org
Re: Re-Proposal - preserve freedom of choice of init systems
On Friday 17 October 2014 05:10 PM, Olav Vitters wrote: The world isn't just GNOME. The issue is bigger than just GNOME. Think of e.g. UPower. There is various other software which is affected by this. Requiring people to do your bidding is against the Debian social contract. While this is pretty much what the GR is about. Seems unrealistic, plus seems you're voting on something without knowing any specific (just GNOME). If you expect upstream/Debian packager teams to take people who cannot bother to inform themselves on their topic serious, then geez... good luck but you're heading towards a wall. Not just UPower. UDisks, PolicyKit and many more. And if we don't take a sensible stand, soon hostname, cron, dns, network, power etc. In Debian, until the decision in Feb, everything worked with sysvinit. And then eventually it broke. As we speak today, Udisk + Upower + PolKit (experimental) does work again. Buy my point is, things used to work neutrally. Why can't we strive to do that? Have the systemd support. I don't think anyone is opposing that. But don't bring that at the cost of an alternate neutral option. Why is SysV Init so unacceptable ? It is a neutral init that serves well for all our sub-projects. Let that be the default choice. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On 17 October 2014 15:53, Ritesh Raj Sarraf r...@researchut.com wrote: Why is SysV Init so unacceptable ? It is a neutral init that serves well for all our sub-projects. Let that be the default choice. Please do not conflate two very different issues. The default choice has been decided and is not in question at this point. This is about ensuring that SysV init (among others) is and continues to be a *possible* choice for a user. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABpYwDWoejUKybVpJk=qzz1j1d6hozk20g-mrmvfh5gg4bv...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
On Fri, Oct 17, 2014 at 06:23:30PM +0530, Ritesh Raj Sarraf wrote: Why is SysV Init so unacceptable ? It is a neutral init that serves well for all our sub-projects. Let that be the default choice. Ritesh, from various mails of yours I got the impression that you are arguing for changing (back) the default init system. This GR is not about that; please don't make yet another _thread_ about that either :-) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Friday 17 October 2014 06:27 PM, Aigars Mahinovs wrote: On 17 October 2014 15:53, Ritesh Raj Sarraf r...@researchut.com wrote: Why is SysV Init so unacceptable ? It is a neutral init that serves well for all our sub-projects. Let that be the default choice. Please do not conflate two very different issues. The default choice has been decided and is not in question at this point. This is about ensuring that SysV init (among others) is and continues to be a *possible* choice for a user. It would be nice to know what possible is defined as. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Fri, Oct 17, 2014 at 06:23:30PM +0530, Ritesh Raj Sarraf wrote: On Friday 17 October 2014 05:10 PM, Olav Vitters wrote: The world isn't just GNOME. The issue is bigger than just GNOME. Think of e.g. UPower. There is various other software which is affected by this. Requiring people to do your bidding is against the Debian social contract. While this is pretty much what the GR is about. Seems unrealistic, plus seems you're voting on something without knowing any specific (just GNOME). If you expect upstream/Debian packager teams to take people who cannot bother to inform themselves on their topic serious, then geez... good luck but you're heading towards a wall. Not just UPower. UDisks, PolicyKit and many more. And if we don't take a sensible stand, soon hostname, cron, dns, network, power etc. In Debian, until the decision in Feb, everything worked with sysvinit. And then eventually it broke. As we speak today, Udisk + Upower + PolKit (experimental) does work again. That's not a result of Debian going for systemd. It is a result of upstream decisions. If you're maintaining something and part of the functionality is provided by systemd, then it is up to the maintainer to decide. Buy my point is, things used to work neutrally. Why can't we strive to do that? Because you're requesting the same functionality to be duplicated. You're also confusing things. The GR is within Debian, while in your email you're talking about upstream decisions/changes. Have the systemd support. I don't think anyone is opposing that. But don't bring that at the cost of an alternate neutral option. So who will maintain that code? Why is SysV Init so unacceptable ? It is a neutral init that serves well for all our sub-projects. Let that be the default choice. I'm not about other init systems. I'm after forcing people to do your bidding. If some work has to be done, go ahead and do it. Alternative logind? Cool! But the systemd-shim is a fork, seems to rely on cgmanager (think nogo on non-Linux), etc. If you want to force changes at upstream, go ahead. This is a GR within Debian. So as an upstream I'd expect Debian to do the work as well as the ongoing maintenance to make it happen. -- Regards, Olav -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141017131441.gd5...@bkor.dhs.org
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, Oct 16, 2014 at 04:05:41PM +0100, Ian Jackson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I wish to propose the following general resolution, and hereby call for seconds. This GR resolution proposal is identical to that proposed by Matthew Vernon in March: https://lists.debian.org/debian-vote/2014/03/msg0.html IMO, it's not the time to propose such GR again. #kthxbye. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. Faith means not wanting to know what is true. -- Nietzsche signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Stefano Zacchiroli writes (Re: Re-Proposal - preserve freedom of choice of init systems): For these reasons, and no matter what went wrong in the past with previous attempts at this GR, I think you should have at the very least included an applies only to jessie + 1 provision in your proposal. Doing so would have disentangled this matter from the upcoming freeze, which, per se, is a well-known cause of stress for the project. The problem with making it simply not apply to jessie is that there would be a continued opportunity to create `facts on the ground' which make it difficult to disentangle things in jessie + 1. But I am not suggesting that the release team ought to apply different criteria for `jessie-ignore' for RC bugs, for example. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21569.9679.510648.635...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
Niels Thykier writes (Re: Re-Proposal - preserve freedom of choice of init systems): While I appreciate that this is a very important issue for a lot of people, I am deeply concerned by the point in time it is revived. _*We have less than 3 weeks till the Jessie freeze starts!*_ I agree that the timing is very regrettable. You'd have to ask other people why they didn't second the identical GR in March. Honestly, I am interpreting this as a ticking time bomb under the freeze. Who exactly is volunteering to implement this GR if it goes through? Taking GNOME as a hypothetical example[2], suppose it was uninstallable without systemd and the GNOME maintainers say We do not want to implement this GR[3]. That would depend how easy it would be to fix. If the fix is easy (for example, the reason it's uninstallable is because of a dependency declared for political reasons but without which the actual operation is OK) then it would be a simple matter to NMU it. If the fix is not easy then we have three options: the release team mark it `jessie-ignore', the GNOME maintainers fix it, or GNOME is removed from jessie. I mention the third option not because I think it's what we should do right now, but to point out that I am not saying that the GNOME team (or indeed GNOME upstream) have to do any work. No-one has to do any work, but if the work goes undone, there are of course consequences to the affected packages. If problems persist into jessie+1 I _would_ expect us to seriously consider removing GNOME. Then you leave us with a per GR-defined RC buggy default desktop from day one of the freeze and no one to clean it up. Of course I would expect those choosing the default desktop to pick one that wasn't RC-buggy. Be advised that I would very much be inclined to jessie-ignore such issues, if such stalemates end up as blockers for the release. Would it help if we added a note to the GR explicitly saying that this is what we expect ? Something like: Given the late passage of this resolution, we expect that intractable bugs which are RC by virtue only of this resolution will be tagged by the release team as `jessie-ignore'. ? Beyond that, I would /very much/ like to see guidelines for just how much degradation is tolerable. Honestly, I think this should be a part of the GR text. I do not want to end up as the bad guy having to enforce this GR during the freeze, when I most at all really do not want this GR to affect Jessie at all. I'm afraid that explaining guidelines for that seems obviously impractical to me. But the backstop is that uninstallability, or complete failure to work on any system, is obviously RC. Lack of working power management or broken suspend would be very annoying but probably not RC. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21569.10430.534356.608...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
Adam D. Barratt wrote: Note (and this is not splitting hairs) that serious bug is not a direct analogue for release-critical bug. This GR is not amending Debian policy, it's setting a technical requirement at a more fundamental level, which has never been used to set technical requirements in Debian before. So it's not clear, at least to me, that the release team would have the power to make that distinction if this GR passes. Bypassing the policy process, locking Debian into a technical decision which would require another GR to change, etc -- this GR is wading into uncharted waters without much concern for long term results. -- see shy jo signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Ian Jackson wrote: The problem with making it simply not apply to jessie is that there would be a continued opportunity to create `facts on the ground' which make it difficult to disentangle things in jessie + 1. Can you please point to one thing in jessie that is currently entangled in a way that your proposal would prevent happening? -- see shy jo signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On 10/17/2014 10:33 AM, Ian Jackson wrote: If the fix is not easy then we have three options: the release team mark it `jessie-ignore', the GNOME maintainers fix it, or GNOME is removed from jessie. The implication here appears to be troubling for any upstream who wants to rely on specific features of a given initsystem. As a developer, i've built tools that were deliberately minimal *because* i want those tools to rely on functionality provided by the initsystem of my choice. Concretely, i've built tools that work only when you have the runit package installed and functional as the local init system. The implication of this proposed GR seems to be that those tools would be unfit for inclusion within debian unless someone erects all the additional scaffolding that runit provides (process supervision, pipelined logfiles with autorotation and log msgs just sent to stderr, restart on abnormal termination, no need for daemonization, clean process initialization, etc), but does so outside of runit. I don't think this makes sense -- we should not be rejecting upstream packages from debian just because they are designed to take advantage of features of a given init system. I'm not opposed to helping people work within the confines of whatever init system they prefer -- one of the things i love about debian is that i've been able to run machines with runit as pid 1 for many years now. But i have always understood that if i'm not using the default initsystem, and something breaks from that interaction, i probably need to fix it myself (and to submit patches to upstream and/or the debian package if i want it to work better for other people who also use runit as pid 1). This isn't surprising or specific to init systems, of course -- it's how free software works. It sounds like there are a lot of people who care about making sure things work with sysvinit -- that's great, and i hope that energy will result in more functional sysvinit-based installations. I'm happy for us to maintain a healthy diversity, and want to see that work happen. But i don't think it is (or should be) an RC bug just because your particular package doesn't support my particular initsystem. --dkg signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
- Holger Levsen hol...@layer-acht.org wrote: If you don't like upstreams choices, *you* should write patches. Not GRs telling other people to do so. Very well stated. Perhaps a sensible response to this GR is for all of the maintainers who truly disagree with it to state their intent of putting their packages up for adoption upon its ratification. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/17457306.37831413558059670.javamail.r...@newmail.brainfood.com
Re: Re-Proposal - preserve freedom of choice of init systems
Hi, Brian May: If people feel strongly that init system XYZ should be supported, then presumably somebody will do the work to make sure it is supported, and it does work. As I believe is the case now. Correct. But this proposal would make *something* RC buggy until *somebody* writes some software, and it's not at all clear which thing should get the bug, who that somebody is, or what happens if no *somebody* steps up -- do we drop Gnome? (Or whichever software next exhibits a problem along these lines.) In this case, some people stepped up and wrote that something – because they saw a need for it. Fine, superb, this is how Debian should work. Did work, even without this GR. What a surprise … On another topic, I think we need a GR stating that all software should work 100% with any window manager, especially my favourite window manager, Awesome. Same problem. Same solution: either somebody is motivated enough to do the work (and, hopefully, Upstream will take the patches), or interoperability will not happen. Making up other issues along these lines is left as an exercise to the reader. In either case, a GR forcing RC bugs on the issue is not helpful IMHO. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141017151108.gb12...@smurf.noris.de
Re: Re-Proposal - preserve freedom of choice of init systems
Joey Hess writes (Re: Re-Proposal - preserve freedom of choice of init systems): Ian Jackson wrote: The problem with making it simply not apply to jessie is that there would be a continued opportunity to create `facts on the ground' which make it difficult to disentangle things in jessie + 1. Can you please point to one thing in jessie that is currently entangled in a way that your proposal would prevent happening? As far as I'm aware the current situation in jessie is fine as far as this GR goes. There are some bugs with the dependency handling which means that sometimes the packaging tools do very surprising and undesirable things, but they are fixable, generally not RC and anyway not directly addressed by this GR. So if there is no backsliding, this GR will not delay the jessie release at all. However there have been a number of bugs already (now fixed), and persistent misunderstandings. For example: https://lists.debian.org/debian-devel/2014/10/msg00163.html The necessity to depend on (and coexist with) pm-utils is imho gone with Debian's move to systemd https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762116#11 The only problem here is trying to support multiple init systems. Linux is not about choice. https://lists.debian.org/debian-devel/2014/10/msg00411.html It is there because upstream requires it. There is no GNOME without systemd. This is not specific to Debian. In some of these cases the rhetoric is very alarming; others are mistakes of some kind. But, it is evident that we have not communicated clearly enough our commitment to diversity. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21569.13047.955094.814...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
Daniel Kahn Gillmor writes (Re: Re-Proposal - preserve freedom of choice of init systems): The implication here appears to be troubling for any upstream who wants to rely on specific features of a given initsystem. Yes, indeed. The implication of this proposed GR seems to be that those tools would be unfit for inclusion within debian unless someone erects all the additional scaffolding that runit provides (process supervision, pipelined logfiles with autorotation and log msgs just sent to stderr, restart on abnormal termination, no need for daemonization, clean process initialization, etc), but does so outside of runit. But runit is exactly the scaffolding needed to do that, and already exists! runit can coexist peacefully with sysvinit, systemd, upstart, or whatever. There is no problem depending on runit because runit doesn't demand being pid 1, so it is nonexclusive. This isn't surprising or specific to init systems, of course -- it's how free software works. The problem with init systems is that you can have only one. If people want to make Debian derivatives that work only with a particular init system, that's completely fine. The reverse - trying to put back support for sysvinit, if it gets taken out of Debian, would be very very difficult. As the upstream for our ecosystem, we in Debian have a special responsibility to retain the flexibility our downstreams might want. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21569.13608.388043.939...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
On 10/17/2014 11:26 AM, Ian Jackson wrote: Daniel Kahn Gillmor writes (Re: Re-Proposal - preserve freedom of choice of init systems): The implication here appears to be troubling for any upstream who wants to rely on specific features of a given initsystem. Yes, indeed. The implication of this proposed GR seems to be that those tools would be unfit for inclusion within debian unless someone erects all the additional scaffolding that runit provides (process supervision, pipelined logfiles with autorotation and log msgs just sent to stderr, restart on abnormal termination, no need for daemonization, clean process initialization, etc), but does so outside of runit. But runit is exactly the scaffolding needed to do that, and already exists! runit can coexist peacefully with sysvinit, systemd, upstart, or whatever. There is no problem depending on runit because runit doesn't demand being pid 1, so it is nonexclusive. nevertheless, runit behaves differently when it is pid 1 than when it is used in a subordinate role to another initsystem. If i'm upstream and i'm building mechanisms that integrate with runit *as it behaves as pid 1*, the implication seems to be that my work would not be welcome in debian. This isn't surprising or specific to init systems, of course -- it's how free software works. The problem with init systems is that you can have only one. If people want to make Debian derivatives that work only with a particular init system, that's completely fine. The reverse - trying to put back support for sysvinit, if it gets taken out of Debian, would be very very difficult. i don't think that anyone has tried to remove support for sysvinit for debian -- i certainly hope the sysvinit maintainers are unlikely to leave the project or orphan the package. There may be packages that don't work as well or integrate as well in a sysvinit-based debian installation as they do for other choices of pid 1. But that is also true if runit is my pid 1 -- some packages won't integrate as well with my system if i choose this config. That doesn't mean those packages are RC-buggy, it means i need to submit servicedirs for them and hopefully find ways for developers to adopt them. Or to provide system service packages that are distinct from packages containing the tools entirely [0], so that anyone who wants to support service initialization on an arbitrary initsystem can do so independently. That said, i don't think that putting back support for sysvinit for any given package that is unable to currently maintain it would actually be as difficult as you make it out to be. As the upstream for our ecosystem, we in Debian have a special responsibility to retain the flexibility our downstreams might want. Yes, we do. But we also have a responsibility to package and distribute modern, upstream-maintained versions of useful free software even if those versions have dependencies that some people might not find preferable. We also shouldn't restrain packagers from uploading software just because they don't have service initialization mechanisms for every pid 1 that can possibly be used in a debian system. I like both postgresql and runit, and am really happy that both these things are in debian. But postgresql isn't RC-buggy just because the system service doesn't start automatically when i choose to use runit as pid 1. Regards, --dkg [0] https://www.debian-administration.org/users/dkg/weblog/53 signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Le vendredi, 17 octobre 2014, 10.00:59 Ean Schuessler a écrit :
- Holger Levsen hol...@layer-acht.org wrote:
If you don't like upstreams choices, *you* should write patches. Not
GRs telling other people to do so.
Very well stated. Perhaps a sensible response to this GR is for all of
the maintainers who truly disagree with it to state their intent of
putting their packages up for adoption upon its ratification.
This would only make Debian worse, not better.
Amongst the other problems of this GR, I think this one is the worst
part: this GR text [0] creates artificial new conditions [1] for
software acceptable in Debian, both for new software _and_ for existing
ones. This implies that the best ${insert-your-tech-here} since slice
bread only working with one init system [2] would _not_ be acceptable in
Debian until someone does the work to make it non-init specific, even
if no one would ever imagine using said ${insert-your-tech-here} in that
context. We'd be severely moving away from a patches welcome culture,
which I feel, does quite essentially define our mode of collaboration.
We'd be moving to a culture where perfect(ly init-agnostic) would be the
enemy of good and where we put the burden of making sure corner-cases
work not on the ones experiencing the corner-cases, but on the
maintainers. I'm unhappy about that and will not vote in favour of this
proposal.
Cheers,
OdyX
[0] 21567.57029.724173.958...@chiark.greenend.org.uk
[1] On top of our usual set: DFSG, maintainability, security, etc.
[2] Which might happen to be why it's so much better: better integration
across the stack.
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/56544976.cMIKFiWbv4@gyllingar
Re: Re-Proposal - preserve freedom of choice of init systems
Ian Jackson wrote: Joey Hess writes (Re: Re-Proposal - preserve freedom of choice of init systems): Ian Jackson wrote: The problem with making it simply not apply to jessie is that there would be a continued opportunity to create `facts on the ground' which make it difficult to disentangle things in jessie + 1. Can you please point to one thing in jessie that is currently entangled in a way that your proposal would prevent happening? As far as I'm aware the current situation in jessie is fine as far as this GR goes. [..] So if there is no backsliding, this GR will not delay the jessie release at all. But, the resolution of this GR and the start of the freeze cooincide, +-1 week. And after the freeze, the chances of backsliding being allowed, after release team review, are minimal. -- see shy jo signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Daniel Kahn Gillmor writes (Re: Re-Proposal - preserve freedom of choice of init systems): nevertheless, runit behaves differently when it is pid 1 than when it is used in a subordinate role to another initsystem. If i'm upstream and i'm building mechanisms that integrate with runit *as it behaves as pid 1*, the implication seems to be that my work would not be welcome in debian. Are you saying that a daemon author would want to write code which only worked if runit was pid 1 ? This question of daemon startup is a red herring, I think. It is generally easy to solve the problem with some kind of wrapper or tool, even if a daemon only starts up in a particular way. I like both postgresql and runit, and am really happy that both these things are in debian. But postgresql isn't RC-buggy just because the system service doesn't start automatically when i choose to use runit as pid 1. postgresql wouldn't be RC-buggy if it _never_ started automatically. That would just be an annoying bug. And the GR text is quite careful: it doesn't say that failure to work with one init system is worse than any other bug. It is only _requiring a specific init system to be pid 1_ which is forbidden. That's the exactly correct criterion because it is pid 1 which you can only have one of. A user can have as different non-pid-1 daemon supervisors as they like so there is no problem with a daemon requiring a particular supervisor - provided that supervisor can work (well enough) when not pid 1. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21569.15983.134642.422...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
Joey Hess writes (Re: Re-Proposal - preserve freedom of choice of init systems): Ian Jackson wrote: So if there is no backsliding, this GR will not delay the jessie release at all. But, the resolution of this GR and the start of the freeze cooincide, +-1 week. And after the freeze, the chances of backsliding being allowed, after release team review, are minimal. So your objection to the GR is that it is a no-op ? Other people are objecting on the grounds that the sky would fall. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21569.16283.286465.7...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
Ian Jackson writes (Re-Proposal - preserve freedom of choice of init systems): ** Begin Proposal ** I am considering making an amendment to this along the lines below. Please let me know ASAP what you think. Feel free to use private email. Especially, I would like to hear from: - People who seconded the original version: are you satisfied that with these amendments it still does the job ? - Lucas and people who have seconded Lucas's version, or who are opposed to the GR on timing grounds: would this go far enough for you to support my version, or feel Lucas's alternative is unnecessary ? I intend to make a decision about this in the next 36-48h. I will send a copy of this by private email to my seconders. 2. Loose coupling of init systems ... Insert new numbered section: 3. As far as we are aware there are currently (17th of October) no bugs in jessie which would be declared RC by this GR. Given the late passage of this resolution, we expect that any intractable bugs which are RC by virtue only of this resolution would be tagged by the release team as `jessie-ignore'. So this proposal is not thought to add blockers to the jessie release. And renumber section 3 to 4. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21569.17357.588656.319...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
On 10/17/2014 12:06 PM, Ian Jackson wrote: Daniel Kahn Gillmor writes (Re: Re-Proposal - preserve freedom of choice of init systems): nevertheless, runit behaves differently when it is pid 1 than when it is used in a subordinate role to another initsystem. If i'm upstream and i'm building mechanisms that integrate with runit *as it behaves as pid 1*, the implication seems to be that my work would not be welcome in debian. Are you saying that a daemon author would want to write code which only worked if runit was pid 1 ? Consider a tool that integrates in some way with /etc/runit/1 or /etc/runit/2 or /etc/runit/3, which are only relevant for systems with runit as pid 1 (see runit(8) for more details). Such a tool should not be RC-buggy just because it's useless on a system that uses systemd or sysvinit. This question of daemon startup is a red herring, I think. It is generally easy to solve the problem with some kind of wrapper or tool, even if a daemon only starts up in a particular way. so to be clear, it's not (and shouldn't be) an RC bug if a service fails to start automatically on a system with a non-default init system, right? I like both postgresql and runit, and am really happy that both these things are in debian. But postgresql isn't RC-buggy just because the system service doesn't start automatically when i choose to use runit as pid 1. postgresql wouldn't be RC-buggy if it _never_ started automatically. That would just be an annoying bug. I'm glad to hear that. And the GR text is quite careful: it doesn't say that failure to work with one init system is worse than any other bug. It is only _requiring a specific init system to be pid 1_ which is forbidden. If the requirement is testing a literal string match against /proc/1/cmdline or $(readlink -f /sbin/init) or whatever, then that's pretty silly, and surely that's *already* a bug that upstream would be grateful for a fix. in this case, we don't need a GR. But if the requirement is hey, i'm not going to work without something else on the system performing functionality X, and a given init system *doesn't provide* functionality X, then it sounds like either a bug in the lacking initsystem (should provide functionality X), or a straightforward case of an explicit dependency. It could also be resolved by making some part of the dependent package's functionality more limited in scope, and saying we can run but we can't to Y if we don't have access to system functionality X. These are all legitimate options for resolving the problem, and they're already available to folks who want to work on them today. It sounds like the gdm issue was actually resolved already through some combination of these approaches (thanks to Aigars for the recap upthread). Why do we need a GR that's unlikely to change this situation? That's the exactly correct criterion because it is pid 1 which you can only have one of. A user can have as different non-pid-1 daemon supervisors as they like so there is no problem with a daemon requiring a particular supervisor - provided that supervisor can work (well enough) when not pid 1. we also limit debian systems to only one mail-transport-agent (e.g. exim or postfix or courier, but not two of them at once), but we don't say that mta-specific packages are RC-buggy, even if someone who has a courier installation would really like to use a tool that currently only integrates into postfix's mail-handling flow. I'm going to stop commenting on this thread now and try to fix some bugs that need fixing before the freeze. Ian, thanks for raising the concern, and Lucas, thanks for floating an alternative option. I hope we can spend our limited time fixing existing bugs and working well together. --dkg signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On 17/10/14 at 17:29 +0100, Ian Jackson wrote: 3. As far as we are aware there are currently (17th of October) no bugs in jessie which would be declared RC by this GR. Given the late passage of this resolution, we expect that any intractable bugs which are RC by virtue only of this resolution would be tagged by the release team as `jessie-ignore'. So this proposal is not thought to add blockers to the jessie release. And renumber section 3 to 4. If you agree that this is only a matter of general technical policy, and that the current state of jessie matches what you would like to see after your proposal, couldn't we just agree to withdraw both proposals now, and discuss what to do for jessie+1 later? If someone makes changes to dependencies between their packages and init systems that break this statu quo in jessie, you could still reintroduce your GR proposal during the freeze. But I think that this threat would be enough to maintain statu quo until we release (also, it is unlikely that the release team would allow such changes to be introduced during the freeze). What do you think? Lucas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141017165421.ga31...@xanadu.blop.info
Re: Re-Proposal - preserve freedom of choice of init systems
On 10/17/2014 03:09 AM, Adam D. Barratt wrote: On Thu, 2014-10-16 at 22:00 +0300, Aigars Mahinovs wrote: We have all kinds of policies about what is fine in a package and what is a Release Critical bug. That is a big part of what makes a distribution. This simply adds - must be able to work with any init system running at PID 1 to those requirements. Strictly speaking, what is a Release Critical bug is the release team's purview, as per their delegation. (Of course, subject to being overriden by the project as with any other delegate.) Regards, Adam And therefore, having this GR now shouldn't be a problem. To me, it's perfectly fine to decide now that we don't want tight coupling with systemd (and therefore, try to fix these issues when we can), as long as we also decide that it's not going to delay the release. And since it's the release team who has the decision power, I can only see it happening the correct way. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544149e7.5090...@debian.org
Re: Re-Proposal - preserve freedom of choice of init systems
Ian Jackson wrote: Joey Hess writes (Re: Re-Proposal - preserve freedom of choice of init systems): Ian Jackson wrote: So if there is no backsliding, this GR will not delay the jessie release at all. But, the resolution of this GR and the start of the freeze cooincide, +-1 week. And after the freeze, the chances of backsliding being allowed, after release team review, are minimal. So your objection to the GR is that it is a no-op ? Other people are objecting on the grounds that the sky would fall. The GR is clearly not a no-op post-jessie. But we're supposed to be getting ready to release jessie now. The timing is off. -- see shy jo signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Lucas Nussbaum writes (Re: Re-Proposal - preserve freedom of choice of init systems): If you agree that this is only a matter of general technical policy, and that the current state of jessie matches what you would like to see after your proposal, couldn't we just agree to withdraw both proposals now, and discuss what to do for jessie+1 later? If someone makes changes to dependencies between their packages and init systems that break this statu quo in jessie, you could still reintroduce your GR proposal during the freeze. But I think that this threat would be enough to maintain statu quo until we release (also, it is unlikely that the release team would allow such changes to be introduced during the freeze). What do you think? I can see why that is tempting. But this resolution is not only important within Debian, and not only for jessie. It is also important feedback for upstreams, and our peer distros and downstreams. At the moment there is a prevailing rhetoric that systemd is inevitable and everyone will (have to) be using it. The TC's decision in February lent weight to that impression (inadvertantly but entirely predictably). This impression has been repeatedly put forth on Debian lists, and indeed elsewhere. (I gave some references earlier.) And this GR is also important for jessie+1 and the future generally. I don't want to postpone having this conversation until things have become yet more difficult, and face the argument that what we want is impossible for jessie+1. If there is a problem with this GR it is that it is too late. Making it later is just going to allow the dispute to escalate. And in the meantime we will have to put up with endless guerilla warfare from the various camps. Ian. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21569.19669.726247.130...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
On 10/17/2014 05:14 PM, Marco d'Itri wrote: aigar...@debian.org wrote: To be frank, in cases like logind I would expect the logind binary package to be split out and its source patched in such a way to allow it to work without systemd running (however badly) and moving the main systemd package from Dependencies to Recommended. It is quite clear that the real world does not and will not meet your expectations, because logind is not released this way and is not packaged this way. Now what? Now, if we can't get the patches we need in the original sources, we deal with such a non-cooperative upstream and do what's needed on the packaging side. That's not the first time, and it wont be the last, and it's not even specific to systemd. Thomas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54414d8c.7080...@debian.org
