Bug#727708: requires in systemd

[Nikolaus Rath]

Zbigniew Jędrzejewski-Szmek  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: init system thoughts

[Nikolaus Rath]

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

[Zbigniew Jędrzejewski-Szmek]

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

Zbyszek


-- 
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/20140102021744.gd2...@in.waw.pl

Bug#727708: init system thoughts

[Cameron Norman]

On Wed, Jan 1, 2014 at 5:09 PM, Nikolaus Rath  wrote:

> Cameron Norman  writes:
> > On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath  wrote:
> >
> >> Colin Watson  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)
>

Pretty much all IPC mechanisms have integration into Upstart, so a lot of
dependencies are covered.


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


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

I agree, especially when one can have a "Requires=*.socket" or
"Requires=

Bug#727708: init system thoughts

[Nikolaus Rath]

Cameron Norman  writes:
> On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath  wrote:
>
>> Colin Watson  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

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

[Cameron Norman]

On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath  wrote:

> Colin Watson  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.
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). I would
also like to note that launchd acts the same exact way as I have described
and had similar limitations. Furthermore, SystemStarter (Apple's previous
init) acted in a very similar way to systemd:

"The hardest part to manage during a launchd boot is dependencies.
SystemStarter had a very simple system of dependencies that used the
"Uses", "Requires", and "Provides" keys in the plist of a startup item.
There are two main strategies when creating launch dependencies on [OS X] .
Using IPC will allow the daemons to talk amongst themselves to work it out,
or you can watch files or paths for changes. Using IPC is much more subtle
than the SystemStarter's keys and requires more work from the developer,
but it may* *lead
to cleaner and quicker startups." --
https://en.wikipedia.org/wiki/Launchd#launchd

I still think your points are relevant, however, because Upstart in Ubuntu
acts in the same way as the below jobs, and Debian will most likely inherit
that behavior if it uses Upstart.

Happy New Year,

Cameron Norman

$ cat jobOne.conf
> start on (starti

Bug#727708: init system thoughts

[Nikolaus Rath]

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

Re: Bug#727708: init system other points, and conclusion

[Michael Gilbert]

On Wed, Jan 1, 2014 at 3:40 PM, Chris Knadle wrote:
>> I appreciate the explanation, and I'm familiar with the contents of the
>> decision.  I simply see nothing there that should have motivated a
>> tech-ctte decision, rather than simply a couple of bug reports against
>> network-manager and an added Conflicts/Breaks or two.
>
> In other words, what you're saying is that not only is there no problem that
> the GNOME maintainers mandated that I get NetworkManager, which I personally
> most certainly don't want, but that the tech-ctte should have made a ruling
> that would have forced users to uninstall wicd too.  :-/  Not cool.

There are more choices than that. Users with this viewpoint could have
stick with the DE that they like but a network tool that they don't.
Or they could switch to another DE that isn't incompatible their
favorite network tool.

The GNOME maintainers are responsible for their island.  If they don't
want to support wicd or anything else, that is their choice.  It's
also the user's choice to go somewhere else.

Best wishes,
MIke


-- 
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/CANTw=mnn0npjtva4vsmrabcqjwbsdmalua4pgrqsizytqdt...@mail.gmail.com

Re: Bug#727708: init system other points, and conclusion

[Josh Triplett]

On Wed, Jan 01, 2014 at 09:37:24PM +, Ian Jackson wrote:
> Josh Triplett writes ("Re: Bug#727708: init system other points, and 
> conclusion"):
> > On Wed, Jan 01, 2014 at 03:40:17PM -0500, Chris Knadle wrote:
> > > In other words, what you're saying is that not only [something
> > > about NetworkManager]
> > 
> > It's fairly clear that NetworkManager [something something]
> 
> Can I suggest that raking over these old coals isn't really helping ?
> 
> Anything that could have convinced any of the participants in that
> dispute has already been said.  I doubt anyone is going to change
> their mind now.
> 
> For the same reason bringing this dispute up as an example is probably
> not that helpful either.

This particular branch of the discussion doesn't seem particularly
helpful, no, and I hadn't planned to continue it further.

I do think NM serves as a useful cautionary tale here, to the extent
that both it and systemd/logind represent ongoing sources of costly
divergence for GNOME packaging, and I think folks who just see the
original tech-ctte decision there may be under the mistaken impression
that that work was over and done with with just a change to package
metadata.  However, I don't think this branch of the discussion in
particular is relevant to that point, and I'm happy to drop it.

- Josh Triplett


-- 
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/20140101215122.GA17157@leaf

Re: Bug#727708: init system other points, and conclusion

[Ian Jackson]

Josh Triplett writes ("Re: Bug#727708: init system other points, and 
conclusion"):
> On Wed, Jan 01, 2014 at 03:40:17PM -0500, Chris Knadle wrote:
> > In other words, what you're saying is that not only [something
> > about NetworkManager]
> 
> It's fairly clear that NetworkManager [something something]

Can I suggest that raking over these old coals isn't really helping ?

Anything that could have convinced any of the participants in that
dispute has already been said.  I doubt anyone is going to change
their mind now.

For the same reason bringing this dispute up as an example is probably
not that helpful either.

Thanks,
Ian.


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

Re: Bug#727708: init system other points, and conclusion

[Josh Triplett]

On Wed, Jan 01, 2014 at 03:40:17PM -0500, Chris Knadle wrote:
> On Wednesday, January 01, 2014 08:47:13 Josh Triplett wrote:
> > On Wed, Jan 01, 2014 at 08:09:56AM -0500, Chris Knadle wrote:
> > > On Tuesday, December 31, 2013 20:12:20 Josh Triplett wrote:
> > > > Steve Langasek wrote:
> > > > >On Tue, Dec 31, 2013 at 09:13:52PM +0100, Josselin Mouette wrote:
> > > > >> So unless the TC wants to remove a great number of packages from the
> > > > >> archive, you need to take into account the fact that some voluntary
> > > > >> manpower is required to implement your decision.
> > > > > 
> > > > > I think the current Debian GNOME team has a not-undeserved reputation
> > > > > for
> > > > > being obstructionist with respect to bugfixes that require divergence
> > > > > from
> > > > > upstream's stated direction.  If the team demonstrated they were open
> > > > > to
> > > > > contributions of the kind you described, volunteers to do the work
> > > > > would
> > > > > not be hard to come by.
> > > > 
> > > > That's an impressively high amount of doublespeak packed into a single
> > > > paragraph, particularly the words "bugfixes", "volunteers", and
> > > > "contributions".  At a minimum, I think you're overstating the situation
> > > > by refusing to acknowledge that the GNOME team does not consider the
> > > > changes forced upon them to be "bugfixes".
> > > 
> > > Responding specifically to this:
> > > > You (and other members of the TC) disliked GNOME's requirement of
> > > > NetworkManager, for reasons I still have yet to see explained coherently
> > > > anywhere.  You forced the GNOME team to remove it.  I certainly hope
> > > > you find "volunteers" willing to do that kind of work increasingly hard
> > > > to come by.
> > > 
> > > Re: dependency removal -- sort of.  The reasoning is explained  for the
> > > most part in the tech-ctte decision for #681834. [1]  But just to fully
> > > make this clear I'll also provide a brief summary of what I think
> > > happened at the time.
> > [...snip explanation...]
> > 
> > I appreciate the explanation, and I'm familiar with the contents of the
> > decision.  I simply see nothing there that should have motivated a
> > tech-ctte decision, rather than simply a couple of bug reports against
> > network-manager and an added Conflicts/Breaks or two.
> 
> In other words, what you're saying is that not only is there no problem that 
> the GNOME maintainers mandated that I get NetworkManager, which I personally 
> most certainly don't want, but that the tech-ctte should have made a ruling 
> that would have forced users to uninstall wicd too.  :-/  Not cool.

It's fairly clear that NetworkManager and wicd conflict, so having a
proper Conflicts or Breaks so that apt can inform you of that seems
preferable to having the two packages both installed and trying to
manage networking.  Even in the current situation, that conflict ought
to exist, since the two packages can't coexist and shouldn't be expected
to.

As for GNOME requiring NetworkManager, GNOME also requires mutter these
days as part of gnome-shell, and doesn't work with other window
managers, and I don't expect GNOME to support configurations attempting
to replace its window manager either.  Likewise you can't replace
dconf/gsettings, or gnome-panel.  With enough patching you probably
could, just as with the current pile of patches it manages to run
without NetworkManager, but that doesn't mean it *should*.  In other
news, http://islinuxaboutchoice.com/ .  I expect to see GNOME making
quite a few more upstream requirements in the future as it continues to
try to make more aspects of system configuration Just Work, and I'd very
much like to see those requirements properly represented in Debian as
dependencies.

But no, I don't think the tech-ctte should have made a ruling that would
have forced users to unstall wicd; I think they simply should have
declined to rule on the situation.

- Josh Triplett


-- 
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/20140101212804.GA16748@leaf

Re: Bug#727708: init system other points, and conclusion

[Chris Knadle]

On Wednesday, January 01, 2014 08:47:13 Josh Triplett wrote:
> On Wed, Jan 01, 2014 at 08:09:56AM -0500, Chris Knadle wrote:
> > On Tuesday, December 31, 2013 20:12:20 Josh Triplett wrote:
> > > Steve Langasek wrote:
> > > >On Tue, Dec 31, 2013 at 09:13:52PM +0100, Josselin Mouette wrote:
> > > >> So unless the TC wants to remove a great number of packages from the
> > > >> archive, you need to take into account the fact that some voluntary
> > > >> manpower is required to implement your decision.
> > > > 
> > > > I think the current Debian GNOME team has a not-undeserved reputation
> > > > for
> > > > being obstructionist with respect to bugfixes that require divergence
> > > > from
> > > > upstream's stated direction.  If the team demonstrated they were open
> > > > to
> > > > contributions of the kind you described, volunteers to do the work
> > > > would
> > > > not be hard to come by.
> > > 
> > > That's an impressively high amount of doublespeak packed into a single
> > > paragraph, particularly the words "bugfixes", "volunteers", and
> > > "contributions".  At a minimum, I think you're overstating the situation
> > > by refusing to acknowledge that the GNOME team does not consider the
> > > changes forced upon them to be "bugfixes".
> > 
> > Responding specifically to this:
> > > You (and other members of the TC) disliked GNOME's requirement of
> > > NetworkManager, for reasons I still have yet to see explained coherently
> > > anywhere.  You forced the GNOME team to remove it.  I certainly hope
> > > you find "volunteers" willing to do that kind of work increasingly hard
> > > to come by.
> > 
> > Re: dependency removal -- sort of.  The reasoning is explained  for the
> > most part in the tech-ctte decision for #681834. [1]  But just to fully
> > make this clear I'll also provide a brief summary of what I think
> > happened at the time.
> [...snip explanation...]
> 
> I appreciate the explanation, and I'm familiar with the contents of the
> decision.  I simply see nothing there that should have motivated a
> tech-ctte decision, rather than simply a couple of bug reports against
> network-manager and an added Conflicts/Breaks or two.

In other words, what you're saying is that not only is there no problem that 
the GNOME maintainers mandated that I get NetworkManager, which I personally 
most certainly don't want, but that the tech-ctte should have made a ruling 
that would have forced users to uninstall wicd too.  :-/  Not cool.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
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/1638461.R6MUifvfgd@trelane

Bug#727708: systemd status when using multiple block device layers (MD/LVM/dm-crypt) below the root-fs

[Christoph Anton Mitterer]

On Wed, 2014-01-01 at 05:48 +0100, Mourad De Clerck wrote:
> So last time I tried, this just worked - my rootfs got mounted using a 
> keyscript in the initramfs, and there were no problems, not a peep from 
> systemd when it took over, no re-setup or anything.
Sure... but that applies, AFAIU, only to the stuff mounted from within
the initramfs (at most: rootfs / resume-fs).

While I think that for most attack-scenarios, where on-disk-encryption
makes sense (the notably exception being: coincidental theft of your
device), a fully encrypted system (i.e. including the root-fs) is the
only thing that makes sense... it's still necessary to support
additional encrypted devices to be brought up during boot (which is
AFAIU then systemd's task).

I've added few thoughts to #618862, with things that IMHO are necessary
to get proper keyscript support with systemd.

> Stacking causes no problems in my experience. There are of course still 
> problems with devices that aren't mounted in the initramfs but still 
> need some keyscript (f.e. decrypt_derived comes to mind).
Well from inside the initramfs this definitely does not work out of the
box... since they initramfs-scripts expect a specific order (i.e. MDADM
first, and so on... and especially the lvm scripts are kinda bogus).
Not that it would make much sense to put dmcrypt below MDADM (in the
meantime not even performance-wise)... security wise this might be even
disastrous.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#727708: init system thoughts

[Uoti Urpala]

On Wed, 2014-01-01 at 17:17 +, Colin Watson wrote:
> On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
> > Colin Watson  writes:
> > > Basically, systemd would be more compelling to me if it tried to do
> > > less.  I don't expect to persuade systemd advocates of this, as I think
> > > it amounts to different basic views of the world, but the basic approach
> > > here is probably the single biggest factor influencing my position.
> > 
> > On the other hand even when using upstart as an init replacement, we'll
> > continue to use large chunks of systemd (logind, other dbus
> > services). I personally think "less is more" would only be a convincing
> > argument if we actually would not need the aditional features.

I think this counterargument, while valid, misses the major flaw in the
"would be more compelling if it tried to do less" claim:

You can simply not install any of these additional services if you don't
want them. This is completely trivial to do. Using systemd as init in no
way requires using them. Thus their existence cannot cause any technical
problems for the use of systemd in Debian (beyond possibly needing to do
the trivial disabling).

If some other components that Debian does want to use start to depend on
those services, such that disabling them is not easy, then this problem
would exist regardless of the chosen init, and is again not a reason for
favor upstart.

> I'm referring to features that I don't think we'll need, not to logind
> et al.  So far I feel that the debates about those seem to be a bit
> circular and go something like this:
> 
>   A: This feature of systemd conflicts with something else; I'd rather
>  we didn't use it.
>   B: You can disable that, you know.
>   A: OK, let's disable it.
>   B: But you shouldn't disable it because that would make Debian systemd
>  less compatible with systemd on other distributions.
>   A: ...

Here B first correctly points out that the feature can be disabled if
desired, and thus the situation cannot be worse than with upstart - you
can do at least as well with systemd as you could with upstart. Then you
(A) have a disagreement with B about whether disabling the feature is
the _best_ way to handle the situation: B thinks that gaining
compatibility with other distributions is a bigger plus, and that
changing to the systemd way is an actual win over current situation,
rather than just neutral like the the upstart and disabling with systemd
cases.

There is no technical reason to prefer upstart here. Given your
preferences, systemd can do at least as well (after disabling the
service). Given B's preferences, systemd can do better (after enabling
the service). The only benefit that choosing upstart would give you here
is that it'd let you automatically win your argument with B: "we already
chose upstart, so enabling the systemd service is not an available
choice any more".


-- 
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/1388600146.3938.402.camel@glyph.nonexistent.invalid

Bug#727708: init system other points, and conclusion

[Cameron Norman]

On Wed, Jan 1, 2014 at 4:56 AM, Colin Watson  wrote:

> On Tue, Dec 31, 2013 at 04:27:16AM -0008, cameron wrote:
> > On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson 
> > >inotify is used to notice changes to configuration files.  This is
> > >certainly helpful for users, but it isn't critical as "initctl
> > >reload-configuration" works without it.  We could probably do without
> > >this with the aid of a dpkg trigger.
> >
> > inotify use can easily be ported to kqueue within Upstart, or
> > libinotify-kqueue can be used.
>
> Note that I'm talking about the Hurd here.  kqueue is a kFreeBSD thing,
> as far as I know.  (Compare e.g.
> https://lists.debian.org/debian-hurd/2013/10/msg00021.html)
>
> > >prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification
> > >work properly when Upstart is supervising a user session.  This isn't
> > >a required feature and could easily be compiled out until suitable
> > >kernel support is available (this actually seems like the sort of
> > >thing that could be done in the Hurd without too much difficulty, but
> > >I haven't looked into it).  If absent, it might well impede the
> > >ability to do an advanced desktop port, but it wouldn't get in the
> > >way of porting the bulk of services.
> >
> > Unity, likely the only desktop environment using Upstart as a
> > session init, is not in Debian. The sacrifice of this functionality
> > on non-linux systems is perfectly acceptable.
>
> While this is true today, we need to look to the future.  Using Upstart
> as a session init is not conceptually tied to Unity in any way, and I
> expect that other desktop environments will want to use more advanced
> session supervision soon enough.
>
>
I place less importance on the session init capabilities of Upstart, as
alternative home grown solutions ww.ritten by the environments are in place
and are portable. Furthermore, portability of these environments hinges on
a session and seat manager, ConsoleKit support in GNOME is quickly
disappearing, and ConsoleKit itself is completely abandoned. What this
means, to me, is there is a lot more effort required to accomplish this
than to port Upstart's session init capabilities or use the current
portable session inits.

Sincerely,
Cameron Norman

--
> Colin Watson   [cjwat...@debian.org]
>

Bug#727708: init system thoughts

[Colin Watson]

On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
> Colin Watson  writes:
> > Reservations with systemd
> > -
> [...]
> > Basically, systemd would be more compelling to me if it tried to do
> > less.  I don't expect to persuade systemd advocates of this, as I think
> > it amounts to different basic views of the world, but the basic approach
> > here is probably the single biggest factor influencing my position.
> 
> On the other hand even when using upstart as an init replacement, we'll
> continue to use large chunks of systemd (logind, other dbus
> services). I personally think "less is more" would only be a convincing
> argument if we actually would not need the aditional features.

I'm referring to features that I don't think we'll need, not to logind
et al.  So far I feel that the debates about those seem to be a bit
circular and go something like this:

  A: This feature of systemd conflicts with something else; I'd rather
 we didn't use it.
  B: You can disable that, you know.
  A: OK, let's disable it.
  B: But you shouldn't disable it because that would make Debian systemd
 less compatible with systemd on other distributions.
  A: ...

> I also have one question: your mail doesn't mention the integration
> problems with logind into a system that uses upstart and not systemd as
> init. Do you think this will not be an issue?

I think the amount of time spent arguing about it has already exceeded
the total amount of effort it would ever take.

That said, I rather suspect that it was a tactical error for Upstart
people to choose to use the logind code from systemd, even though that
involved less reimplementation of wheels.  In the long term it would
probably be better to write an independent implementation of the same
interfaces or fork the existing code to a different source package,
partly because that would help to dispose of the idea that Upstart is
really dependent on systemd anyway, and partly because it would be
friendlier to the Debian systemd maintainers.

No doubt that could still be done.  It's unfortunate that it's not one
of the components listed as "Reimplementable Independently", but I guess
that just means more manual effort to keep track of the interface; and
this would move the grunt work from the shoulders of the Debian systemd
maintainers to those of the Upstart maintainers, which is probably the
right place for it to lie.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
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/20140101171725.gw5...@riva.ucam.org

Bug#727708: init system thoughts

[Ansgar Burchardt]

Hi,

Colin Watson  writes:
> Reservations with systemd
> -
[...]
> Basically, systemd would be more compelling to me if it tried to do
> less.  I don't expect to persuade systemd advocates of this, as I think
> it amounts to different basic views of the world, but the basic approach
> here is probably the single biggest factor influencing my position.

On the other hand even when using upstart as an init replacement, we'll
continue to use large chunks of systemd (logind, other dbus
services). I personally think "less is more" would only be a convincing
argument if we actually would not need the aditional features.

I also have one question: your mail doesn't mention the integration
problems with logind into a system that uses upstart and not systemd as
init. Do you think this will not be an issue? Given it means ongoing
work instead of a one-time investment, this is one of my main gripes
with upstart. I feel that minor technical differences between the init
replacements are not work committing to long-time maintaince of a
systemd-logind branch that works outside of systemd. There are more
interesting areas we can invest our resources into.

Note that this might also include session management functions in the
future. As you mentioned yourself in [1], DEs are looking into using
advanced session supervision. So far both kwin and GNOME seem to target
systemd for this. So this would be another area that we would need to
invest resources into to maintain an upstart replacement.

  [1] 

Ansgar


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

Bug#727708: loose ends for init system decision

[Neil McGovern]

On 30 Dec 2013, at 18:47, Russ Allbery  wrote:
> However, I think it's the best available approach that balances our ideals
> as a project against the opportunities offered by a new init system.  This
> approach does permit full use of new init system features for jessie
> except for eliminating /etc/default files (which I doubt we'd successfully
> do quickly anyway), and opens up the full spectrum of use cases after
> jessie.  The cost is that packagers should merge contributed patches to
> the init systems that they don't use.  I don't think this is too much to
> ask, nor do I think it will have serious effects on package complexity
> based on my own experience configuring a package to work under all three
> init systems I considered.
> 

I’m no longer a RM, but I would echo Russ’ comments here - an ordered 
transition is very important for Debian releases - and the size of this 
transition would be something that (in my opinion) would be very hard to 
achieve in one release cycle.

Neil


--
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/fd1ab7df-1a43-42c4-90d9-78c08e6be...@halon.org.uk

Re: Bug#727708: init system other points, and conclusion

[Josh Triplett]

On Wed, Jan 01, 2014 at 08:09:56AM -0500, Chris Knadle wrote:
> On Tuesday, December 31, 2013 20:12:20 Josh Triplett wrote:
> > Steve Langasek wrote:
> > >On Tue, Dec 31, 2013 at 09:13:52PM +0100, Josselin Mouette wrote:
> > >> So unless the TC wants to remove a great number of packages from the
> > >> archive, you need to take into account the fact that some voluntary
> > >> manpower is required to implement your decision.
> > > 
> > > I think the current Debian GNOME team has a not-undeserved reputation for
> > > being obstructionist with respect to bugfixes that require divergence from
> > > upstream's stated direction.  If the team demonstrated they were open to
> > > contributions of the kind you described, volunteers to do the work would
> > > not be hard to come by.
> > 
> > That's an impressively high amount of doublespeak packed into a single
> > paragraph, particularly the words "bugfixes", "volunteers", and
> > "contributions".  At a minimum, I think you're overstating the situation
> > by refusing to acknowledge that the GNOME team does not consider the
> > changes forced upon them to be "bugfixes". 
> 
> Responding specifically to this:
> 
> > You (and other members of the TC) disliked GNOME's requirement of
> > NetworkManager, for reasons I still have yet to see explained coherently
> > anywhere.  You forced the GNOME team to remove it.  I certainly hope
> > you find "volunteers" willing to do that kind of work increasingly hard
> > to come by.
> 
> Re: dependency removal -- sort of.  The reasoning is explained  for the most 
> part in the tech-ctte decision for #681834. [1]  But just to fully make this 
> clear I'll also provide a brief summary of what I think happened at the time.
[...snip explanation...]

I appreciate the explanation, and I'm familiar with the contents of the
decision.  I simply see nothing there that should have motivated a
tech-ctte decision, rather than simply a couple of bug reports against
network-manager and an added Conflicts/Breaks or two.

- Josh Triplett


-- 
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/20140101164713.GA13257@leaf

Bug#727708: init system other points, and conclusion

[intrigeri]

Hi,

Ian Jackson wrote (31 Dec 2013 16:58:17 GMT) :
> I think you have misunderstood.  Or perhaps I hae misunderstood you.
> The "work" that I'm saying needs to be done anyway is the work to
> disentange the parts of systemd which are required by (say) GNOME from
> the parts which are only relevant for systemd as init.

I was talking about the very same work, so I think we're understanding
each other just fine on this point :)

Your reply helped me focus and clarify my analysis (that is not "the
project as whole" / "porters and upstart lovers" anymore), though.
Thank you.

It also helped me understand what, I think, a few things we disagree
on: first, who would have the "moral" responsibility of doing this
work; second, whether it matters at all; third, who would have to do
this work in practice.

In what follows, I'll try to keep my personal preferences (that don't
matter at all as far as the TC decision is concerned) aside, but
I don't expect to be entirely successful. Sorry about that in advance.
My conscious intent here is to help make this discussion more fruitful
and focused on what matters in practice; but it's obvious that my
analysis is somehow affected by the investments I've personally made
in the last 14 months (since then, I have been very happily running
systemd on almost every Wheezy or newer system that I am responsible
for). For the sake of full-disclosure, I have to add that I am a core
developer of a Debian derivative that relies on GNOME and does not
intend to switch any time soon.

> intrigeri writes ("Bug#727708: init system other points, and conclusion"):
>> The difference lies in who are the people who "need" to do this work
>> "anyway", and who else may instead dedicate their time to other tasks,
>> lead by their own desires and needs.

> I think that it is right that the costs of undoing systemd's bundling,
> be borne by the systemd community (including systemd's advocates and
> maintainers in Debian) rather than by Debian (or the rest of the Free
> Software world) at large.

First, I beg to disagree about who, in full rightness, would have the
"moral" responsibility to do this work. But as shown below, we don't
care much about what you or I think.

Second, regardless of what my or Ian's or the TC's or $DEITY's opinion
on this moral matter is, that's very much unimportant: in my belief,
the time and energy people put into Debian is rarely lead by a sense
of "moral" responsibility, especially when the work that "needs to be
done" is something they do *not* feel to be part of what they have
committed to in the first place. I happen to very much doubt that the
systemd community feels that they are committed to support the
use-case we are discussing (systemd minus its init component).

Hence, my third point is that in practice:

* If upstart is chosen as the default init: it might be that the
  systemd community shows little interest in doing this work (and, to
  be fair, I would find this totally understandable, and not
  surprising at all). Then, it is not unlikely that the people who end
  up doing this work are those who maintain reverse dependencies of
  the systemd stack, such as desktop environments (at least GNOME and
  Unity, in Debian and/or Ubuntu). They might have to do this because
  of the combination of 1. they want to keep their packages in working
  state in Debian and/or Ubuntu; 2. the decision to use upstart
  creates the need for someone to do this work; 3. for whatever
  reason, nobody else is doing it.

  If this were to happen, regardless of anyone's take on what full
  rightness would have called for, then the cost of the initial and
  ongoing work would be held by an important subset of our community,
  that is anyone who wants Debian to deliver a given modern DE.
  I realize that it's not the same as the Debian project as a whole,
  contrary to what I initially wrote. But it's a lot more people than
  just the systemd maintainers in Debian (I'm not comparing to the
  broader systemd community here, for reasons I've given above).

* If systemd is chosen as the default init: I am very doubtful that
  a decision of the TC regarding who has the "moral" responsibility of
  it would be enough to motivate the systemd community to tackle this
  work if they don't feel it's part of the mission they are committed
  to. It might be, but I don't think it's a reasonable assumption to
  make.

  So, with the information I have in hand, I'm sticking to my original
  point here: in practice, this would be a job for porters, for anyone
  who wants to allow users of Debian to give this amount of
  flexibility, and for any derivative who wants to use another init
  system; while others treat this effort with "deference and
  reasonable accommodation", and can get themselves busy, as they
  wish, with other means to scratch their own itch and/or make the
  world a better place.

My conclusion is that 1. in practice, the situation is far from being
as simple as: the systemd commu

Re: Bug#727708: init system other points, and conclusion

[Chris Knadle]

On Tuesday, December 31, 2013 20:12:20 Josh Triplett wrote:
> Steve Langasek wrote:
> >On Tue, Dec 31, 2013 at 09:13:52PM +0100, Josselin Mouette wrote:
> >> So unless the TC wants to remove a great number of packages from the
> >> archive, you need to take into account the fact that some voluntary
> >> manpower is required to implement your decision.
> > 
> > I think the current Debian GNOME team has a not-undeserved reputation for
> > being obstructionist with respect to bugfixes that require divergence from
> > upstream's stated direction.  If the team demonstrated they were open to
> > contributions of the kind you described, volunteers to do the work would
> > not be hard to come by.
> 
> That's an impressively high amount of doublespeak packed into a single
> paragraph, particularly the words "bugfixes", "volunteers", and
> "contributions".  At a minimum, I think you're overstating the situation
> by refusing to acknowledge that the GNOME team does not consider the
> changes forced upon them to be "bugfixes". 

Responding specifically to this:

> You (and other members of the TC) disliked GNOME's requirement of
> NetworkManager, for reasons I still have yet to see explained coherently
> anywhere.  You forced the GNOME team to remove it.  I certainly hope
> you find "volunteers" willing to do that kind of work increasingly hard
> to come by.


Re: dependency removal -- sort of.  The reasoning is explained  for the most 
part in the tech-ctte decision for #681834. [1]  But just to fully make this 
clear I'll also provide a brief summary of what I think happened at the time.

network-manager conflicted with wicd; when both were installed and active, 
neither worked -- neither could detect this situation, and the resulting error 
output was not meaningful.  (wicd: "Connection failed: bad password",
N-M: "NetowrkManager is not running.  Please start it.")  Furthermore the 
documentation that came with network-manager did not in any way explain that 
this could happen nor what to do about it, nor was there a Breaks: on the 
package related to wicd to avoid the conflict.  By making network-manager a 
requirement via a dependency, anybody that previously had wicd installed would 
have their system broken, nor given any clue how to fix it.

There was a strong emphasis from GNOME maintainers that N-M integrates with 
GNOME but that alternatives such as wicd do not and thus a strong desire to 
have N-M installed; however GNOME does function with Wicd even if there are 
certain features that don't work due to lack of integration, and there were a 
known number of installation configurations (> 1000) where users of Squeeze 
had both wicd and gnome installed.

The maintainer of network-manager discussed that the user could leave
network-manager installed but disable it via running
"update-rc.d network-manager disable" as root -- there was an idea to include 
this information within the package's README.Debian file, but that didn't 
happen.

In #681834 the decision was to revert the Depends: on network-manager-gnome in 
gnome-core.  However 10 days later a new dependency was added for
network-manager-gnome within the gnome metapackage, causing a similar
network-manager dependency another way, thus having to go through the 
discussion again in #688772.  There was some discussion concerning N-M as to 
whether it was possible to detect wicd and avoid conflicts with it, but to my 
knowledge that was not completed.  Near the end of the discussion (which had 
mostly stopped) I sent a patch for the Debian Release Notes to try to explain 
this situation for users, resulting in [2], which IMHO is not adequate by 
itself for mitigating this situation.  Discussion fully stopped, and after 
some time the tech-ctte bug was closed.



If you're feeling ire for the tech-ctte but have not yet read their decisions, 
I would suggest doing so and considering them.



[1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834#273

[2]: 
http://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#network-manager-conflicts


  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
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/3068331.gcSIP34SPN@trelane

Bug#727708: init system other points, and conclusion

[Colin Watson]

On Tue, Dec 31, 2013 at 04:27:16AM -0008, cameron wrote:
> On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson 
> >inotify is used to notice changes to configuration files.  This is
> >certainly helpful for users, but it isn't critical as "initctl
> >reload-configuration" works without it.  We could probably do without
> >this with the aid of a dpkg trigger.
> 
> inotify use can easily be ported to kqueue within Upstart, or
> libinotify-kqueue can be used.

Note that I'm talking about the Hurd here.  kqueue is a kFreeBSD thing,
as far as I know.  (Compare e.g.
https://lists.debian.org/debian-hurd/2013/10/msg00021.html)

> >prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification
> >work properly when Upstart is supervising a user session.  This isn't
> >a required feature and could easily be compiled out until suitable
> >kernel support is available (this actually seems like the sort of
> >thing that could be done in the Hurd without too much difficulty, but
> >I haven't looked into it).  If absent, it might well impede the
> >ability to do an advanced desktop port, but it wouldn't get in the
> >way of porting the bulk of services.
> 
> Unity, likely the only desktop environment using Upstart as a
> session init, is not in Debian. The sacrifice of this functionality
> on non-linux systems is perfectly acceptable.

While this is true today, we need to look to the future.  Using Upstart
as a session init is not conceptually tied to Unity in any way, and I
expect that other desktop environments will want to use more advanced
session supervision soon enough.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
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/20140101125639.gb30...@riva.ucam.org

Bug#727708: loose ends for init system decision

[Colin Watson]

On Tue, Dec 31, 2013 at 10:18:08PM -0800, Russ Allbery wrote:
> For upstart readiness, obviously one needs some sort of explicit flag or
> trigger to enable the raise(SIGSTOP) behavior, since that will otherwise
> cause rather obvious problems in getting the daemon to work outside of
> upstart.  I prefer to use a command-line flag for this (-Z, per your
> recommendation) since it has to be explicitly enabled and there isn't the
> same sort of safe fallback if it's missing the way that there is for the
> systemd protocol.  I don't see any real problem with using an environment
> variable, though, as long as it's unset afterwards so that it's not
> inherited by children.

Bear in mind that this may often be being done by the Debian maintainer
in advance of upstream, and adding a one-character command-line option
is problematic since that stands a decent chance of clashing.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
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/20140101125149.ga30...@riva.ucam.org

Bug#727708: systemd status when using multiple block device layers (MD/LVM/dm-crypt) below the root-fs

[Steve Langasek]

On Tue, Dec 31, 2013 at 07:08:34PM -0800, Steve Langasek wrote:
> On Tue, Dec 31, 2013 at 11:15:33AM -0800, Russ Allbery wrote:
> > Similarly, I'm not sure why the focus on only adding necessary tools to
> > the initramfs image.  Surely this doesn't matter much if the tools are
> > harmless when unneeded?
> 
> In this context I'm not sure how applicable it is; but there are many x86
^^^
non-x86

> platforms where the bootloader doesn't have particularly impressive I/O
> performance, and having to load a large initramfs before booting the kernel
> has a major impact on boot speed.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#733452: init system daemon readiness protocol

[Tollef Fog Heen]

]] Ian Jackson 

> (Sorry, 2nd copy here because I missed up the change of To field in
> the previous one.)
> 
> cameron writes ("Re: Bug#733452: init system daemon readiness protocol"):
> > I was curious: why should SOCK_STREAM be used instead of SOCK_DGRAM in 
> > your proposed protocol?
> 
> SOCK_DGRAM sockets do not offer reliable delivery (at least, not on
> all unices).
> 
> > Have you seen Lennart Poettering's pastebin of a short daemon side 
> > implementation of that protocol: http://fpaste.org/64821/32737713/? It 
> > meets all your desired criteria, it is used in one init system already, 
> > and it is very extensible. Now that you know that systemd does not 
> > actually use SOCK_SEQPACKET, but SOCK_DGRAM, do you have any changes in 
> > opinion of the systemd approach?
> 
> I still think it would be simpler to pass the ready-connected socket
> (or whatever) to the daemon by inheritance, rather than having the
> daemon call socket() etc.
> 
> Do you know why in systemd it was done the way it was ?

Passing a file descriptor around reliably so it only ends up in the
right place is harder than doing the same with an environment variable.
Many daemons close all fds as part of the startup (this is documented as
best practice in quite a few places).

You also need to ensure that the fd given in the environment variable is
actually a valid file descriptior.  As per Lennart when asked on IRC:

17:16 < poettering> Mithrandir: anyway, the one line summary is that i
wanted this to be as simple as possible: it should suffice to place a
single sd_notify() at the appropriate place to make this work. With fd
passing that would not work, as you first have to make sure the passed
fd is not closed as part of setting up the execution environment during
daemon initialization.
17:17 < poettering> Mithrandir: sd_notify() as it stands now is really
really isolated. As long as the env var is there it doesn't need
anything else
17:17 < poettering> Mithrandir: what ian wants otoh is not so isolated,
you need to have a look at the entire daemon initialization and make
sure the fd is never closed or handled in its process, and then you
*also* need to look at the env var for it
17:17 < poettering> hope that makes sense

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/m2y530f6r4@rahvafeir.err.no