Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

[Nikolaus Rath]

>> Policy 6.1 says
>> | Programs called from maintainer scripts should not normally have a
>> | path prepended to them.
>>
>> Ie, programs that are on PATH should be found via the PATH rather than
>> by hardcoding /usr/bin/foo or whatever.  In general, I think we
>> normally, at least in software written specifically for Debian, apply
>> this not just to maintainer scripts but to all program execution.
>
> I agree that it's a common practice for software written specifically
> for Debian.  I'm not convinced it's a common practice elsewhere, and i'm
> definitely not convinced that we should mandate divergence from upstream
> for this purpose.

Just as a datapoint, in other communities there is actually a trend in
the opposite direction. For example, for the Python ecosystem there is
an increasing drive to establish a "system Python" that ignores Python
modules in /usr/local and $PYTHONPATH, specifically to avoid potential
interference of user installed modules with distribution Python scripts.

I have a lot of sympathie for this idea, and I think it would be good to
keep this in mind when discussing potential clarifications of policy.


Best,
Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#841294: Overrule maitainer of "global" to package a new upstream version

[Nikolaus Rath]

On Dec 05 2016, Ron  wrote:
> Hi Sam,
>
> On Wed, Nov 30, 2016 at 11:39:08AM -0500, Sam Hartman wrote:
>> > "Ron" == Ron   writes:
>> 
>> Ron> Hi OdyX,
>> 
>> Ron> On Wed, Nov 16, 2016 at 03:23:47PM +0100, Didier 'OdyX' Raboud 
>> wrote:
>> >> Hi there,
>> >> 
>> >> I've been mostly VAC, and only now found enough time to properly
>> >> read through this bug log. In the interest of transparency and to
>> >> help the TC reach a consensus (also through understanding what
>> >> the other members' understanding, ideas and positions are), here
>> >> comes my current understanding of the problem at hand.
>> >> 
>> >> As preamble, I will upfront state that I have _not_ looked in the
>> >> precise details of the so-called 'htags' functionality, as, the
>> >> rest will show, my current viewpoint on the problem is that it
>> >> doesn't matter.
>> 
>> Ron> If we run with your proposal, what are you actually suggesting
>> Ron> we tell the people who'd be upset by the loss of htags without
>> Ron> notice in Stretch?  Because I don't really see how you've
>> Ron> addressed that here.
>> 
>> Ron, thanks for working with the process.
>
> Thanks for engaging with the question :)
>
> I was a little disappointed that all OdyX had to say about it was:
>
>   I've sent a long mail with my opinion, and Ron's answer hasn't
> altered my conviction yet.
>
> Because "lalala, I'm not listening" isn't really an answer to a simple
> direct question.  And definitely not something that I can wrap with
> "Sorry, but a group of Debian Developers considered this all in careful
> detail, and this is what we have decided", when breaking the news to
> affected people.

...whose existence has only been postulated so far though.

In any case, it seems there are plenty of people who'd be willing to
relieve you of that burden and take over maintenance of global -
including dealing with any fallout from updating to an up-to-date
version.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Nikolaus Rath]

On Nov 07 2016, Ron  wrote:
>> In my opinion, the fact that you had no time for this issue for multiple
>> years, but are now able to send a large number of long emails about it
>> to the ctte does not speak in your favor.
>
> I'm sorry, remind me again about where and what you have ever tried
> to offer that would be of value to resolving this which I didn't
> respond to?
>
> Because I've had countless detailed discussions with people who have,
> and I don't recall you ever being part of any of that.

[...]

> I've taken the time to repeat this all again now, because regardless
> of how it got here, I actually have some faith in the new face of the
> TC as a forum for building 'project wide' consensus around hard problems.
> Having read all of that, Phil has now asked me to propose a concrete
> alternative to what he suggested, which I did. And I think the important
> difference is that we have the opportunity to build a consensus here
> which includes a good proportion of impartial and non-partisan voices who
> weighed up all the options like I've been doing.

It seems you're only interested in impartial and non-partisan voices
when they happen to back your position. I am impartial and non-partisan,
and formed my opinion by reading the bugs and your emails. If you indeed
welcome opinions from people like me, your statements above are a little
odd.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Nikolaus Rath]

On Nov 06 2016, Ron  wrote:
> On Thu, Nov 03, 2016 at 09:20:30AM +0100, Philip Hands wrote:
>> Ron  writes:
>> >
>> > I can try to clarify that if there's a question in your mind that
>> > you don't think I touched on there.
>> 
>> The question that remains is what you actually intend to do.
>
> Nod.  So far here, I've mostly tried to stick to just outlining the
> facts we have to deal with, and the options I think we have and the
> pros and cons of them - because I don't have a preconceived answer
> to that which I'm welded to, and I was more interesting in listening
> to well considered comments that people might have had than turning
> this into a mindless tug of war between two inflexible positions.

It's too bad that you only started doing this after this was escalated
to the CTTE. Had you responded at such length and with so little delay
to the earlier bug reports, the situation would be very different. But
now, your sudden communicativeness just has the opposite effect.

In my opinion, the fact that you had no time for this issue for multiple
years, but are now able to send a large number of long emails about it
to the ctte does not speak in your favor.


Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Bug#797533: New CTTE members

[Nikolaus Rath]

On Sep 09 2015, Steve Langasek  wrote:
> On Wed, Sep 09, 2015 at 05:30:03PM +0100, Wookey wrote:
>
>> So what I learned from this is that, as currently operating, the
>> committee is incapable of making quick 'overrule unreasonableness'
>> decisions. My overriding impression was that those involved simply did
>> not have the time available that would be be needed to enable that.
>
> No, what you see here is that the TC did not agree with you that the
> maintainer's action was unambiguously unreasonable under the
> circumstances.

Is that disagreement captured somewhere? Looking at #766708, the bug was
filed on Oct 26th and from then until Dec 16th (at which point it was
too late for jessie) we have the following emails from ctte members:

- one email from Don asking Matthias for more information (but he got no
  reply).

- one email from Ian (who, according to his later emails was certainly
  not opposed to overwriting the maintainer)

- One question from Colin that I can't interpret as either agreement or
  disagreement, but it was answered by Wookey and got no further
  response.

- One skeptical question from Don on Nov 19th

- Another email from Don about long-term consequences that he explicitly
  says is not related to the jessie decision


So the only mail that could be interpreted to signal disagreement in the
ctte is this one:

