Months later, it turns out that notify-osd ships a org.freedesktop.Notifications.service already, so it conflicts with the one made by this patch.

In D5012#110815, @lbeltrame wrote:

Months later, it turns out that notify-osd ships a org.freedesktop.Notifications.service already, so it conflicts with the one made by this patch.

I wouldn't know what course of action would be best to follow in this case. @davidedmundson ?

There's no need for the .service file to match the dbus service name

We change that, we get no file colision.
I wrote a patch on Friday when someone told me on irc, but hadn't tested because I had to rebuild something.
I'm back tomorrow, will upload then.

In D5012#111331, @davidedmundson wrote:

There's no need for the .service file to match the dbus service name

We change that, we get no file colision.
I wrote a patch on Friday when someone told me on irc, but hadn't tested because I had to rebuild something.
I'm back tomorrow, will upload then.

This is not a real fix.

Quoting the specification (https://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-starting-services):

On the well-known session bus, if two .service files in the same directory offer the same service name, the result is undefined. Distributors should avoid this situation, for instance by naming session services' .service files according to their service name.

Sure, but the current state of having two notification systems was already undefined long before this patch.

Undefined trumps not being a defined state of not co-installable in this case.

There is a long term fix where service files will also go into /run/user this will solve all our problems. That's not out yet though.

In D5012#111492, @davidedmundson wrote:

Sure, but the current state of having two notification systems was already undefined long before this patch.

Two notification systems? That's not the case here as far as I can tell.

Undefined trumps not being a defined state of not co-installable in this case.

Undefined means anything can happen and thus it's worse than not being co-installable.
In our packaging we can simply make the file an optional (but recommended) dep, which means
the user can choose between this fix and co-installability with other DEs.

There is a long term fix where service files will also go into /run/user this will solve all our problems. That's not out yet though.

Generating a set of services at runtime? Sounds interesting, where can I get some more information about that from?

Fix in D5968

Undefined means anything can happen

That is what the word means, but DBus isn't a black box. We do roughly know what it will do.
If it was truly problematic, they would force the name to match, something which is enforced on the system bus.

More info

"transient service activation" is the googlable name.
https://bugs.freedesktop.org/show_bug.cgi?id=99825

It's in 1.11.12. Which I think isn't used by anyone yet