Re: Bug#770627: dbus: Please (consider) switch(ing) to no-await triggers
On 04/12/14 07:00, Niels Thykier wrote:
> On 2014-11-30 02:52, Guillem Jover wrote:
>> If this cannot be fixed in apt proper (due to requiring it to
>> self-upgrade), then it should be fixable by switching dbus to
>> noawaiting trigger directives (which I think would be correct
>> regardless).
So these triggers are: whenever a new D-Bus system service is installed
in /usr/share/dbus-1/system-services or new security policies are
installed in /etc/dbus-1/system.d, we tell the system dbus-daemon to
reload, and block until it has done so.
deb-triggers(5) says we should -noawait when "the functionality provided
by the trigger is not crucial".
My question is, crucial for who? If dbus-daemon has not yet reloaded,
then dbus-daemon will continue to work fine (it's in a consistent state
either way), but the package that shipped the system service or security
policy (in #771417 it's systemd) won't necessarily work properly until
dbus-daemon has had a chance to reload.
>From reading deb-triggers(5) and /usr/share/doc/dpkg-dev/triggers.txt.gz
it seems that the difference is that when systemd triggers dbus, with an
"interest" trigger, systemd does not satisfy other packages'
dependencies until dbus' trigger has run, forcing the trigger to be run
before other packages try to use systemd's D-Bus API; but with an
"interest-noawait" trigger, systemd is assumed to be fully working and
satisfies dependencies, potentially resulting in failed calls to its
D-Bus API because dbus-daemon's security policy does not allow them yet.
Am I correct?
If I am correct in my interpretation, then it seems to me that normal
"interest" triggers are right here. However, if there is consensus that
using the wrong trigger is a less severe bug than #771417, I can switch
to "interest-noawait" and open a bug for "should go back to ordinary
triggers post-jessie"... as long as that new bug is not *also* going to
be considered RC.
S
Reply to: