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. > 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. > +stop on deconfiguring-networking This appears to have caused some rather upset bug reports in Ubuntu (<https://bugs.freedesktop.org/show_bug.cgi?id=76344>, <https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1072518>) and I don't really want to have to field those bug reports in Debian too. I believe the rationale is that dbus-daemon is in /usr which could conceivably be NFS. Ubuntu's src:dbus packages install more of their contents to the root directory. I briefly tried to do similarly in Debian, but it caused regressions, so I had to revert it. System service-activation will not work correctly until /usr/share/dbus-1/system-services becomes available, so moving the daemon to the rootfs probably doesn't help as much as you might think. > +start on local-filesystems Similarly, this doesn't necessarily provide /usr. S -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
