Which D-Bus services do you want to disable in this way? Can't you just uninstall those services?

I would like to be careful about the ability to disable activatable D-Bus services, since it undermines package dependencies: if you have a package installed that needs a service com.example.Foo, it would normally have "Depends: foo-daemon" (dpkg) or "Requires: foo-daemon" (RPM). If activatable services can be disabled, this dependency is no longer sufficient to ensure that the com.example.Foo service can be obtained, and the depending package doesn't necessarily work any more.

Unlike init-launched daemons, D-Bus services are only launched if something communicates with them: services that aren't requested don't get launched. As a result, whenever you disable a service that would normally be launched, you're likely to be breaking an application that depends on that service.

(In reply to comment #0)
> I suggest adding an extra key to the service file 'Enabled=' with possible
> values 'Yes' or 'No'.

For session services, a service file in ~/.local/share/dbus-1/services takes precedence over the one in /usr/share, so your Enabled idea could work.

For system services, that isn't actually enough: package upgrades will (and should) still overwrite the service file in /usr/share. If you need to disable system services, the mechanism to do so is system configuration, so it needs to be in /etc. For instance, it could work like systemd's "/etc overrides /lib" semantics.

(In reply to comment #1)
> I would like to be careful about the ability to disable activatable D-Bus
> services, since it undermines package dependencies: if you have a package
> installed that needs a service com.example.Foo, it would normally have
> "Depends: foo-daemon" (dpkg) or "Requires: foo-daemon" (RPM).

In Debian-derived distributions, if you have a package installed that *can* use a service com.example.Foo but works OK without it, it should have a "Recommends" or "Suggests" relationship with foo-daemon instead of "Depends", allowing you to remove foo-daemon. I don't know whether these weaker dependencies are possible in non-dpkg package management systems yet.

(In reply to comment #1)
> Which D-Bus services do you want to disable in this way? Can't you just
> uninstall those services?

Well, in Fedora 17, I wanted to stop zeitgeist from running. Of course I first tried to uninstall but it tried to take the whole of KDE with it, so that was no option. After the service didn't show up in systemctl or chkconfig, I found it in /usr/share/dbus-1/services. After removing it from there, the service stopped running and nothing appears to be broken.

> 
> I would like to be careful about the ability to disable activatable D-Bus
> services, since it undermines package dependencies: if you have a package
> installed that needs a service com.example.Foo, it would normally have
> "Depends: foo-daemon" (dpkg) or "Requires: foo-daemon" (RPM). If activatable
> services can be disabled, this dependency is no longer sufficient to ensure
> that the com.example.Foo service can be obtained, and the depending package
> doesn't necessarily work any more.

Yes, I understand. That is part of the reason I also mentioned the 'description' key. For example, in KDE you can disable the khotkeys daemon, but in the dialog where you do that the description used to say something like 'Note: if you disable this daemon keyboard shortcuts will no longer work'. And then the user can decide. Anyway, any installed services will/should be enabled by default, so I'd say you can assume a user who explicitly disables something does so for a reason, and if things instantly break, he/she will remember disabling a service 3 seconds earlier and hopefully have the common sense to reactivate it.

> 
> Unlike init-launched daemons, D-Bus services are only launched if something
> communicates with them: services that aren't requested don't get launched. As a
> result, whenever you disable a service that would normally be launched, you're
> likely to be breaking an application that depends on that service.
> 
> (In reply to comment #0)
> > I suggest adding an extra key to the service file 'Enabled=' with possible
> > values 'Yes' or 'No'.
> 
> For session services, a service file in ~/.local/share/dbus-1/services takes
> precedence over the one in /usr/share, so your Enabled idea could work.
> 
> For system services, that isn't actually enough: package upgrades will (and
> should) still overwrite the service file in /usr/share. If you need to disable
> system services, the mechanism to do so is system configuration, so it needs to
> be in /etc. For instance, it could work like systemd's "/etc overrides /lib"
> semantics.

Right, I hadn't realized that (I actually only had session services in mind), but that's true of course. Do I understand correctly that creating an empty 'foo.service' file in ~/.local/share/dbus-1/services effectively disables the foo service by taking precedence over the (working) foo.service file in /usr/share? Because that would, for session services, actually be a nicer solution than removing the file from the root-owned location (and it would survives updates).

I'm not sure about the weaker dependencies, or suggested packages in rpm, but maybe I should file a bug against kde for depending on zeitgeist anyway...

Thanks!

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/70.

Happy to find guidance and need of providing standardized way to disable services started by dbus and methods to disable a service immediately which are justly hackish and don't survive a package upgrade/reinstall.
Alex,
http://www.qualityassignment.co.uk/