[Pkg-utopia-maintainers] Bug#712167: dbus: add upstart init support

[Dimitri John Ledkov]

On 26 March 2014 10:46, Simon McVittie <smcv at debian.org> wrote:
> On Tue, 25 Mar 2014 at 22:41:32 -0007, Cameron Norman wrote:
>> I have attached a deb diff that includes an upstart job. It is different
>> from the previous diff by Dimitri because it prompts for a reboot in the
>> post installation regardless, per Simon McVittie's suggestion.
>
> That seems sensible. I might apply that change regardless of
> whether we ever have Upstart support.
>
>> It also uses the --nopidfile option to start dbus.
>
> Does the combination of "expect fork" and "there is no pid file" work
> properly? I'm somewhat surprised if it does; but if Upstart has some
> clever trick to follow processes even though they double-fork (like systemd's
> use of cgroups), then that's fine.
>

this works fine under upstart.

>> Please consider this for inclusion
>
> Given that Ubuntu is the major user of Upstart, already has a
> heavily-patched src:dbus with considerable Upstart support code that
> didn't go upstream, and will be switching to systemd in future,
> how much benefit is there in having a native Upstart job for dbus
> in Debian? I'm concerned that the risks (and effort required) may
> outweigh the benefits.
>
> More specifically, is anyone volunteering to maintain dbus' Upstart support
> by watching bug reports and "owning" any relevant bugs? I'm not going to
> test this configuration, and if it causes RC bugs that aren't addressed by an
> Upstart user, I'd be inclined to revert it rather than spending time on it.
>

i can subscribe to dbus package in debian.

>> +stop on deconfiguring-networking
>

This is correct.

> This appears to have caused some rather upset bug reports in Ubuntu

These problems are unrelated to dbus package, and are not bugs dbus
job. Despite the confusing state the user's machines were left in =)))
It was a bug in upstart jobs in the ifupdown package which has been
resolved recently.

>
>> +start on local-filesystems
>
> Similarly, this doesn't necessarily provide /usr.
>

    start on remote-filesystems

is emitted after /usr and all virtual filesystems are available (/run
et al). Maybe that's a better fit on Debian.

-- 
Regards,

Dimitri.