,
| From: Don Armstrong 
| To: Helmut Grohne , 766...@bugs.debian.org, Debian GCC 
Maintainers , woo...@debian.org
| Subject: Re: Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross 
building
| Date: Wed, 19 Nov 2014 16:41:49 -0800
| 
| On Tue, 28 Oct 2014, Helmut Grohne wrote:
| > I have to admit that the code is not exactly lightweight. I do
| > understand the desire to get rid it and asked that a ctte ruling does
| > not apply beyond jessie for that reason.
| 
| Are people who are doing cross-building like this actually using the
| code which will be in jessie? I (perhaps naïvely) would expect them to
| be primarily using the code in unstable, and maybe at a late stage of
| bring-up rebuilding all of stable.
`


Note that only three members of the ctte actually voiced anything at
all. To me this looks a lot more like the ctte not having enough time
rather than the ctte being stuck in some intractable technical
disagreement that prevents them from taking any action.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Nikolaus Rath]

On Aug 31 2015, Sam Hartman  wrote:
> OK.
> I'd really appreciate hearing from anyone now who needs more time before
> a CFV.

Please don't forget that if anyone needs more time, they can always vote
FD.

Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#741573: Comparison of Options AB and D

[Nikolaus Rath]

On Aug 30 2015, Sam Hartman hartm...@debian.org wrote:
 Nikolaus == Nikolaus Rath nikol...@rath.org writes:

 Nikolaus On Aug 29 2015, Sam Hartman hartm...@debian.org wrote:
  Option D goes further.  Option D requires that packages drop
  their traditional menu entries if they ship .desktop files.
  (That's done on a per-application not per-package basis).

 Nikolaus That would be a pretty ridiculous situation. So package
 Nikolaus maintainers would be free to ship .desktop files as well
 Nikolaus menu files for their favorite third menu system, but they
 Nikolaus *must not* ship menu files for the traditional debian
 Nikolaus menu?

 correct.

 Nikolaus Surely there is no need to single out the traditional menu
 Nikolaus as something that must not be used. It's sufficient if
 Nikolaus policy mandates the use of .desktop files, anything beyond
 Nikolaus that ought to be entirely up to the maintainer.

 I think the argument in favor of this need is that we're trying to force
 a transition of the traditional menu to .desktop as a metadata format.

Indeed. The question is why.

A. This comes very close to design work which the CTTE should not be
   doing. If there's a conflict between two crappy designs and the CTTE
   is asked to rule, then you should pick the less crappy one or decline
   to rule, not create an entirely new design.

   Having a central design body for Debian may not actually be a bad
   idea, but experience (as from this bug) has shown that the CTTE does
   not have the necessary manpower.

B. Even if the CTTE were supposed to do design work, or if this clearly
   was not design work, it's still not what the CTTE has been asked. You
   were asked to override a maintainer.

C. Even if you were supposed to do design work, and had been asked to do
   so in this case, who would actually benefit from a forced transition?

   - It's certainly not the current users of the traditional menu. In
 the short term there worse off (because the menu will become
 smaller), and in the long term they can write a converter to matter
 if there's a forced transition or not.

   - It's probably not the users of .desktop files either (they don't
 want all the additional entries).

   - It's also not the maintainers (if shipping traditional menu files
 is a burden, they can stop doing so even if policy doesn't force
 them to remove them).

   So who is benefitting?

D. Even if you were supposed to do design work, were asked to do so in
   this case, and I forget someone who benefits from this forced
   transition, was it really worth delaying a decision for more than a
   year and a release cycle? It's not that overruling Bill a year ago
   would somehow made a forced transition later on impossible.


I think a lot of things went wrong here.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Bug#741573: Comparison of Options AB and D

[Nikolaus Rath]

On Aug 30 2015, Sam Hartman hartm...@debian.org wrote:
 if you actually want the TC to only
 choose with no comment from the options before it; if you want us not to
 raise objections and actually set policy as we are charged with in the
 constitution, 

There is an (important) difference between set policy and create
policy. I object to the latter, not the former.

I am not sure what you mean with raising objections. Do you mean this
as some sort of formal task? I don't think this is anything that the
constitution charges the ctte with. Or do mean that you just want to
share your personal objections to something as a ctte member? I
certainly don't object to that.

Though, in any case, I think that:

 then you will find absolutely no one willing to serve on
 the TC.

is a rather strong statement. It's easily disproven by finding someone,
and I'm pretty sure that you haven't asked everyone. As a matter of
fact, judging from the different kinds and levels of (publicly visible)
activity of the sitting ctte members, I would expect that at least some
of them would be willing to continue to serve in a ctte that uses its
powers a little less creatively[1].

(Replying to ctte list only, this isn't relevant to the bug at hand
anymore).

Best,
-Nikolaus

[1] No negative connotation implied. I mean creative in the sense of
not just picking between the presented options.

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#741573: #741573: Menu Policy and Consensus

[Nikolaus Rath]

On Aug 28 2015, Ian Jackson ijack...@chiark.greenend.org.uk wrote:
[ things about the menu system ]

This really has become a farce. This issue been open for more than a
year. Sam rephrased the entire issue earlier this year in terms of
consensus and has just finished his analysis. And now it seems the
discussion is restarting again from the point where it started last
year.

It seems to me that the TC members have become very hesitant to call for
a vote until there is internal conesus. I think this is a laudable goal
when it can be achieved. But in this case this doesn't seem possible, so
it just results in endless discussion.  Please just vote. Almost any
outcome (and certainly all the potential vote options that have been
proposed) are better than discussing something for more than a year.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#741573: #741573: Menu Policy and Consensus

[Nikolaus Rath]

On Aug 28 2015, Sam Hartman hartm...@debian.org wrote:
 Nikolaus == Nikolaus Rath nikol...@rath.org writes:

 Nikolaus On Aug 28 2015, Ian Jackson ijack...@chiark.greenend.org.uk 
 wrote:
 Nikolaus [ things about the menu system ]

 Nikolaus This really has become a farce. This issue been open for
 Nikolaus more than a year. Sam rephrased the entire issue earlier
 Nikolaus this year in terms of consensus and has just finished his
 Nikolaus analysis. And now it seems the discussion is restarting
 Nikolaus again from the point where it started last year.

 My understanding is that we're going to make a minor revision to option
 D and vote.  Steve and Don wanted to see option D on the ballot, and
 Keith is incorporating some of my feedback.

 I don't think this discussion is what is blocking progress; I think
 we're just waiting on Keith at this point, and some other TC members
 including myself have agreed to help out if he gets busy.

Maybe discussion was the wrong word. What I mean is that for more than
one year, any vote on this bug was prevented by the TC waiting for any
one of its members to catch up on the discussion, articulate his
concerns, write down a counter-proposal or refine their own
proposal. What I'm saying is that here the perfect is the enemy of the
good. You could have held a vote with three options (conses achieved +
override Bill, consenus not achieved + agree with Bill, further
discussion) within days of receiving this bug, and most likely would
have been able to resolve it. 


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#762194: Initial draft of affirming transition to systemd as default for #762194

[Nikolaus Rath]

[ Resending to bug address rather than just ctte list ]

Don Armstrong d...@debian.org writes:
 On Wed, 10 Dec 2014, Nikolaus Rath wrote:

 Don Armstrong d...@debian.org writes:
  4. The CTTE appreciates the effort of Debian contributors to mitigate
 any issues with the transition by:
 
 a) Providing a fallback boot entry for sysvinit when systemd is the
 default init in grub (#757298)
 
 b) Developing a mechanism to warn on non-standard inittab
 configurations which are unsupported in systemd.
 
 Does this deliberately say just inittab instead of something like
 non-compatible configurations?

 Yes.

 I believe (and hope) that similar mechanism are planned in particular
 for fstab and crypttab.

 It would be awesome if they are; I'd like to point to specific bugs for
 these if you're aware of them. [My motivation here is to try to get
 people who have these kinds of setups to participate in those bugs.]

Not sure if I understand you correctly, because they're easy enough to
find. But anyway, here are some examples:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751707
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771492
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747258
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765594

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87tx11xv57@vostro.rath.org

Re: Bug#762194: Initial draft of affirming transition to systemd as default for #762194

[Nikolaus Rath]

Don Armstrong d...@debian.org writes:
 On Wed, 10 Dec 2014, Nikolaus Rath wrote:

 Don Armstrong d...@debian.org writes:
  4. The CTTE appreciates the effort of Debian contributors to mitigate
 any issues with the transition by:
 
 a) Providing a fallback boot entry for sysvinit when systemd is the
 default init in grub (#757298)
 
 b) Developing a mechanism to warn on non-standard inittab
 configurations which are unsupported in systemd.
 
 Does this deliberately say just inittab instead of something like
 non-compatible configurations?

 Yes.

 I believe (and hope) that similar mechanism are planned in particular
 for fstab and crypttab.

 It would be awesome if they are; I'd like to point to specific bugs for
 these if you're aware of them. [My motivation here is to try to get
 people who have these kinds of setups to participate in those bugs.]

Not sure if I understand you correctly, because they're easy enough to
find. But anyway, here are some examples:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751707
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771492
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747258
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765594

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wq5xxv6g@vostro.rath.org

Bug#762194: Initial draft of affirming transition to systemd as default for #762194

[Nikolaus Rath]

Don Armstrong d...@debian.org writes:
 4. The CTTE appreciates the effort of Debian contributors to mitigate
any issues with the transition by:

a) Providing a fallback boot entry for sysvinit when systemd is the
default init in grub (#757298)

b) Developing a mechanism to warn on non-standard inittab
configurations which are unsupported in systemd.

Does this deliberately say just inittab instead of something like
non-compatible configurations? I believe (and hope) that similar
mechanism are planned in particular for fstab and crypttab.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjauyfqk@vostro.rath.org

Re: please stop

[Nikolaus Rath]

Steve Langasek vor...@debian.org writes:
 On Sat, Nov 08, 2014 at 07:49:10PM -0800, Nikolaus Rath wrote:
 Joey Hess jo...@debian.org writes:
  I'll add that the ctte is rubber-stamping Ian's wording, when that went
  *so* well last time.

 I believe this issue is at least partly caused by the fact that the work
 of the tech ctte has, for the last two years or so, been effectively
 split between just two people: Ian is drafting resolutions, and Russ is
 discussing with involved parties to better understand the situations. As
 far as I can tell, the activity of the rest of the committee is
 restricted to voting and the occasional presence at the IRC meetings.

 In any case, as someone who has spent many long hours dealing with TC
 business over the past two years, I categorically reject this
 characterization that only two people are doing the work of the committee. 

I'm happy to hear that. I should have said that it /seems/ to be split
up mostly between Ian and Russ.

Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87mw7wc4xb@kosh.rath.org

Re: please stop

[Nikolaus Rath]

Joey Hess jo...@debian.org writes:
 I'll add that the ctte is rubber-stamping Ian's wording, when that went
 *so* well last time.

I believe this issue is at least partly caused by the fact that the work
of the tech ctte has, for the last two years or so, been effectively
split between just two people: Ian is drafting resolutions, and Russ is
discussing with involved parties to better understand the situations. As
far as I can tell, the activity of the rest of the committee is
restricted to voting and the occasional presence at the IRC meetings.

I don't think anyone should be critized for that individually, the ctte
members are doing volunteer jobs like everyone else in Debian. However,
I think institutionally this is a bit of a problem, because this is not
how the ctte was intended to function.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/545ee436.7060...@rath.org

Bug#741573: Two menu systems

[Nikolaus Rath]

Keith Packard kei...@keithp.com writes:
  1. Implement .desktop parsing support in the existing 'menu' package so
 that packages providing only .desktop files would be incorporated
 into menu programs without further change.


FWIW, it seems there is at least partial support for that already. At
least on my testing system, there is:

NAME
   desktop2menu - create a menu file skeleton from a desktop file

SYNOPSIS
   desktop2menu --help|--version

   desktop2menu desktop file [package name]

DESCRIPTION
   desktop2menu generates a skeleton menu file from the supplied
   freedesktop.org desktop file.

   The package name to be used in the menu file may be passed as an
   additional argument. If it is not supplied then desktop2menu will
   attempt to derive the package name from the data in the desktop file.

LICENSE
   This program is Copyright (C) 2007 by Sune Vuorela
   deb...@pusling.com. It was modified by Adam D. Barratt
   a...@adam-barratt.org.uk for the devscripts package.  This program
   comes with ABSOLUTELY NO WARRANTY.  You are free to redistribute this
   code under the terms of the GNU General Public License, version 2 or
   later.

AUTHOR
   Sune Vuorela deb...@pusling.com with modifications by Adam D. Barratt
   a...@adam-barratt.org.uk

   
Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a98t1zej@vostro.rath.org

Bug#741573: Please decide on a reversion of commit 3785878 in the Policy's Git repository.

[Nikolaus Rath]

Jonathan Nieder jrnie...@gmail.com writes:
 Charles Plessy wrote:

In particular, in the absence of
 Bill's contribution to the resolution of our conflict, I am asking the TC to
 not discuss the menu systems and focus instead on correcting Bill's
 misbehaviour.

 What is at a stake here is not the Debian Menu system, it is the fact that in
 Debian, it takes 5 minutes for one person to block one year of effort and
 patience from multiple other persons.

 Please take a step back, breathe, and remember that people on the policy
 team probably have good intentions when doing their work.

I'm pretty sure Charles knows this very well, but good intentions alone
do not justify all (in-)actions done with them. 

 For what it's worth, I think Bill made the right choice in reverting the
 change and trying to find a variant that had consensus.  I don't think
 he acted improperly.

I don't think it's worth much in the context of this bug, but since you
started it, and since I don't want Charles to become even more
frustrated because of additional, vocal after-the-fact opposition like
yours: looking through the discussion I think Bill is blocking other
people's work, and Charles is completely right in his anger. I hope the
ctte will find time for this soon.


Best,
Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/874n0yl0zh@kosh.rath.org

Bug#727708: Additional CTTE Drafting Meeting useful?

[Nikolaus Rath]

Ian Jackson ijack...@chiark.greenend.org.uk writes:
 Ansgar Burchardt writes (Re: Additional CTTE Drafting Meeting useful?):
 In this case I suggest to decide just the question of the default init
 system on Linux architectures first and address further details later if
 no consensus can be found elsewhere. Finding the correct wording then
 should be easier.

 I strongly object to this approach for the reasons I have given
 already.

 If I am given the opportunity to do so, if such a resolution is
 proposed I will always propose amendments to settle the T vs L
 question.

I understand that you don't like the simple vote, because it doesn't
allow you to express that your opinion on the init system depends on the
outcome of the coupling question (or vice versa).

This is all good in theory. In this particular situation, however, I
don't think this is a concern in practice. It seems pretty clear that
the default init system question is going to be decided by Bdale casting
vote. As I think you said yourself, it's not likely that anyones opinion
is going to change at this point.

In other words, the decision for the init system is a given, all that is
necessary is to finally bring it to a formal vote. In practice any
difference in your vote that would depend on the outcome of the coupling
question is not going to affect the result.

It seems that the only effect of adding all the coupling and GR stuff is
to make the ballot more complicated. If adding these options would
somehow result in a clear majority (without the need for a casting vote)
for one default init system, then to me this would look more like an
undesired voting artifact rather than a change in the majority opinion
of the CTTE.

Am I missing something?

Given the apparent challenges to draft an acceptable ballot, I think
Bdale's idea of keeping the vote truly simple should be reconsidered.


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871tzeblb2@rath.org

Bug#727708: Call for votes on init system resolution

[Nikolaus Rath]

Russ Allbery r...@debian.org writes:
 Don Armstrong d...@debian.org writes:
 On Thu, 06 Feb 2014, Kurt Roeckx wrote:

 So let me expand on that a little.  Image the following options
 - A: something that doesn't overrule the ctte (1:1)
 - B: something that does overrule the ctte (2:1)
 - FD

 In this case, I don't know A could be anything but 2:1, baring riders
 from the CTTE. If A is technical, it needs the power of the CTTE under
 §4.1.4 which requires 2:1. [I suppose something could be written which
 would fall under the DPL's remit.]

 As I understand it, we'd like to make everything be 1:1, and the method
 we're trying is to write a proposal in such a way that it automatically
 enshrouds a non-technical statement by the project in the power of the
 CTTE.

 It may be that we can't actually do that, and should instead just have
 an agreement between CTTE members to enact a decision which followed a
 position statement GR under §4.1.5.

 I think what we're trying to say looks something like this:

 If the project holds a GR vote on the topic of the default init
 system, the winning option of that vote replaces this text in its
 entirety and becomes the decision of the Technical Committee.  The
 winning option of the GR vote for this purpose will be decided
 following the normal rules for deciding the outcome of a General
 Resolution, with the exception that the 2:1 majority normally required
 to overule the Technical Committee will not be taken into account.

 I think this works, although it does create the possibility of a rather
 odd situation, and I'm not quite sure how it would work procedurally.
[more complicated stuff snipped]

It is not at all clear to me why the CTTE so desperately wants to
automatically defer to a GR in their resolution. If there is consensus
to defer to a GR with simple majority among the CTTE, surely it would be
easy enough to revoke or change the resolution if/when a GR has actually
happened?


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874n4bll3l@vostro.rath.org

Bug#727708: Vote sysvinit 4 jessie

[Nikolaus Rath]

Michael Gilbert mgilb...@debian.org writes:
 On Mon, Feb 3, 2014 at 11:44 PM, Nikolaus Rath wrote:
 Michael Gilbert writes:
 On Mon, Feb 3, 2014 at 1:42 PM, Steve Langasek wrote:
 So all deferring for another cycle does is leave Debian with annoying
 cumbersome init scripts and unsolvable race conditions for another cycle.

 Which have already been solved for a long time now.

 No, they haven't. Try eg. various combinations of layering md-raid,
 cryptsetup, lvm and btrfs on top of each other. If you feel particularly
 adventurous, add some storage devices that take minutes to initialize or
 need a working network connection (disclaimer: I haven't personally
 tried the latter, but I'm pretty sure it's not going to make things work
 better).

 For use cases like this where sysvinit is insufficient, the user can
 use init-select or whatever to use a newer init that does handle this
 better.

You are not making sense to me. You claimed that race conditions and
bugs in sysvinit have been solved. They have not been solved. So now you
are claiming that *because better init systems exist*, these bugs do not
matter and we should stick with sysvinit?

End of discussion for me here.

Best,
Nikolaus


-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87eh3ia5x5@rath.org

Bug#727708: Vote sysvinit 4 jessie

[Nikolaus Rath]

Michael Gilbert mgilb...@debian.org writes:
 On Mon, Feb 3, 2014 at 1:42 PM, Steve Langasek wrote:
 So all deferring for another cycle does is leave Debian with annoying
 cumbersome init scripts and unsolvable race conditions for another cycle.

 Which have already been solved for a long time now.

No, they haven't. Try eg. various combinations of layering md-raid,
cryptsetup, lvm and btrfs on top of each other. If you feel particularly
adventurous, add some storage devices that take minutes to initialize or
need a working network connection (disclaimer: I haven't personally
tried the latter, but I'm pretty sure it's not going to make things work
better).


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ppn3pjvi@vostro.rath.org

Bug#727708: init system discussion - the highlights (was: Bug#727708: init system gr override - formal resolution proposal)

[Nikolaus Rath]

Bdale Garbee bd...@gag.com writes:
 Ian Jackson ijack...@chiark.greenend.org.uk writes:

 I hereby propose the following resolution:

   1. The Technical Committee does not wish any resolutions it passes
  about the init system question(s) to stand in the face of any
  contrary view expressed by a majority of the Developers in a
  General Resolution.

   2. Accordingly, all TC decisions (past and future) related to init
  systems, which do not specify otherwise, should be read as
  including the following rider:
| This decision is automatically vacated by any contrary
| General Resolution which passes by a simple majority.
| In that case the General Resolution takes effect and
| the whole of this decision is to be taken as withdrawn by the
| TC (i.e. as if the TC had explicitly withdrawn it by a
| subsequent TC resolution).

 Please send comments, or formal amendment proposals, by 2014-01-28
 17:00 UTC.  I will call a vote on some version(s) then.

 I would strongly prefer you time-bound such a resolution.  Burdening all
 *future* technical committees with an exception to the constitution they
 must remember and handle seems unkind.  

Wow, this is amazing.

I'm trying to keep track of all the interesting stuff that has happened
here so far to preserve it for the future. Is there anything noteworthy
that I missed? So far I have (not strictly chronological):

* The Debian CTTE is asked to decide about the default init system for
  Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708)

* Off the 8 CTTE members, 2 are starting to dive down into a technical
  comparison, writing about 98% of all messages sent by ctte members on
  this topic (FIXME: number is just a guess, need to do proper counting)

* One ctte member is appaled by the reaction of the systemd developers
  and maintainers to his suggestion regarding a daemon startup
  notification method. He then creates and refers a second issue to the
  ctte: the design of a daemon readiness protocol
  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733452#1501)

* A ctte member states that the outright attacks [..] assuming not only
  bad faith but malicious motives among other people in the free
  software community that he sees in the messages of another ctte
  member are deeply disturbing
  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2443).

* A ctte member devotes a lengthy email to describing how the GNOME
  Team has a pattern of failing to engage constructively with the rest
  of the project around crucial integration issues, and that therefore
  the ctte should not let its decision be influenced by assertions that
  GNOME upstream is tethering itself to a specific init
  system. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2638)

* The ctte chair asks to try *very* hard to keep [disrespectful
  sentences] out of the TC discussion.
  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2468)

* The ctte members one by one announce their preferences, resulting in a
  theoretical (no formal vote was called) 4:4 draw between upstart and
  systemd. All of 3 Ubuntu (or former Ubuntu) developers in the ctte
  declare their support for upstart.

* A debian developer finds a fairly challeging conflict of interest
  after a ctte member and Canoncial-employed maintainer of upstart
  states that decision for systemd would leave Canonical confronting
  some hard questions about whether to continue investing in upstart
  development.
  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2810)
  
* An attempt to draft a resolution gets stuck.

* A GR is proposed on debian-vote. The option to defer the decision to
  the ctte seems to get the most vocal support.
  (XXX)

* Some ctte members offer to implement specific functions in their
  preferred init system in an attempt to sway others to their position.
  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#4031)
  
* The ctte chair calls for vote on the default init system in a ~10 line
  message without prior discussion of the resolution. The call for votes
  is not send to the ctte bug, but the ctte mailing list.
  (xxx)
  
* A ctte member is offended by calling for votes on this resolution
  without discussing it first, and asks the other members to vote with
  further discussion because the resolution did not specify that it
  could be overturned by a GR with simple majority.
  (XXX)
  
* A ctte resolution to declare that all future ctte decisions relating
  to the init system will be automatically overruled by GRs with simple
  majority is proposed. The author states he will call for votes after a
  discussion period of one day.
  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#4191)

* A ctte resolution asserting that sysv init support is mandatory and
  that no package may depend on a specific init system is proposed. The
  author states he will call for votes after a discussion 

Bug#727708: The tech ctte isn't considering OpenRC at all

[Nikolaus Rath]

Ian Jackson ijack...@chiark.greenend.org.uk writes:
 Nikolaus Rath writes (Bug#727708: The tech ctte isn't considering OpenRC at 
 all):
 Ian Jackson ijack...@chiark.greenend.org.uk writes:
  Thomas, does OpenRC provide a means for do non-forking daemon
  startup ?
 [...]
 
 Ian, quoting from your previous evaluation of upstart
 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1499):
 ...
 I don't see how this is consistent with what you say about
 OpenRC. Either the lack of features isn't a problem if they can in
 principle be implemented in the future (in that case, upstart and OpenRC
 are both viable candidates), or hypothetical features do not matter (in
 that case this should also hold for upstart).

 Firstly, non-forking daemon startup and supervision is less of a
 feature and more of a design decision.  I think that doing it from
 scratch in a system which doesn't have it at all involves a lot of
 design decisions and a fair amount of programming work.

 Secondly, the features I list as missing for upstart are not IMO
 anywhere near as important.

I see, thanks for the clarification. To me implementing non-forking
startup in OpenRC seems about the same amount of work as implementing
systemd-style socket activation in upstart. 

 If you think OpenRC will soon have non-forking daemon startup, then
 excellent.  Can you explain to me how it will work ?

I don't think OpenRC is a good candidate for the default init and I
don't know about any plans to implement non-forking startup, so I'd
rather not do that. My actual goal was to have you reconsider the weight
you put on not-yet-implemented-but-easy-to-do features in upstart :-).


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txcy5bd5@vostro.rath.org

Bug#727708: Thoughts on Init System Debate

[Nikolaus Rath]

Andres Freund and...@anarazel.de writes:
 On 2014-01-19 23:18:26 -0800, Steve Langasek wrote:
 As you say that planned features or development could sway your opinion: are
 there particular features that you have in mind, here?  For instance,
 correcting upstart's socket-based activation interface is on the upstart
 roadmap in the jessie timeframe.

 Showing some progress on issues like
 https://bugs.launchpad.net/upstart/+bug/447654 would excite me far
 much more than promises about future features. Not fixing issues
 described as a fundamental design flaw by upstart's original author
 for several years, without an inkling of progress, is what's causing
 doubts about upstarts health, at least for me.

I would add the very presence of the mountall tool to this
list. Lennart has described the issues with mountall in
https://plus.google.com/u/0/+LennartPoetteringTheOneAndOnly/posts/ip8e1DqJdxT,
and apparently the upstart developers have been aware them as well since
the very beginning (at least since Ubuntu 8.04), yet the mountall
manpage still says

   This  is  a  temporary  tool  until  init(8) itself gains the necessary
   flexibility to perform this processing; you  should  not  rely  on  its
   behaviour.

Yet no replacement is in sight even after more than 5 years.


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ha8y58u8@vostro.rath.org

Bug#727708: The tech ctte isn't considering OpenRC at all

[Nikolaus Rath]

Ian Jackson ijack...@chiark.greenend.org.uk writes:
 Thomas Goirand writes (Bug#727708: The tech ctte isn't considering OpenRC at 
 all):
 But that OpenRC just hasn't been considered just because of rumors is
 really unacceptable.

 The reason I haven't seriously considered OpenRC for the default is
 that it wasn't ready.

 Perhaps things have improved.  But I don't think it is necessarily the
 TC's job to go back and revisit OpenRC in these circumstances.  How
 mature a system is and how well-developed in Debian are relevant
 factors and it's not unreasonable to set a deadline, at which the
 state of the system in Debian will be the basis of our technical
 evaluation.


 On to specifics:

 Thomas, does OpenRC provide a means for do non-forking daemon
 startup ?
[...]

Ian, quoting from your previous evaluation of upstart
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1499):

,
| [...]
| upstart's minimalism is very appealing to me.
| 
| It does, however, have a number of missing features.  Those I have in
| mind are:
|   - ability to log daemon output to syslog
|   - multiple socket activation (systemd socket activation protocol)
|   - socket activation for IPv6 (and datagram sockets)
| 
| Of these Russ rightly points out that lack of IPv6 support is rather
| poor; it is arguably not suitable for release in jessie without this.
| 
| However, crucially, these are all simple matters of programming,
| without difficult design decisions.  They IMO don't reveal structural
| problems with upstart's approach to things.
| [...]
| I therefore conclude that the default init system for jessie should be
| upstart.
`

I don't see how this is consistent with what you say about
OpenRC. Either the lack of features isn't a problem if they can in
principle be implemented in the future (in that case, upstart and OpenRC
are both viable candidates), or hypothetical features do not matter (in
that case this should also hold for upstart).


I'm not saying that the existing OpenRC and upstart features are on par,
but outright rejecting OpenRC just because of missing features does not
seem fair to me when you at the same time consider the missing upstart
features as irrelevant because they can still be implemented.


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwirxu5s@vostro.rath.org

Bug#727708: init system thoughts

[Nikolaus Rath]

Anthony Towns a...@erisian.com.au writes:
 To emulate systemd dependencies in an event model (ie, X depends on
 Y), you'd need to do either:

 * change Y's job to say start on starting X
 * add stop on stopping Y to X's job description

 or

 * add a pre-start script to X in order to start Y first
 * add stop on stopping Y to X's job description

 The latter looks like it's the documented way of doing things.

But maybe not the working and/or recommend one:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#3150 (the quoted
parts are important).

Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874n52atz4@vostro.rath.org

Bug#727708: init system thoughts

[Nikolaus Rath]

Hello,

I am aware that this bug already has a lot of emails in it, but I think
the issue below is important enough to warrant a

*ping*

to the upstart developers. It would be great if someone could comment on
this.

Best
Nikolaus


Nikolaus Rath nikol...@rath.org writes:
 Cameron Norman camerontnor...@gmail.com writes:
 On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath nikol...@rath.org wrote:
 Colin Watson cjwat...@debian.org writes:
  The criticisms of Upstart's event model in the systemd position
  statement simply do not make sense to me.  Events model how things
  actually happen in reality; dependencies are artificial constructions on
  top of them, and making them work requires the plethora of different
  directives in systemd (e.g. Wants, which is sort of a non-depending
  dependency) to avoid blocking the boot process on a single failing
  service.  Yes, there are some bugs possible in the Upstart design, but I
  don't agree that those are world-ending fundamental issues and I think
  they're generally incrementally fixable.  The systemd design appears to
  me to expose far more complexity to the user writing unit files, and I
  think it's important that their mental model be as straightforward as
  possible.
 
  (Now, I've been working with Upstart's model for years, and it's now a
  pretty fundamental way of how I think of system operation; so if people
  who are new to *both* models rather than partisans of one side or the
  other consistently tell me that the systemd model is easier to grasp,
  then I'll listen.)

 For what it's worth, I consider myself new to both the upstart and the
 systemd model, and for me the upstart event model has been pretty much
 the only reason to prefer systemd over upstart (though after reading
 Russ' opinion, that has changed a bit).

 For me, upstart was actually the reason for me switching from Debian to
 Ubuntu for a while. I am less familiar with systemd, so it may well be
 that I underestimate the complexities of the systemd model. However, I
 am very certain in my dislike for the upstart approach.


 My first point of criticism has already been described by Russ, but
 maybe I can make it clearer by giving an example. In my opinion, the
 following job looks completely harmless, and should not result in an
 unbootable system (but at least on Ubuntu 13.10 it does, you have to
 reboot with init=/bin/sh and remove/fix the evilJob.conf file):

 $ cat evilJob.conf
 start on (mounted MOUNTPOINT=/var and started lightdm)
 stop on runleves [016]
 respawn
 script
exec /bin/sleep 60
 end script

 I believe that the equivalent systemd unit (where dependencies are
 specified with Requires=) works just fine.  It is not clear to me how
 this can be incrementally fixed in upstart without fundamentally
 changing the design.


 My second point is that by treating dependencies as events, upstart does
 not seem to truly recognize dependencies as such and is then unable to
 resolve them.  For example, with the following two job files (created
 according to the upstart cookbook, 6.32.2):

 $ cat jobOne.conf
 start on (starting jobTwo and runlevel stop on runlevel [016])
 stop on runlevel [016]
 respawn
 script
 exec /bin/sleep 60
 end script
 
 $ cat jobTwo.conf
 start on runlevel [2345]
 stop on runlevel [016]
 respawn
 script
 exec /bin/sleep 60
 end script
 
 
 I can type service start jobOne, and upstart will willingly start
 jobOne without starting jobTwo, or doing anything about the unfulfilled
 dependency (not even a warning):
 
 root@ubuntu-kvm:/etc/init# service jobOne status
 jobOne stop/waiting
 root@ubuntu-kvm:/etc/init# service jobTwo status
 jobTwo stop/waiting
 root@ubuntu-kvm:/etc/init# service jobOne start
 jobOne start/running, process 3177
 root@ubuntu-kvm:/etc/init# service jobTwo status
 jobTwo stop/waiting
 
 (on Ubuntu 13.10).

 I think you raise a lot of good points in this email, but here you are
 saying something which may demonstrate your (understandable) confusion
 about the Upstart event model. Upstart does not treat dependencies as
 events. Often times, Upstart //jobs// treat dependencies as events (and the
 ones you wrote below do), but events do not signal a dependency. Just
 because you said that jobOne starts with jobTwo does not mean that jobOne
 needs jobTwo, just that during boot up jobOne will start with jobTwo. To
 express a dependency, jobTwo needs to have a start on (event where I am
 needed). If, for example, jobOne depends on a dbus interface of jobTwo,
 then jobTwo could have a start on dbus ... to show that dependency.

 I think I understand what you're saying, thanks for the explanations!

 However, I can't say that this improved understanding has improved my
 opinion about upstart. If I understand correctly, this means that either

 a) every upstart job definition needs to explicitly list every possible
