bus1 / dbus-broker

Linux D-Bus Message Broker
https://github.com/bus1/dbus-broker/wiki
Apache License 2.0
677 stars 80 forks source link

Service file is not named after the D-Bus name #247

Closed WhyNotHugo closed 3 years ago

WhyNotHugo commented 3 years ago

I'm seeing this warning in my logs:

 Nov 25 10:00:48 victory dbus-broker-launch[879]: Service file '/usr/share/dbus-1/services/org.jackaudio.service' is not named after the D-Bus name 'org.jackaudio.service'.

However, the file is clearly named after the D-Bus service.

$ cat /usr/share/dbus-1/services/org.jackaudio.service
[D-BUS Service]
Name=org.jackaudio.service
Exec=/usr/bin/jackdbus auto
dvdhrm commented 3 years ago

This is really unfortunately phrased here, sorry. The file needs to be named like the service name, plus the suffix .service.

Thing is, all service files must be suffixed *.service (as defined by dbus-daemon, the reference implementation) and the part before that suffix should be the service-name given as Name= in the file itself. The reference implementation only ever enforced this rule for the system bus, for other buses it only warns. dbus-broker needs to mirror that behavior.

In your case, I would recommend using Name=org.jackaudio (without the .service suffix). But that would be an API break, if that name is already part of a release. If it is, then the way to fix this is to call the file org.jackaudio.service.service (note the double .service suffix).

WhyNotHugo commented 3 years ago

Thanks for the thorough explanation!

This service file is part of jack. Changing the service name would likely break too many things.

However, it renaming the file should work. I'll mention this upstream.

The reference implementation only ever enforced this rule for the system bus, for other buses it only warns. dbus-broker needs to mirror that behaviour.

Huh, this is a very weird rule.

In particular, because it does not allow the existence of multiple implementations that provide the same service. E.g.: many apps provide org.freedesktop.Notifications. If they had to include a dbus service file with the name org.freedesktop.Notifications.service, it would not be possible to install them onto the same system.

Isn't it somewhat conflicting with the idea behind DBus: that there can be exist implementations of one single service? (though only one can run at once).

dvdhrm commented 3 years ago

Thanks for the thorough explanation!

This service file is part of jack. Changing the service name would likely break too many things.

However, it renaming the file should work. I'll mention this upstream.

Indeed, if it is part of a release, renaming the file is the correct approach. Feel free to put me on CC, if any input from upstream dbus-broker is needed.

In particular, because it does not allow the existence of multiple implementations that provide the same service. E.g.: many apps provide org.freedesktop.Notifications. If they had to include a dbus service file with the name org.freedesktop.Notifications.service, it would not be possible to install them onto the same system.

Isn't it somewhat conflicting with the idea behind DBus: that there can be exist implementations of one single service? (though only one can run at once).

I think you are conflating dbus-interfaces with dbus-names. The term org.freedesktop.Notifications most likely refers to an interface, which any dbus client can implement, even in parallel with others. Similar to interfaces in Java, or abstract classes in C++, or traits in Rust, etc.

In contrast, D-Bus Well-Known Names are ways to identify a peer on the bus, hence it must be unique. Names are used to route messages, and are thus more comparable to pointers or references in normal programming languages. They do not define what type of object they point to, they are merely named identifiers.