On Mon, 06 May 2024 at 08:05:55 +0200, Niels Thykier wrote:
> I thought the order was sysusers (to create the user) and then tmpfiles (to
> create files/directories and set ownership accordingly). In this bug report,
> the request is to have the directories first before the user is created.
The request to run tmpfiles before sysusers seems wrong to me, and I think
it should be wontfix. The directories certainly can't be successfully
created owned by the gnome-remote-desktop user before the user even
exists!
My understanding is that the sequence should be:
1. sysusers: Create user
2. tmpfiles: Create home directory owned by that user
3. systemctl daemon-reload
4. Start system services that run as that user
And if there are any systemd *user* services that rely on the tmpfiles
snippet, they will also need to be set up no earlier than step 3.
It looks as though debhelper itself, in a sufficiently new compat level,
gets this right:
$include_if_compat_X_or_newer->(14, 'dh_installsysusers'),
$include_if_compat_X_or_newer->(13, 'dh_installtmpfiles'),
$include_if_compat_X_or_newer->(11, 'dh_installsystemd'),
$include_if_compat_X_or_newer->(12, 'dh_installsystemduser'),
In older compat levels, opting-in to dh-sequence-installsysusers triggers
somewhat earlier:
insert_after('dh_install', 'dh_installsysusers');
but that seems like it should be fine too: the important thing is that
we get sysusers -> tmpfiles -> systemd{,user} in that order.
I think the *actual* bug here is that gnome-remote-desktop installs a
D-Bus policy fragment to allow the gnome-remote-desktop user to own the
org.gnome.RemoteDesktop name, but the postinst does not ensure that
the D-Bus system message bus (dbus-daemon or dbus-broker) has reloaded
its configuration before attempting to start gnome-remote-desktop.
I'll follow up to #1070119 with more details since this is not a
debhelper problem.
smcv
