Re: Re-Proposal - preserve freedom of choice of init systems

[Aleskandro]

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: Re-Proposal - preserve freedom of choice of init systems

[tor...@riseup.net]

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

[Marco d'Itri]

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-Proposal - preserve freedom of choice of init systems

[golinux]

Greetings Debian developers!

As a lowly 'Troglyte' who uses Debian as a DE not as server, this appeal 
to the 'cloud dwellers' of Debian-Stratos might be dismissed (with 
disdain and prejudice) as non-technical and 'emotional'.  So be it.


I have seen just about everything in my many years on this earth (born 
before Hiroshima was bombed). One of the biggest lessons of life is that 
nothing lasts for very long. So it is illogical to assume that Debian, 
the bastion of freedom and stability, would not eventually  come to the 
time of its undoing. That time appears to be imminent. I predict he 
adoption of systemd as the one-and-only-way will transform Debian into a 
shadow of its former glorious self.


I came to Linux for FREEDOM and for configurability. Finally, I could 
have a DE exactly as I wanted it! I have had many happy years with 
Debian but have also been aware of subtle changes that slowly eliminated 
this feature, then that feature.  The rate of feature-attrition has only 
increased over the years but things were still workable.


Then when the abomination of Gnome 3 arrived, I could see the 
handwriting on the wall.  This was the beginning of the end.  And so it 
appears that day is upon us.


systemd is about more than an init system. I don't want it's tentacles 
ANYWHERE on my system in any form. I love what this Debian user had to 
say:


". . . it seems the powers that be want everybody using stupid, ugly, 
bizarre Gnome with virusd under the hood, I'd rather take an axe to my 
PC first."


In a perfect world, Debian would offer not only a choice of init systems 
but a version completely liberated from the tyranny of systemd.


I'll be watching this carefully until Squeeze comes to EOL and then 
Wheezy. By that time either Debian will have corrected course and/or a 
viable fork will have emerged and/or another OS will have come to the 
forefront to fill the void. It's gonna be a real cliffhanger.  I hope I 
live long enough to see how this sorts out.


Hopefully, the final epitaph won't be 'Debian RIP'.  Or worse yet "Linux 
RIP".  Think that couldn't happen?  Think again . . .


Thanks for listening.

golinux

(a pissed off Desktop user)



--
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/a27760f39d54aa2c2ecf0ab2144b2...@riseup.net

Re: Re-Proposal - preserve freedom of choice of init systems

[Andre Kiepe]

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

[spoofy]

I agree with the proposal.

Re: Calling for the vote (Re: Re-Proposal - preserve freedom of choice of init systems)

[Ian Jackson]

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: Calling for the vote (Re: Re-Proposal - preserve freedom of choice of init systems)

[Kurt Roeckx]

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)

[Anthony Towns]

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)

[Ian Jackson]

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)

[Kurt Roeckx]

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)

[Ansgar Burchardt]

Hi,

Ian Jackson  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

Calling for the vote (Re: Re-Proposal - preserve freedom of choice of init systems)

[Ian Jackson]

-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: Re-Proposal - preserve freedom of choice of init systems

[Martinx - ジェームズ]

On 23 October 2014 18:28, Vittorio Beggi (Gmail)
 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-Proposal - preserve freedom of choice of init systems

[Olav Vitters]

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

[Vittorio Beggi (Gmail)]

Ian Jackson's proposal to preserve freedom of choice of init systems 
.


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: Re-Proposal - preserve freedom of choice of init systems

[Lars Wirzenius]

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

[Ritesh Raj Sarraf]

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

[Olav Vitters]

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: Re-Proposal - preserve freedom of choice of init systems

[Svante Signell]