way in which another service may depend on it (and, furthermore,
every possible such dependency needs to have

Bug#727708: init system discussion status

[Nikolaus Rath]

Uoti Urpala uoti.urp...@pp1.inet.fi writes:
 On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote:
 Clint Adams cl...@debian.org writes:
  On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
  or alternatively   
  
  4. Packages may, however, depend on a specific init system (which may
 not be the default init) for features that are not related to daemon
 startup. Such packages will only be installable on systems running a
 non-default init, but are permitted in the archive.
 
  As loath as I am to participate in this discussion, I have to ask
  if your intent is to suddenly outlaw all the packages which depend
  on runit.
 
 Are you asking me personally? No, that's not my intent. I merely think
 that a CTTE solution should spell out precisely to what extent a package
 must be compatible with the default init (i.e., if it must be fully
 working with the default init, or if it only has to provide daemon
 startup/supervision/shutdown for the default init). This is why I
 explicitly listed two conflicting, alternative wordings.

 There are two different kinds of dependencies: dependencies expressed in
 package metadata, and functional dependencies (as in whether the package
 does anything useful with another init). Your earlier wording sounds
 like it was talking about the former (installable) and Ian's proposal
 definitely was (explicitly mentioning package fields), but the fully
 working you use now sounds like it's about the latter.

I think that if a program functionally depends on another, but the
package does not declare this dependency, then it's a bug. So in this
context I consider functional dependencies and package dependencies to
be the same.

Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gafb89u@vostro.rath.org

Bug#727708: init system discussion status

[Nikolaus Rath]

Ian Jackson ijack...@chiark.greenend.org.uk writes:
 | Choice of init system:
 | 
 | 1. The default init(1) in jessie will be upstart.
 |
 | 2. Architectures which do not currently support upstart should try to
 |port it.  If this is not achieved in time, those architectures may
 |continue to use sysvinit.  [ Non-use of upstart should not be a
 |criterion for architecture qualification status in jessie. ]
 | 
 | 3. At least in jessie, unless a satisfactory compatibility approach is
 |developed and deployed (see paragraph 10), packages must continue
 |to provide sysvinit scripts.  Lack of a sysvinit script (for a
 |daemon which contains integration with at least one other init
 |system) is an RC bug in jessie.


As said elsewhere, I think there should be a paragraph about packages
that depend on a specific init system for reasons other than service
startup, e.g.

4. The above criterium also extends to dependencies that are not related
   to service startup. In jessie, no package may depend on a single
   initsystem other than sysvinit. After jessie, no package may depend
   on a single init system other than the default init.

or alternatively   

4. Packages may, however, depend on a specific init system (which may
   not be the default init) for features that are not related to daemon
   startup. Such packages will only be installable on systems running a
   non-default init, but are permitted in the archive.


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3ehaqqu@rath.org

Bug#727708: init system discussion status

[Nikolaus Rath]

Clint Adams cl...@debian.org writes:
 On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
 As said elsewhere, I think there should be a paragraph about packages
 that depend on a specific init system for reasons other than service
 startup, e.g.
 
 4. The above criterium also extends to dependencies that are not related
to service startup. In jessie, no package may depend on a single
initsystem other than sysvinit. After jessie, no package may depend
on a single init system other than the default init.
 
 or alternatively   
 
 4. Packages may, however, depend on a specific init system (which may
not be the default init) for features that are not related to daemon
startup. Such packages will only be installable on systems running a
non-default init, but are permitted in the archive.

 As loath as I am to participate in this discussion, I have to ask
 if your intent is to suddenly outlaw all the packages which depend
 on runit.

Are you asking me personally? No, that's not my intent. I merely think
that a CTTE solution should spell out precisely to what extent a package
must be compatible with the default init (i.e., if it must be fully
working with the default init, or if it only has to provide daemon
startup/supervision/shutdown for the default init). This is why I
explicitly listed two conflicting, alternative wordings.


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwjc2x0j@vostro.rath.org

Bug#727708: loose ends for init system decision

[Nikolaus Rath]

Russ Allbery r...@debian.org writes:
 This message is about a transition plan for an init system replacement and
 about how to handle portability to our non-Linux ports.  I'm keeping the
 same subject as Ian's message on the same basic topics and attaching it to
 the same thread, but this is more of a separate writeup than a reply.
[...]

 5. Support for the other init system that was not chosen should be handled
in the same fashion, should a team choose to pursue it.  If we select
systemd, package maintainers should still be willing to merge
contributed upstart configuration, with the understanding that they
can't test it and any support is on a best-effort basis only.
Similarly, if we select upstart, package maintainers should be willing
to merge systemd unit files and to enable upstream systemd support
where requested and where it doesn't interfere with the operation of
the daemon under upstart, with the understanding that the package
maintainer is not committing to testing or directly supporting this
configuration.

Thanks all a lot for all your detailed writeups Russ. It is much
appreciated.


I think there is one additional questions that will probably need to be
decided by the tc but hasn't really been discussed yet:

Will packages that explicity depend on a (non-default) init system be
allowed in Debian?


For example, if I want to package a program that depends on a feature
available only in upstart, but systemd was chosen as the default init
system, can I upload this package with a depends on upstart, or will
this be rejected?

If such packages will not be allowed in the archive, does the burden of
making them work with the default init lie on the maintainers of the
default init (to add the missing feature), or the package maintainer (to
work around the features absence if he wants the package in Debian)?


The specific situation that I have in mind is of course when upstart
becomes the default, and gnome becomes dependent on systemd, but I think
the question is larger than just this example.


Best,
-Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878uuyl11k@rath.org

Bug#727708: upstart and upgrading from sysvinit scripts

[Nikolaus Rath]

Steve Langasek vor...@debian.org writes:
 However, I think this gets to the heart of why upstart upstream has avoided
 ever recommending the use of socket-based activation.  There are some fairly
 fundamental problems that basically halted development of socket-based
 activation in upstart (beyond merging of Scott's original implementation,
 which is rudimentary, as has been noted), and a look at systemd usage on
 Fedora led me to believe that systemd had not overcome these problems at
 all.
[...]

I really hope that you wrote this email (and a few other recent ones)
with your upstart maintainer hat on, and not your ctte member hat.

Unless I have missed something, pretty much all the statements you have
made (in a rather confrontational and certain tone) about systemd in
this mail have been refuted. It seems that you have misunderstood some
important parts of the systemd architecture, and instead of asking
anyone to clarify, you went on to construct contra-systemd arguments
from them.

That can happen, and I am pretty sure that I have done the same. In my
opinion, however, this is not acceptable from a ctte member who is
expected to make a decision about the better init system for Debian as a
whole.

I do not believe that being the upstart maintainer disqualifies you from
making this decision as a ctte member. I believe, however, that it
places a special responsibility on you to be especially diligent in your
research on systemd. Being the upstart maintainer means you have twice
as much time available to learn about systemd (every other ctte member
needs to split his time between upstart and systemd), and it means that
you have to work extra hard to obtain at least a roughly comparable
familiarity with both systemd and upstart.

From your emails thus far, it does not look as if you have done
this. Quite the contrary, I have the impression that you are using your
familiarity with upstart as a reason to not investigate systemd in much
depth.


To put a long story short, I hope you are going to spend some more time
on systemd before casting a vote.


Thanks for considering, and happy new year!

Best,
-Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874n5ml05g@rath.org

Bug#727708: loose ends for init system decision

[Nikolaus Rath]

On 01/02/2014 10:20 AM, Ian Jackson wrote:
 Nikolaus Rath writes (Bug#727708: loose ends for init system decision):
 I think there is one additional questions that will probably need to be
 decided by the tc but hasn't really been discussed yet:

 Will packages that explicity depend on a (non-default) init system be
 allowed in Debian?
 
 My answer to this is no.
 
 So, firstly, I would say that all packages must, in jessie at least,
 continue to support sysvinit.  Russ (from the other side of the
 upstart/systemd fence) agrees.  Failure to support sysvinit would be
 an RC bug.
 
 And since all the proposed replacement inits have a compatibility
 mode, that naturally means they'll work.
 
 Contributors who support the non-default new init system will be able
 to supply patches for native support and should have them accepted.
 
 If such packages will not be allowed in the archive, does the burden of
 making them work with the default init lie on the maintainers of the
 default init (to add the missing feature), or the package maintainer (to
 work around the features absence if he wants the package in Debian)?
 
 The latter.

Just to make sure that I expressed myself correctly: I was not thinking
about a package that depends on a specific init system to start or stop,
but about a program that is really specific to the *new* features of
upstart or systemd.


For example, a hypothetical future program to interactively adjust
program cgroups cannot be sysvinit compatible in any meaningful sense,
because it does not need to be supervised, started, or stopped. However,
this program would depend on the cgroups API offered by systemd. So this
program would not be allowed in Debian, unless its maintainer adds
support for whatever cgroups managed we would eventually use with upstart?


Best,
Nikolaus


-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52c5afce.5010...@rath.org

Bug#727708: loose ends for init system decision

[Nikolaus Rath]

On 01/02/2014 10:30 AM, Ian Jackson wrote:
 Nikolaus Rath writes (Re: Bug#727708: loose ends for init system decision):
 For example, a hypothetical future program to interactively adjust
 program cgroups cannot be sysvinit compatible in any meaningful sense,
 because it does not need to be supervised, started, or stopped. However,
 this program would depend on the cgroups API offered by systemd. So this
 program would not be allowed in Debian, unless its maintainer adds
 support for whatever cgroups managed we would eventually use with upstart?
 
 I would hope that we can standardise on a single API to the system's
 single cgroup writer.

I certainly hope so too, but I think the question of how such a
situation would be handled needs to be answered. Even if we end up with
a standardized cgroup API, it may show up in a different disguise.


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52c5b301.2080...@rath.org

Bug#727708: init system thoughts

[Nikolaus Rath]

Colin Watson cjwat...@debian.org writes:
 The criticisms of Upstart's event model in the systemd position
 statement simply do not make sense to me.  Events model how things
 actually happen in reality; dependencies are artificial constructions on
 top of them, and making them work requires the plethora of different
 directives in systemd (e.g. Wants, which is sort of a non-depending
 dependency) to avoid blocking the boot process on a single failing
 service.  Yes, there are some bugs possible in the Upstart design, but I
 don't agree that those are world-ending fundamental issues and I think
 they're generally incrementally fixable.  The systemd design appears to
 me to expose far more complexity to the user writing unit files, and I
 think it's important that their mental model be as straightforward as
 possible.

 (Now, I've been working with Upstart's model for years, and it's now a
 pretty fundamental way of how I think of system operation; so if people
 who are new to *both* models rather than partisans of one side or the
 other consistently tell me that the systemd model is easier to grasp,
 then I'll listen.)

For what it's worth, I consider myself new to both the upstart and the
systemd model, and for me the upstart event model has been pretty much
the only reason to prefer systemd over upstart (though after reading
Russ' opinion, that has changed a bit).

For me, upstart was actually the reason for me switching from Debian to
Ubuntu for a while. I am less familiar with systemd, so it may well be
that I underestimate the complexities of the systemd model. However, I
am very certain in my dislike for the upstart approach.


My first point of criticism has already been described by Russ, but
maybe I can make it clearer by giving an example. In my opinion, the
following job looks completely harmless, and should not result in an
unbootable system (but at least on Ubuntu 13.10 it does, you have to
reboot with init=/bin/sh and remove/fix the evilJob.conf file):

$ cat evilJob.conf
start on (mounted MOUNTPOINT=/var and started lightdm)
stop on runleves [016]
respawn
script
   exec /bin/sleep 60
end script

I believe that the equivalent systemd unit (where dependencies are
specified with Requires=) works just fine.  It is not clear to me how
this can be incrementally fixed in upstart without fundamentally
changing the design.


My second point is that by treating dependencies as events, upstart does
not seem to truly recognize dependencies as such and is then unable to
resolve them.  For example, with the following two job files (created
according to the upstart cookbook, 6.32.2):

$ cat jobOne.conf
start on (starting jobTwo and runlevel stop on runlevel [016])
stop on runlevel [016]
respawn
script
exec /bin/sleep 60
end script

$ cat jobTwo.conf
start on runlevel [2345]
stop on runlevel [016]
respawn
script
exec /bin/sleep 60
end script


I can type service start jobOne, and upstart will willingly start
jobOne without starting jobTwo, or doing anything about the unfulfilled
dependency (not even a warning):

root@ubuntu-kvm:/etc/init# service jobOne status
jobOne stop/waiting
root@ubuntu-kvm:/etc/init# service jobTwo status
jobTwo stop/waiting
root@ubuntu-kvm:/etc/init# service jobOne start
jobOne start/running, process 3177
root@ubuntu-kvm:/etc/init# service jobTwo status
jobTwo stop/waiting

(on Ubuntu 13.10).

As I understand, a systemd unit with Requires=jobTwo will not start
without jobTwo running.

I guess this could be fixed by hardcoding a special treatment of the
start on starting event, but that would effectively be equivalent to
introducing a new kind of depends on stanza, and thus acknowledge that
the everything is an event model doesn't quite work.


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y52zuuaw@vostro.rath.org

Bug#727708: init system thoughts

[Nikolaus Rath]

On 01/01/2014 04:00 PM, Nikolaus Rath wrote:
 My second point is that by treating dependencies as events, upstart does
 not seem to truly recognize dependencies as such and is then unable to
 resolve them.  For example, with the following two job files (created
 according to the upstart cookbook, 6.32.2):
 
 $ cat jobOne.conf
 start on (starting jobTwo and runlevel stop on runlevel [016])
 stop on runlevel [016]
 respawn
 script
 exec /bin/sleep 60
 end script

Wops, something went wrong with copy and paste here.

This should be:

$ cat jobOne.conf
start on (starting jobTwo and runlevel [2345])
stop on runlevel [016]
respawn
script
exec /bin/sleep 60
end script


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52c4b5af.8030...@rath.org

Bug#727708: init system thoughts

[Nikolaus Rath]

Cameron Norman camerontnor...@gmail.com writes:
 On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath nikol...@rath.org wrote:

 Colin Watson cjwat...@debian.org writes:
  The criticisms of Upstart's event model in the systemd position
  statement simply do not make sense to me.  Events model how things
  actually happen in reality; dependencies are artificial constructions on
  top of them, and making them work requires the plethora of different
  directives in systemd (e.g. Wants, which is sort of a non-depending
  dependency) to avoid blocking the boot process on a single failing
  service.  Yes, there are some bugs possible in the Upstart design, but I
  don't agree that those are world-ending fundamental issues and I think
  they're generally incrementally fixable.  The systemd design appears to
  me to expose far more complexity to the user writing unit files, and I
  think it's important that their mental model be as straightforward as
  possible.
 
  (Now, I've been working with Upstart's model for years, and it's now a
  pretty fundamental way of how I think of system operation; so if people
  who are new to *both* models rather than partisans of one side or the
  other consistently tell me that the systemd model is easier to grasp,
  then I'll listen.)

 For what it's worth, I consider myself new to both the upstart and the
 systemd model, and for me the upstart event model has been pretty much
 the only reason to prefer systemd over upstart (though after reading
 Russ' opinion, that has changed a bit).

 For me, upstart was actually the reason for me switching from Debian to
 Ubuntu for a while. I am less familiar with systemd, so it may well be
 that I underestimate the complexities of the systemd model. However, I
 am very certain in my dislike for the upstart approach.


 My first point of criticism has already been described by Russ, but
 maybe I can make it clearer by giving an example. In my opinion, the
 following job looks completely harmless, and should not result in an
 unbootable system (but at least on Ubuntu 13.10 it does, you have to
 reboot with init=/bin/sh and remove/fix the evilJob.conf file):

 $ cat evilJob.conf
 start on (mounted MOUNTPOINT=/var and started lightdm)
 stop on runleves [016]
 respawn
 script
exec /bin/sleep 60
 end script

 I believe that the equivalent systemd unit (where dependencies are
 specified with Requires=) works just fine.  It is not clear to me how
 this can be incrementally fixed in upstart without fundamentally
 changing the design.


 My second point is that by treating dependencies as events, upstart does
 not seem to truly recognize dependencies as such and is then unable to
 resolve them.  For example, with the following two job files (created
 according to the upstart cookbook, 6.32.2):


 I think you raise a lot of good points in this email, but here you are
 saying something which may demonstrate your (understandable) confusion
 about the Upstart event model. Upstart does not treat dependencies as
 events. Often times, Upstart //jobs// treat dependencies as events (and the
 ones you wrote below do), but events do not signal a dependency. Just
 because you said that jobOne starts with jobTwo does not mean that jobOne
 needs jobTwo, just that during boot up jobOne will start with jobTwo. To
 express a dependency, jobTwo needs to have a start on (event where I am
 needed). If, for example, jobOne depends on a dbus interface of jobTwo,
 then jobTwo could have a start on dbus ... to show that dependency.

I think I understand what you're saying, thanks for the explanations!

However, I can't say that this improved understanding has improved my
opinion about upstart. If I understand correctly, this means that either

a) every upstart job definition needs to explicitly list every possible
   way in which another service may depend on it (and, furthermore,
   every possible such dependency needs to have upstart integration so
   that it can actually be used as an event)

or

b) a package providing jobOne that depends on jobTwo from another
   package needs to patch the *other* package's configuration to add the
   dependency information to jobTwo's definition.

Neither of this sounds appealing to me at all, especially compared to
systemd, where all you have to do is drop a Requires= line into jobOne's
configuration.

 Basically, to express dependencies in Upstart you express all the ways
 a job is needed inside of that job, not inside others.  That said,
 Upstart developers and Ubuntu developers do not use Upstart this way
 and write jobs like you did below, so an Upstart system will most
 likely not act like I explained above (however this is not an inherent
 flaw in Upstart).

Well, so what is the proper way to encode a dependency in an upstart job
for Ubuntu (and presumable Debian) then? Apparently the proper way is
extremly tedious and not used by anyone, and the other way isn't able to
satisfy dependencies.


Also, I would think that your

Bug#727708: init system thoughts

[Nikolaus Rath]

Cameron Norman camerontnor...@gmail.com writes:
  I think you raise a lot of good points in this email, but here you
  are saying something which may demonstrate your (understandable)
  confusion about the Upstart event model. Upstart does not treat
  dependencies as events. Often times, Upstart //jobs// treat
  dependencies as events (and the ones you wrote below do), but
  events do not signal a dependency. Just because you said that
  jobOne starts with jobTwo does not mean that jobOne needs jobTwo,
  just that during boot up jobOne will start with jobTwo. To express
  a dependency, jobTwo needs to have a start on (event where I am
  needed). If, for example, jobOne depends on a dbus interface of
  jobTwo, then jobTwo could have a start on dbus ... to show that
  dependency.

 I think I understand what you're saying, thanks for the explanations!

 However, I can't say that this improved understanding has improved my
 opinion about upstart. If I understand correctly, this means that either

[...]
 or

 b) a package providing jobOne that depends on jobTwo from another
package needs to patch the *other* package's configuration to add the
dependency information to jobTwo's definition.


 Yes. The patch would, however, be limited to a or (...) in the start on
 section. So it is not like the patch is going to change a ton.

No it's not a difficult change, but you'd be patching a *different
packages* configuration file. I am not a dpkg expert, but I'm pretty
sure this is not something a maintainer script should do.


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sit69aad@vostro.rath.org

Bug#727708: requires in systemd

[Nikolaus Rath]

Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes:
 As I understand, a systemd unit with Requires=jobTwo will not start
 without jobTwo running.

 If you request the start of jobOne, without jobTwo running,
 systemd will start jobTwo in addition to jobOne.

 There's also a Requisite= dependency, where if jobTwo isn't runnning,
 starting jobOne will fail.

Thanks for the confirmation! This is what I concluded from the
documentation, and also what I consider to be the right behavior.


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ob3u9a7d@vostro.rath.org

Bug#727708: upstart and upgrading from sysvinit scripts

[Nikolaus Rath]

Steve Langasek vor...@debian.org writes:
 On Sun, Dec 29, 2013 at 01:43:59PM -0800, Nikolaus Rath wrote:
 I'm a bit surprised that you mention this only now, after Russ'
 extensive mail. Could you tell us if there are there other components in
 systemd that you think are similarly flawed,

 Why should it have been mentioned before now?

Socket activation seems to be considered one of the major new features
that systemd brings to the table. You seem to think it's fundamentally
flawed, and you're the maintainer of the upstart position statement, so
I would have expected it to be mentioned there as an important point to
be taken into account when making the decision.

Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r48tlcjf@vostro.rath.org

Bug#727708: upstart and upgrading from sysvinit scripts

[Nikolaus Rath]

Steve Langasek vor...@debian.org writes:
 On Sat, Dec 28, 2013 at 05:24:57PM -0800, Russ Allbery wrote:

 I'll have more to say about the relative merits of the two init systems
 later, but one thing I wanted to not briefly: this exercise was extremely
 valuable in helping me get a more realistic picture of both init systems.
 I had gone into this exercise with the vague impression that they were
 roughly at feature parity, and now realize that is not the case.

 My impression now is that systemd's init and service management component
 is a substantially more mature piece of software.  That's an odd thing to
 say given that upstart is older, but systemd has the feel of software
 that's been tested against a wide variety of different situations and has
 had the necessary adaptations and configuration added to meet those needs.
 In some cases, that's simply additional features; in some cases, that's
 more comprehensive and more scalable design.  The socket activation system
 in particular is night and day between the two systems.

 So to respond specifically to this point about the night and day
 difference between the socket-based activation systems: yes, upstart
 upstream has not invested in fleshing out its socket-based activation
 support, because earlier investigations led us to believe that socket-based
 activation is a red herring that will never deliver the promised benefits.

 The feature was made available for those who might prefer to start their
 services without the need for writing socket-handling code; but in my
 estimation, the flaws wrt system startup (which as far as I can see also
 affect the systemd implementation) make it altogether unsuitable for any
 services you're expecting to have started at boot, and we have deliberately
 avoided its use in Ubuntu.

I'm a bit surprised that you mention this only now, after Russ'
extensive mail. Could you tell us if there are there other components in
systemd that you think are similarly flawed, and/or are if there other
features in upstart that you think will never deliver the benefits one
would naively expect from them?

Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wqin8h9c@vostro.rath.org

Bug#733452: Minimal code for systemd protocol

[Nikolaus Rath]

Hello,

It's already been mentioned elsewhere, but I think it should be included in 
this bug for reference. The minimum code to support systemd style readyness 
notification is (from 
https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/37AWJLE3XcJ):


static void notify(const char *data) {
const char *e;
 
e = getenv(NOTIFY_SOCKET);
if (e) {
struct sockaddr_un un = { .sun_family = AF_UNIX };
int fd;
strncpy(un.sun_path, e, sizeof(un.sun_path));
if (un.sun_path[0] == '@')
un.sun_path[0] = 0;
fd = socket(AF_UNIX, SOCK_DGRAM, 0);
if (fd  0)
return;
sendto(fd, data, strlen(data), MSG_NOSIGNAL, (struct 
sockaddr*) un, offsetof(un.sun_path) + strlen(e));
close(fd);
   }
}



Best,
Nikolaus
-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52c0a17f.7060...@rath.org

Bug#727708: init system other points, and conclusion

[Nikolaus Rath]

Ian Jackson ijack...@chiark.greenend.org.uk writes:
 It does, however, have a number of missing features.  Those I have in
 mind are:
   - ability to log daemon output to syslog
   - multiple socket activation (systemd socket activation protocol)
   - socket activation for IPv6 (and datagram sockets)

 Of these Russ rightly points out that lack of IPv6 support is rather
 poor; it is arguably not suitable for release in jessie without this.

 However, crucially, these are all simple matters of programming,
 without difficult design decisions.  They IMO don't reveal structural
 problems with upstart's approach to things.

I don't understand this argument. Even turning systemd into a 1:1
upstart copy is simple programming (and vice versa), so by that argument
there'd be no technical reason to pick one init system over the other at
all. In some sense, it seems to me that you are proposing that the
Debian *Technical* Committee make its decision for the init system based
on the *developers* of each project, because the technical differences
are mere metters of programming.

(I'm not sure why the structural and design decisions would make a
difference either, changing from one existing design to another existing
design is also just programming).

Best,
Nikolaus


-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vby7fesj@vostro.rath.org

Bug#733452: init system daemon readiness protocol

[Nikolaus Rath]

Ian Jackson ijack...@chiark.greenend.org.uk writes:
 (I have cloned the bug for this, to keep this particular
 sub-discussion separable.)

 As I have reported, we have a problem with non-forking daemon
 readiness protocols.

We have a problem seems a bit exxagerated to me. So far, the only
problem that I have seen is that you don't like the systemd protocol,
(and there's nothing wrong with that, I even agree to some extent). But
does that translate to a general problem with readiness protocols in
Debian? In other words, is there a significant number of important
packages where neither upstream nor the Debian maintainer is willing to
tolerate systemd's protocol, and that cannot use socket activation
either?

[...]
 I conclude therefore that we should design another simple protocol -
 preferably, a variation on one of the existing ones - and have (at
 least) both Debian's systemd and Debian's upstart implement it.

Could you elaborate a bit on the advantages of this proposal for Debian?
(Maybe I don't see them because I don't see the general problem that
you're trying to solve in the first place).

I think that most likely this standard wouldn't be used by anyone other
than Debian, so every daemon needs a Debian specific patch to support
it.


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ppogfsce@vostro.rath.org

Bug#727708: Problems with upstarts event model

[Nikolaus Rath]

Hi,

I just want to raise one issue that I think has not been adequately
addressed by any of the position statements (it has unfortunately been
deleted from the upstart page and been trimmed down a lot on the systemd
page):

I think an important drawback of upstart is the idea of treating
dependencies as events.

The systemd statement already mentions correctly that upstart turns the
dependency chain “upside down”, because it starts a service as soon as
all its dependencies are ready, instead of starting the dependencies of
a service when the service itself should be started.

This has practical implications as well. When trying to debug why a
service isn't starting, it's simpler to investigate which dependency
couldn't be started than to figure out which event was not emitted for
what reason at some point in the past.


Moreover (and, in my opinion, most importantly), by treating
dependencies as events (start A if B has started rather than the
conventional A requires B), native upstart jobs can create event
loops which can block starting of all services in the loop. Example:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/964207 and
discussion at https://lists.debian.org/debian-devel/2013/05/msg01500.html

As far as I can tell, something like this can not happen with systemd units.


Best,
-Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52786bbd.2010...@rath.org

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Nikolaus Rath]

On 10/31/2013 09:51 PM, Russ Allbery wrote:
 You can, of course, be
 disciplined about this when writing systemd helper scripts by always
 exernalizing the shell script into a separate file, but I really like that
 upstart lets me inline trivial shell fragments without worrying about
 that while still keeping them readable.

I can very well imagine that this is how sysv init scripts started out.
Let's make them shell scripts, it's so convenient to be able to place
that extra bit of initialization code in there...

In other words: the ability to add extra features to upstart jobs by
extending them with shell scripts could eventually end up making them
just as complex as sysv scripts. I am guilty of having written some
rather complicated trickery in upstart shell sections myself, so I know
how tempting it is.

(In my case, I was mostly working around my still insufficient
understanding of the upstart event system to start a job only in some
specific conditions. Just coding the condition and stopping the job in
its pre-start script (in itself a rather weird concept, but it came from
the upstart cookbook) turned out to be quicker and easier, but it
certainly wasn't the proper solution...)


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/527874ed.2010...@rath.org