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