(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-Proposal - preserve freedom of choice of init systems

[Neil McGovern]

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

[Sergey Vlasov]

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  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

[Andy Smith]

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-Proposal - preserve freedom of choice of init systems

[ss-composer]

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

[Tobias Frost]

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

[Francisco Gonzalez Flores]

-- 
L.S.C.A. Francisco González Flores
Redes y Comunicaciones
CDE PRI Chihuahua

Re: Re-Proposal - preserve freedom of choice of init systems

[Sergey Vlasov]

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

[Ian Jackson]

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: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)

[Neil McGovern]

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

[ss-composer]

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: Re-Proposal - preserve freedom of choice of init systems

[Joey Hess]

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: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)

[Alessio Treglia]

On Mon, Oct 20, 2014 at 11:55 AM, Ian Jackson
 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: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)

[Ian Jackson]

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: Re: Re-Proposal - preserve freedom of choice of init systems

[Steve Langasek]

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

Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)

[Ian Jackson]

-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

[Aigars Mahinovs]

On 17 October 2014 20:07, Ian Jackson  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

Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)

[Alessio Treglia]

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

[quixote]

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 , Acid Test 

Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)

[Ian Jackson]

-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

[Ian Jackson]

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

Re: Re-Proposal - preserve freedom of choice of init systems

[Vincent Blut]

Le dim. 19 oct. 2014 à 10:54, John James 
 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

[John James]

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

[Paul Wise]

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

[Kurt Roeckx]

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

[Stefano Zacchiroli]

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: Re-Proposal - preserve freedom of choice of init systems

[Jonathan de Boyne Pollard]

Daniel Kahn Gillmor:

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.

Ian Jackson:

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.

Daniel Kahn Gillmor:

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.

Ian Jackson:

Are you saying that a daemon  author would want to write code which

> only worked if runit was pid 1 ?

Daniel Kahn Gillmor:

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.

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?


* https://lists.debian.org/debian-vote/2014/03/msg00103.html
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747742

