We had a similar issue on pulseaudio (bug 1083473), and PA package still contain a workaround.
Maybe still some bits missing in systemd macro?

I think this is probably a case of "package upgraded instead of installed".

The %systemd_user_post macro checks the vendor preset and enables user services only when a package is installed for the first time. Otherwise users that disable a vendor-enabled service would have them enabled again on every package update.

Actually, if a package update introduces a new service it would get enabled correctly. The problem with pipewire was that the service was introduced before the systemd macro in the package so if we want to get it automatically enabled with updates we need to either:

* Add a workaround like the one in pulseaudio that enables the services on every package update
* Add a similar workaround but store some lock file somewhere so it's only enabled once on the first update to a package including the workaround.
* Change the service name (which is, I think, standard across distributions so I don't think we should do that).

Just to check it, Lukas, can you test removing the pipewire package from your system and installing it again to see if the service is enabled automatically in that case or if there's something else wrong?

(In reply to Antonio Larrosa from comment #2)
> Just to check it, Lukas, can you test removing the pipewire package from
> your system and installing it again to see if the service is enabled
> automatically in that case or if there's something else wrong?

Removing and installing does enable the service correctly.

A bit unrelated but uninstalling pipewire-pulse also removes all pulseaudio-related packages including plasma5-pa which means no sound setting in Plasma at all until you install it again. Installing pipewire-pulse should probably recommend plasma5-pa at least.

(In reply to Antonio Larrosa from comment #2)
> Actually, if a package update introduces a new service it would get enabled
> correctly. The problem with pipewire was that the service was introduced
> before the systemd macro in the package so if we want to get it
> automatically enabled with updates we need to either:

Hm can't you just rebuild the package since the macro is now supposed to handle the "service introduced via an update" case properly ?

(In reply to Franck Bui from comment #4)
> (In reply to Antonio Larrosa from comment #2)
> > Actually, if a package update introduces a new service it would get enabled
> > correctly. The problem with pipewire was that the service was introduced
> > before the systemd macro in the package so if we want to get it
> > automatically enabled with updates we need to either:
> 
> Hm can't you just rebuild the package since the macro is now supposed to
> handle the "service introduced via an update" case properly ?

The macro now handles the "service introduced via an update" properly (as in "the service doesn't exist in the system and then an update installs it for the first time"), but the service was already introduced before the macro was updated (briefly, but I'm afraid there was a period of time when pipewire-pulse installed the service and didn't have the fixed macros), so now the %systemd_user_pre macro checks for the existence of the service and since it's there, it doesn't mark any work for %systemd_user_post to do.

I'll try to add tomorrow a workaround that forces the service preset to be set and then stores a lock file somewhere (something like /var/lib/systemd_preset_workaround/${service_name} but I'll try to find a better name/place) so the workaround is only executed once.

(In reply to Antonio Larrosa from comment #5)
> but the service was already introduced before the macro
> was updated (briefly, but I'm afraid there was a period of time when
> pipewire-pulse installed the service and didn't have the fixed macros)

For those who updated the package including the new service with the broken macros then I'm afraid there's not much we can do.

But since users were only briefly exposed to that broken case maybe a few of them were affected...

> I'll try to add tomorrow a workaround that forces the service preset to be
> set and then stores a lock file somewhere (something like
> /var/lib/systemd_preset_workaround/${service_name} but I'll try to find a
> better name/place) so the workaround is only executed once.

Well I'm sorry but I won't include such workaround in the systemd rpm macros if that's your idea. We had "fun" time to clean them up from all hacks that were accumulated over the past years and reintroducing a new one sounds the wrong thing to do, especially since it's going to break any setups where users explicitly disabled the service.

(In reply to Franck Bui from comment #6)
> (In reply to Antonio Larrosa from comment #5)
> > but the service was already introduced before the macro
> > was updated (briefly, but I'm afraid there was a period of time when
> > pipewire-pulse installed the service and didn't have the fixed macros)
> 
> For those who updated the package including the new service with the broken
> macros then I'm afraid there's not much we can do.
> 
> But since users were only briefly exposed to that broken case maybe a few of
> them were affected...
> 

I've already seen a few bug reports about that, so I'm afraid they're a bit more than "a few".

> > I'll try to add tomorrow a workaround that forces the service preset to be
> > set and then stores a lock file somewhere (something like
> > /var/lib/systemd_preset_workaround/${service_name} but I'll try to find a
> > better name/place) so the workaround is only executed once.
> 
> Well I'm sorry but I won't include such workaround in the systemd rpm macros
> if that's your idea. We had "fun" time to clean them up from all hacks that
> were accumulated over the past years and reintroducing a new one sounds the
> wrong thing to do, especially since it's going to break any setups where
> users explicitly disabled the service.

Of course, that wasn't my idea. I was thinking on including the workaround in pipewire-pulse and pulseaudio (in fact, pulseaudio already includes a workaround but it enables the service on every update, so executing it only once more would be IMHO an improvement). I was just thinking on doing it in a generic way because it might be useful for other packages in the future too, so they could copy a few lines into their own %post section if needed.

(In reply to Antonio Larrosa from comment #7)
> I've already seen a few bug reports about that, so I'm afraid they're a bit
> more than "a few".

pipewire-pulse (during a short time frame), maybe pulseaudio, what else ?

> Of course, that wasn't my idea. I was thinking on including the workaround
> in pipewire-pulse and pulseaudio 

Ok, I misunderstood you then let me reassign this bug to you ;)

Thanks.

This is an autogenerated message for OBS integration:
This bug (1184852) was mentioned in
https://build.opensuse.org/request/show/896634 Factory / pipewire

SUSE-RU-2021:2260-1: An update that has three recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1183012,1184852,1186561
CVE References: 
JIRA References: 
Sources used:
SUSE Linux Enterprise Module for Desktop Applications 15-SP3 (src):    pipewire-0.3.24-4.3.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

openSUSE-RU-2021:2260-1: An update that has three recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1183012,1184852,1186561
CVE References: 
JIRA References: 
Sources used:
openSUSE Leap 15.3 (src):    pipewire-0.3.24-4.3.1