Bringing forth runit integration regarding desktop environments

[Martin Steigerwald]

Hi Mark, hi Andrew, hi Lorenzo, hi.

@Lorenzo: I mainly CC you on where to ship runit dir for
power-profiles-daemon. Given the time frame for Debian Trixie and given
I have not yet asked the package maintainer and given I am more familiar
with providing a MR for runit-services than for a third party package, I'd
opt for runit-services for now. And I know I still have incus and lxcfs to
go. It might be easier to get everything done in case I can go for
runit-services with power-profiles-daemon for now and try the put it into
the package approach with incus and lxcfs. The maintainer of those has
been very welcoming and friendly and already accepted SYSV init scripts.
On the other hand first going for runit-services and then aiming at
inclusion into power-profiles-daemon… is also additional work.

I am finally coming back to this one:

Martin Steigerwald - 09.11.24, 13:40:38 MEZ:
[…]
> However I wonder about doing some work for desktop integration as well.
> 
> I will do a power-profiles-daemon service dir. Probably based on what
> Void linux maintainers have been doing and probably still today:
> 
> https://github.com/void-linux/void-packages/tree/master/srcpkgs/power-pr
> ofiles-daemon/files/power-profiles-daemon

I finally did one. The run script basically goes like:

#!/usr/bin/env /lib/runit/invoke-run
#[…]

sv start dbus ||  exit 170

exec 2>&1

if [ -e /etc/runit/verbose ]; then
        echo "Invoke-run: starting ${PWD##*/}"
fi

exec /usr/libexec/power-profiles-daemon

Instead of using "sv check dbus >/dev/null || exit 1" as in Void Linux,
I copied over the "sv start dbus" line from elogind run script. I did not
test the run script with that yet, but I will see whether it works with
that line added after the next reboot.

Also there is a different approach that would work with all init systems:

Alpine Linux basically just patches the upstream DBUS activation file like
this:

-Exec=/bin/false
+Exec=/usr/libexec/power-profiles-daemon

https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/power-profiles-daemon/0001-dbus-no-systemd.patch

The power-profiles-daemon package from Debian ships this file as:

/usr/share/dbus-1/system-services/org.freedesktop.UPower.PowerProfiles.service

It looks like if the patch from Alpine would just apply… however finding
a solution to divert this file on alternate init based systems while
keeping the original for Systemd based systems… I don't know. So maybe
doing it per init is the better approach.

As for shipping a runit service… I could ask the maintainer of the package
or it could be shipped in runit-services. Given the timeline till Trixie it might
be more realistic to get it into runit-services.

> And again I also wondered about pipewire integration as well. AFAIR
> according to some discussion about it this cannot really be handled as a
> system service, but needs to be tied to the user session, probably by
> DBUS activation.
> 
> Maybe what Alpine does there would be a good approach:
> 
> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/pip
> ewire/pipewire-launcher.sh
> 
> I believe I read from a Devuan user that this would work. But I did not
> find that mail anymore. So I am not completely sure where to integrate
> Pipewire startup properly.

I now did this *exactly* as done in Alpine Linux. Which basically means:

- pipewire.desktop => /etc/xdg/autostart
- pipewire-launcher.sh => /usr/libexec/pipewire-launcher

https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/pipewire/APKBUILD#L120

And then it is XDG autostart which should work with all init systems.

I will test this over the coming days. But so far it appears to work just
fine. I removed Pulseaudio package and sound still works :).

One disadvantage is: Services are not stopped on logout. That is why the
scripts tries to stop them at the beginning. I am not sure whether stopping
on logout could be achieved with DBUS activation. I doubt it.

Also of course there is no service supervision. But given the time frame
for Trixie this might be the most realistic approach.

How to ship this to users is a different question though. Maybe in an extra
package like "pipewire-xdg" or "pipewire-autostart". And ask the maintainer
of Pipewire to add a suggests or so. Or in case there are additional
services for desktops that make sense to be started with either XDG
autostart or DBUS activation, there could be a more generic package like
"desktop-services" or something like that. But then how to select such a
package for users of alternative init systems?

Another approach would be to make /usr/libexec/pipewire-launcher exit
immediately when Systemd is found and then ask the Pipeware package
maintainer to ship both files with the package. That way all users would
benefit from it. However… not sure whether the Pipewire maintainer will
accept such an approach. On the other hand I will not know unless I ask.

What do you think?

> Of course the unit-translator approach by Mark is also something that
> probably can help here, however I prefer hand-crafted service dirs.

I am happy to see that this in Debian archive meanwhile! Maybe after
Trixie release I look into a Runit backend for it.

> Regarding Pipewire as  a session related service an approach that would
> work with all init systems would be nice. I bet some kind of DBUS
> service activation will work on all init systems.

Or well that XDG auto start approach from above.

I just wonder about XDG auto start versus DBUS activation but what gives.
For now I just try with what works in Alpine Linux.

Best,
-- 
Martin