Requiring that people be bootstrap system neutral has perhaps unintended 
consequences, one of which is disappointing the spectators (in the press 
and on other mailing lists) who mistakenly thought that M. Jackson was 
championing the System V init status quo ante.  Proper neutrality, it 
turns out once one sits down and actually looks at it, makes work for 
the maintainers of old softwares that only work with System V init, 
too.  M. Jackson, perhaps unintentionally, is pushing in the final nail 
in the coffin of /etc/inittab .  (-:



--
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/5441cff1.4020...@ntlworld.com

Re: Re-Proposal - preserve freedom of choice of init systems

[Jonas Smedegaard]

Quoting Ansgar Burchardt (2014-10-17 22:34:31)
> Simon Richter  writes:
>> On 17.10.2014 16:54, Daniel Kahn Gillmor 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.
>>
>> The implication of not making sure packages get along with each other 
>> may be that system administrators need to decide which of the 
>> mutually exclusive desktop systems they can offer their users.
>
> That's however not what the proposal forbids: A can depend on 
> init-A|init-B, B can depend on init-B|init-C and C can depend on 
> init-C|init-A. There's no way to install both A, B and C.

The proposal is indeed possible to misinterpret of you really want to. 
As Lucas pointed out earlier, other misinterpretations are possible too.

Suggestions for improvements, while preserving readability and intent, 
are quite welcome.


>> No, but I think we should reject packages that are mutually exclusive 
>> with unrelated packages because they require incompatible choices of 
>> packages they depend on.
>
> Again, this does seem to be a different issue than what the GR 
> proposes.

Different but related: Simon describes a broader pattern where init 
systems play a part but is not the only part.  This GR is limited to the 
init issue.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Re-Proposal - preserve freedom of choice of init systems

[parspes]

 I also agree with this proposal. Currently several packages cannot be
upgraded without including libsystemd-* something, and I have
experienced several installation issues with packages from Testing and
the reccommended alternatative package systemd-shim.

Stefano Zacchiroli writes ("Re: Re-Proposal - preserve freedom of
choice of init systems"):
> Specifically: have you, or anyone else involved in this GR, asked the
> GNOME team and the release team, whether a positive outcome of this GR
> is going to disrupt their work (plans) or not?

No, I have not.

I am not aware of any underlying bugs in (say) gnome-without-systemd
that would be RC.  But the sentiment behind this GR is that any such
bugs should be considered indeed RC for the whole project.

...

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/CANdXYChd5=zpwrnrknp89gwt8rlry26gqhqejhxgh0pzky4...@mail.gmail.com

Re: Re-Proposal - preserve freedom of choice of init systems

[Craig Sanders]

Jonathan Wiltshire  wrote:
> I'm really glad you think there is no work to be done between now and
> release.

try being at least minimally honest in your argument. 

i didn't say that no work at all was necessary for the release. i was
responding to the claim that this GR isn't necessary because debian is
already compliant with it.


dishonest "debating" like this (i.e. petty ego-wankers like you
point-scoring by malicious twisting of words and selective misquoting),
is why i haven't bothered for years. i should have remembered that i
have better things to do with my time.

craig

-- 
craig sanders 


-- 
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/20141017235245.gi4...@taz.net.au

Re: Re-Proposal - preserve freedom of choice of init systems

[Dimitri John Ledkov]

On 17 October 2014 23:19, Simon Richter  wrote:
> Hi,
>
> On 17.10.2014 22:13, Ansgar Burchardt wrote:
>
>> I note that it was *not* possible to switch init systems in Wheezy in a
>> supported way (in particular sysvinit is essential and various things
>> get very unhappy if it gets uninstalled), but you seem to treat Jessie
>> as more problematic even though it allows switching init systems? How
>> come?
>
> I applaud the possibility to switch init systems.
>
>> And is "you cannot switch init systems (at all)" to "you cannot
>> switch init systems if you want to run " a regression that takes away
>> choice?
>
> The regression comes in two forms:
>
> 1. "a package that is a dependency of a package that is a recommendation
> of a dependency of  requires the init system to be ".
>
> This requires manual intervention by the user if they do not want to
> switch init system. My laptop moved to systemd because I installed a
> Japanese input method which uses GTK, which depends on libcolord, which
> recommends colord, which indirectly depends on systemd.
>

>From multiarch and cross-building point of view library package must
not depend, and should not recommend, equivalent executable / runtime
packages.
(Although I can see the reasons behind marking colord m-a:foreign &
libcolord m-a:same with dependencies declared as they are now)

Also I think if "depends" exist one way between two packages, a
reverse "recommends" should not be allowed.

> No part of the chain is wrong. The strong dependencies are libraries in
> DT_NEEDED, so they cannot be easily demoted, and the libcolord -> colord
> recommendation also makes sense. The end result, however, is that
> installation of an application package may require extensive changes to
> the core system or manual intervention by the user, overriding the
> package manager.
>
> 2. "the init system required to run  is mutually exclusive with the
> init system required to run ."
>
> This is at present purely academic, but I'm not convinced it will remain
> this way. We also ship a desktop environment aimed at less powerful
> hardware, would we be okay if that system used a different network
> configuration subsystem conflicting with systemd?
>
>  - If yes, what should system administrators wishing to offer their
> users a choice of environment do?
>
>  - If no, why would it be acceptable for one system to do so, but not
> for the other?
>
> I'd rather avoid these problems in the first place.
>
> We have a sensible default in place for desktop users, who are the ones
> in need of a default setting.
>
> However I believe that systemd is not ideal for server environments
> (where we'd rather have minimal attack surface rather than features) and
> downright unusable for embedded applications where memory is scarce, and
> thus I find it very important that the package manager *never*
> second-guesses my choice of init system because of a dependency.
>
>Simon
>

-- 
Regards,

Dimitri.


-- 
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/canbhlujqi9ikrux7nuk_tcwsy0vjsu8vzy5lnc5etef2uz8...@mail.gmail.com

Re: Re-Proposal - preserve freedom of choice of init systems

[Simon Richter]

Hi,

On 17.10.2014 22:13, Ansgar Burchardt wrote:

> I note that it was *not* possible to switch init systems in Wheezy in a
> supported way (in particular sysvinit is essential and various things
> get very unhappy if it gets uninstalled), but you seem to treat Jessie
> as more problematic even though it allows switching init systems? How
> come?

I applaud the possibility to switch init systems.

> And is "you cannot switch init systems (at all)" to "you cannot
> switch init systems if you want to run " a regression that takes away
> choice?

The regression comes in two forms:

1. "a package that is a dependency of a package that is a recommendation
of a dependency of  requires the init system to be ".

This requires manual intervention by the user if they do not want to
switch init system. My laptop moved to systemd because I installed a
Japanese input method which uses GTK, which depends on libcolord, which
recommends colord, which indirectly depends on systemd.

No part of the chain is wrong. The strong dependencies are libraries in
DT_NEEDED, so they cannot be easily demoted, and the libcolord -> colord
recommendation also makes sense. The end result, however, is that
installation of an application package may require extensive changes to
the core system or manual intervention by the user, overriding the
package manager.

2. "the init system required to run  is mutually exclusive with the
init system required to run ."

This is at present purely academic, but I'm not convinced it will remain
this way. We also ship a desktop environment aimed at less powerful
hardware, would we be okay if that system used a different network
configuration subsystem conflicting with systemd?

 - If yes, what should system administrators wishing to offer their
users a choice of environment do?

 - If no, why would it be acceptable for one system to do so, but not
for the other?

I'd rather avoid these problems in the first place.

We have a sensible default in place for desktop users, who are the ones
in need of a default setting.

However I believe that systemd is not ideal for server environments
(where we'd rather have minimal attack surface rather than features) and
downright unusable for embedded applications where memory is scarce, and
thus I find it very important that the package manager *never*
second-guesses my choice of init system because of a dependency.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Re-Proposal - preserve freedom of choice of init systems

[Jonathan Wiltshire]

On 2014-10-17 22:04, Craig Sanders wrote:

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?


because right now when NO work needs to be done is the perfect time to
get this clarified. if we wait until there is a huge amount of work to
be done then it will be impossible (or, at least, declared impossible).


I'm really glad you think there is no work to be done between now and 
release. You should ask my fiance how much time I have for her right 
now.



--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 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/9ef45c0e51b563a9c4768e2910f17...@hogwarts.powdarrmonkey.net

Re: Re-Proposal - preserve freedom of choice of init systems

[Craig Sanders]

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?

because right now when NO work needs to be done is the perfect time to
get this clarified. if we wait until there is a huge amount of work to
be done then it will be impossible (or, at least, declared impossible).

it's generally best to avoid causing damage in the first place than to
cause it and then have to undo it.

and, btw, it's not just about gnome. many other packages, including
xfce, have or are gaining dependencies that could trigger an unwanted
conversion to systemd if the user is not extremely careful - which is
part of the point of this GR...if software like gnome and xfce depend on
systemd then any claims that systemd in jessie is "only the default, the
user can choose something else" are worthless hot air.

> If you don't like upstreams choices, *you* should write patches. Not GRs 
> telling other people to do so.

in other words:

I couldn't be bothered making my packages compliant with debian
policy. my packages are such special unique snowflakes that policy
is irrelevant. if you think that's a bug, then you have to supply
the patches to fix it and not tell other people to do so.

craig

-- 
craig sanders 


-- 
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/20141017210418.gh4...@taz.net.au

Re: Re-Proposal - preserve freedom of choice of init systems

[Ansgar Burchardt]

Hi Ian,

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.

Ansgar


-- 
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/87bnpawhml@deep-thought.43-1.org

Re: Re-Proposal - preserve freedom of choice of init systems

[Ansgar Burchardt]

Simon Richter  writes:
> On 17.10.2014 16:54, Daniel Kahn Gillmor 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.
>
> The implication of not making sure packages get along with each other
> may be that system administrators need to decide which of the mutually
> exclusive desktop systems they can offer their users.

That's however not what the proposal forbids: A can depend on
init-A|init-B, B can depend on init-B|init-C and C can depend on
init-C|init-A. There's no way to install both A, B and C.

> No, but I think we should reject packages that are mutually exclusive
> with unrelated packages because they require incompatible choices of
> packages they depend on.

Again, this does seem to be a different issue than what the GR proposes.

Ansgar


-- 
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/87y4sezb8o@deep-thought.43-1.org

Re: Re-Proposal - preserve freedom of choice of init systems

[Didier 'OdyX' Raboud]

Le vendredi, 17 octobre 2014, 19.50:22 Jonas Smedegaard a écrit :
> We need the GR to ensure situation stays good.  No big deal.

That's the fundamental crux of the disagreement I think: A GR will _not_ 
automagically generate upstream attention for non-systemd support. 
Point.

If your "good" situation is a situation where non-systemd setups 
continue to work, what's needed to ensure it stays so is "people putting 
up the work everywhere needed", _not_ a GR (which is "people have stated 
a collective opinion").

Post-Jessie, trying to coerce sysvinit maintenance burden on maintainers 
is directly against §2.1.1 of our constitution; trying to coerce 
sysvinit maintenance burden on upstreams will simply not happen, no 
matter how many GRs we might pass in that hope.

Cheers,
OdyX


--
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/11311148.CxcO47Piez@gyllingar

Re: Re-Proposal - preserve freedom of choice of init systems

[Simon Richter]

Hi,

On 17.10.2014 16:54, Daniel Kahn Gillmor 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.

The implication of not making sure packages get along with each other
may be that system administrators need to decide which of the mutually
exclusive desktop systems they can offer their users.

> 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.

No, but I think we should reject packages that are mutually exclusive
with unrelated packages because they require incompatible choices of
packages they depend on.

Policy is rather strict on "Conflicts" as an absolute last-resort for
packages that really cannot be co-installed, and it is reserved mostly
for file conflicts between packages with similar functionality. Even the
Provides/Conflicts for "mail-transport-agent" was controversial.

Allowing packages to depend on mutually conflicting packages introduces
conflicts between otherwise unrelated and co-installable packages.

This is what we want to avoid.

   Simon





signature.asc
Description: OpenPGP digital signature

Re: Re-Proposal - preserve freedom of choice of init systems

[Ansgar Burchardt]

Hi,

Simon Richter  writes:
> On 17.10.2014 11:52, Marco d'Itri 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.
>
> No, the majority disregarding the needs of the minority makes it
> controversial.
>
> Debian has always aimed to be the "universal" operating system and be
> inclusive of desktop users, system administrators and system builders at
> the same time.
>
> Debian "jessie" fails to work in several instances on my embedded
> systems where "wheezy" used to work. I'd call that a severe regression,
> however for some reason that no longer counts because the majority has
> no such issues.

Bugs happen with every release...

I note that it was *not* possible to switch init systems in Wheezy in a
supported way (in particular sysvinit is essential and various things
get very unhappy if it gets uninstalled), but you seem to treat Jessie
as more problematic even though it allows switching init systems? How
come?

And is "you cannot switch init systems (at all)" to "you cannot
switch init systems if you want to run " a regression that takes away
choice?

Ansgar


-- 
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/87vbni3152@deep-thought.43-1.org

Re: Re-Proposal - preserve freedom of choice of init systems

[Simon Richter]

Hi,

On 17.10.2014 11:52, Marco d'Itri 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.

No, the majority disregarding the needs of the minority makes it
controversial.

Debian has always aimed to be the "universal" operating system and be
inclusive of desktop users, system administrators and system builders at
the same time.

Debian "jessie" fails to work in several instances on my embedded
systems where "wheezy" used to work. I'd call that a severe regression,
however for some reason that no longer counts because the majority has
no such issues.

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.

The "us vs them" attitude has permeated both camps by now, and the only
way out I can see is to find a solution that allows both sides to
install the solution that works best for them, without sacrificing too
much functionality.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Re-Proposal - preserve freedom of choice of init systems

[Kurt Roeckx]

On Fri, Oct 17, 2014 at 07:14:13PM +0100, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Re-Proposal - preserve freedom of choice of init 
> systems"):
> > I think those 2 conflict, and that if you want to use the TC
> > powers it would fall under 4.1.4.
> 
> Kurt, we had that conversation in March.  Can you please go back and
> read the thread then ?  After that extended conversation, you wrote
> this, which ended the subthread:

So let's just assume for now that I would 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/20141017191406.ga18...@roeckx.be

Re: Re-Proposal - preserve freedom of choice of init systems

[Ian Jackson]

Kurt Roeckx writes ("Re: Re-Proposal - preserve freedom of choice of init 
systems"):
> I think those 2 conflict, and that if you want to use the TC
> powers it would fall under 4.1.4.

Kurt, we had that conversation in March.  Can you please go back and
read the thread then ?  After that extended conversation, you wrote
this, which ended the subthread:

  From: Kurt Roeckx 
  To: Ian Jackson 
  Cc: debian-vote@lists.debian.org, debian-proj...@lists.debian.org
  Subject: Re: Proposal - preserve freedom of choice of init systems
  Date: Mon, 3 Mar 2014 22:05:32 +0100

  On Mon, Mar 03, 2014 at 11:39:40AM +, Ian Jackson wrote:
  [...]
  > Does that mean that you are now tending towards the view that
  > Matthew's proposal requires only a simple 1:1 majority ?

  Yes.

  Kurt

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.23669.46326.679...@chiark.greenend.org.uk

Re: Re-Proposal - preserve freedom of choice of init systems

[Kurt Roeckx]

On Thu, Oct 16, 2014 at 04:05:41PM +0100, Ian Jackson wrote:
> 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:
[...]
> 3. Notes and rubric
> 
>   This resolution is a Position Statement about Issues of the Day
>   (Constitution 4.1.5)

I think those 2 conflict, and that if you want to use the TC
powers it would fall under 4.1.4.


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/20141017180549.ga16...@roeckx.be

Re: Re-Proposal - preserve freedom of choice of init systems

[Jonas Smedegaard]

Quoting Daniel Kahn Gillmor (2014-10-17 18:38:35)
> On 10/17/2014 12:06 PM, Ian Jackson wrote:
>> 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?

We need the GR to ensure situation stays good.  No big deal.


> I'm going to stop commenting on this thread now and try to fix some 
> bugs that need fixing before the freeze.

Me too :-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Re: Re-Proposal - preserve freedom of choice of init systems

[Adam D. Barratt]

On Fri, 2014-10-17 at 13:15 -0400, Miles Fidelman wrote:
> The TC stated, and passed a resolution to the effect of Debian 
> continuing to support multiple init systems.  If, as you say, "Gnome 
> right now is installable with systemd-shim + sysvinit,"  those sound 
> like release critical bugs in Gnome and/or systemd-shim - and precisely 
> a reason to resolve this issue now, not kick it down the road.

I think you may be confused about what Holger wrote. You appear to be
arguing that *things working* is a 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/1413568133.2260.27.ca...@adam-barratt.org.uk

Re: Re-Proposal - preserve freedom of choice of init systems

[Kurt Roeckx]

On Fri, Oct 17, 2014 at 04:05:20PM +0900, Arnaud Fontaine wrote:
> Seconded.

This seems to be signed with a key that is not in the keyring.


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/20141017172745.ga10...@roeckx.be

Re: Re: Re-Proposal - preserve freedom of choice of init systems

[Miles Fidelman]

Holger Levsen mailto:holger%40layer-acht.org>> 
wrote:



Hi,

On Donnerstag, 16. Oktober 2014, 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.

Exactly.

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?


That's an awfully good reason FOR pushing the GR now.

The TC stated, and passed a resolution to the effect of Debian 
continuing to support multiple init systems.  If, as you say, "Gnome 
right now is installable with systemd-shim + sysvinit,"  those sound 
like release critical bugs in Gnome and/or systemd-shim - and precisely 
a reason to resolve this issue now, not kick it down the road.


This is a GR based on rumors, which is very sad.


Some us us want to continue to run production servers, w/o having major 
changes foisted on our systems - which, at the very least, will require 
significant testing, and possibly reconfiguration.


Breaking backwards compatibility is big deal.

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
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/54414eb9.9040...@meetinghouse.net

Re: Re-Proposal - preserve freedom of choice of init systems

[Thomas Goirand]

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

Re: Re-Proposal - preserve freedom of choice of init systems

[Ian Jackson]

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

[Joey Hess]

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

[Thomas Goirand]

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

[Lucas Nussbaum]

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

[Daniel Kahn Gillmor]

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

[Ian Jackson]

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

[Ian Jackson]

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]

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]

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

[Didier 'OdyX' Raboud]

Le vendredi, 17 octobre 2014, 10.00:59 Ean Schuessler a écrit :
> - "Holger Levsen"  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

[Daniel Kahn Gillmor]

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

[Ian Jackson]

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

[Ian Jackson]

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

[Matthias Urlichs]

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

[Ean Schuessler]

- "Holger Levsen"  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

[Daniel Kahn Gillmor]

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

[Joey Hess]

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

[Joey Hess]

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]

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

[Ian Jackson]

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

[Miguel Landaeta]

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

[Olav Vitters]

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

[Ritesh Raj Sarraf]

On Friday 17 October 2014 06:27 PM, Aigars Mahinovs wrote:
> On 17 October 2014 15:53, 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.
> 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

[Stefano Zacchiroli]

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

[Aigars Mahinovs]

On 17 October 2014 15:53, 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.

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

[Ritesh Raj Sarraf]

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

[Adam D. Barratt]

On 2014-10-17 12:00, Aigars Mahinovs wrote:

On 17 October 2014 13:27, Matthias Urlichs  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

[Olav Vitters]

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

[Olav Vitters]

On Fri, Oct 17, 2014 at 02:19:38PM +0530, Ritesh Raj Sarraf wrote:
> 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.

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.

-- 
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/20141017114020.gb5...@bkor.dhs.org

Re: Re-Proposal - preserve freedom of choice of init systems

[Olav Vitters]

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

[Florian Lohoff]

Hi,

On Fri, Oct 17, 2014 at 01:00:12PM +0200, Marco d'Itri wrote:
> On Oct 17, Florian Lohoff  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...

You say vocal - Before this GR i have send 1 in word ONE mail prior
commenting the systemd issues on any debian mailinglist. Followed
by bug reporting 2 days ago.

So i am neither vocal nor part of any group beeing called minority.

> > 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.

I am not saying its a conspiracy. I dont understand the hurry - For me systemd
came from behind the couch 24 months ago and suddenly its the best invention
since sliced bread. I am just courious about any integral part of my system
beeing rewritten in a revolutionary way and people beeing very loud about it
beeing the best thing ever happened. 

Its the same with people telling me their hash has no collisions or their
crypto is unbreakable - Curiosity should apply to all technical decisions
and i say this has not been done with systemd. Nobody thought of the 
consequences
it causes using all those little bells and whistles systemd brought with it.
As we discovered the last months its basically impossible already to dissect
systemd from any debian system. You end up with a handful of systemd-
daemons doings thing like presenting the hostname via DBUS (WTF?) and stuff.

I dont like this trend - systemd already mixes beeing pid 1 and beeing an
aglomerated blob of nearly ANY low level functionality any unix system needs 
like
syslog, timekeeping etc.

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature

Re: Re-Proposal - preserve freedom of choice of init systems

[Stefano Zacchiroli]

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

[Matthew Vernon]

Jonathan Dowland  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