This is an alternative to https://bugs.debian.org/1107944 . I figured
it is expressed differently enough to be worth a separate bug.

GDM 49 now uses dynamic users for greeter sessions. (By the way, the
merge request that landed this said that it allows gdm to be used with
dbus-broker instead of dbus-daemon).

Therefore, Arch Linux now installs gdm without a system user. It does
have a gdm **group** created with this sysusers snippet:
g gdm 120 -

That sets a UID for the group of 120. In Debian, I don't believe we
care about the gdm UID, so a Debian version would look like one of
these 2 lines, depending on whether we decide to keep the
Debian-specific group name:
g Debian-gdm - -
g gdm - -

Then there is this proposal to store dconf overrides in /etc/dconf/gdm.d/
https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/312

We could then remove our 91_dconf_database_path.patch. We have several
packaging files that reference dconf that would need to be updated.

Upgrades are an extra complication. In the long term, having a drop-in
directory for dconf overrides makes it simpler for users and system
administrators to override Debian defaults.

References
----------------
- https://gitlab.archlinux.org/archlinux/packaging/packages/gdm/-/blob/main/PKGBUILD
- https://src.fedoraproject.org/rpms/gdm/blob/rawhide/f/gdm.sysusers
Fedora 43 still creates a gdm user
- https://gitlab.gnome.org/GNOME/gdm/-/issues/553

Thank you,
Jeremy Bícha

This causes its own problems for us if we cannot rely on libnss_systemd
working correctly in all installations: see #1116563. But for the
purposes of this bug let's assume that we can.
name is something like George David Miller, it's completely reasonable
that you would want to use your initials, gdm, as your own login name
(which also becomes your user's group name). So we should use Debian-gdm
(hysterical raisins) or _gdm (as per Policy §9.2.1).

This is great - it would let us stop doing our downstream-specific
things with /var/lib/gdm3/greeter-dconf-defaults.

I think we'd still need to regenerate /etc/dconf/db/gdm from
/etc/dconf/db/gdm.d during gdm startup? But perhaps that would be
upstreamable.

Yes. If the user has edited /etc/gdm3/greeter.dconf-defaults, those
changes should be propagated into the new thing on upgrade. If it's the
same format (which I think it is) then it could be as simple as doing a
mv_conffile operation from /etc/gdm3/greeter.dconf-defaults to
/etc/dconf/db/gdm.d/greeter.dconf-defaults or similar.

     smcv