Bug#1025349: gdm3: should define the display-manager alias for start dependencies

[Luca Boccassi]

Control: tags -1 patch

On Thu, 12 Jun 2025 at 17:23, Luca Boccassi <bluca at debian.org> wrote:
>
> On Thu, 12 Jun 2025 at 10:13, Simon McVittie <smcv at debian.org> wrote:
> >
> > On Thu, 12 Jun 2025 at 00:51:51 +0100, Luca Boccassi wrote:
> > >On Mon, 5 Dec 2022 00:15:01 +0000 Simon McVittie <smcv at debian.org>
> > >wrote:
> > >> In Debian, instead of gdm3.service having that, the debconf question
> > >> creates that symlink programmatically if and only if gdm3 is the
> > >selected
> > >> display manager (in particular, the symlink isn't created if you have
> > >> installed both gdm3 and lightdm, and chosen to use lightdm instead).
> > >
> > >The same can be achieved by using the Alias mechanism. Simply run
> > >'systemctl enable <selected>.service' instead of creating the symlink
> > >manually.
> >
> > That's fine if all display managers agree to have an Alias, and only
> > enable themselves if they are the single selected display manager, via a
> > coordinated change to the common code that is in all display managers'
> > postinsts. It isn't obvious to me that it would work as intended if half
> > the display managers have the current implementation, and the other half
> > use an Alias and `systemctl enable`. Perhaps I'm overthinking this and
> > it's fine, but if it isn't obvious to me, then I expect it won't be
> > obvious to the release team either.
>
> I don't think that would be a problem? The existing infrastructure
> around debconf et al. can remain, all I'm asking is to change the
> mechanism that creates/removes the symlink: rather than manual ln -s
> and rm -f, have an alias and do enable/disable, so that existing
> automated systems can also deal with it, without having to rely on the
> maintainer script. If one package does that, and another keeps the
> ln/rm, there shouldn't be any issue, as the end result is the same?
>
> As long as the alias is disabled first, whoever owns it doesn't
> matter, the link is removed, and the new one can be added. E.G. with a
> fictional gdm4 that is just a copy of gdm3:
>
> root at particle-e2ce-7be4:~# deb-systemd-invoke disable display-manager
> Removed '/etc/systemd/system/display-manager.service'.
> root at particle-e2ce-7be4:~# deb-systemd-invoke enable gdm4
> Created symlink '/etc/systemd/system/display-manager.service' →
> '/etc/systemd/system/gdm4.service'.
> root at particle-e2ce-7be4:~# deb-systemd-invoke disable display-manager
> Removed '/etc/systemd/system/display-manager.service'.
> root at particle-e2ce-7be4:~# deb-systemd-invoke enable gdm
> Created symlink '/etc/systemd/system/display-manager.service' →
> '/usr/lib/systemd/system/gdm.service'.
>
> But again as mentioned in the other MR, no need to rush this, it can
> wait for Forky, I certainly don't want to inconvenience anyone while
> you are busy working on the release.
>
> > So I think it's too late to make a coordinated change like that for
> > trixie, but it seems like a good thing to aim for during the early part
> > of the forky cycle. Can you prototype this in at least a few display
> > managers (gdm3, lightdm and sddm are probably the most important), test
> > the interaction between them, and do the coordination after the forky
> > cycle opens to make this change distro-wide?
>
> That's a bit too much for me, I might get around to send a MR for
> gdm3, but I don't use the other ones. As mentioned above, there's no
> need for coordination anyway.
>
> > Do I assume correctly that we'd want the postinst to use deb-systemd-helper
> > rather than calling `systemctl enable` directly?
>
> Yeah that's fine
>
> > >The problem with manually creating things in maintainer scripts is that
> > >this is not compatible with building image-based systems with usr-only
> > >and ephemeral/first-boot etc. With an alias in the unit, the preset
> > >runs on first boot and re-creates it if needed, for any unit, for any
> > >purpose.
> >
> > How does that work if, for example, both gdm3 and lightdm are installed?
> > Which one will the systemd preset choose to "win" when they both want to
> > be enabled?
> >
> > (If the answer is "image-based systems with more than one display
> > manager don't make sense, use a traditional package-based system if you
> > want this level of flexibility" then perhaps that's OK as something to
> > document as a limitation and otherwise leave unfixed.)
>
> That's a local configuration, so it can be the preferred one, or none.
> Currently in particleos we don't enable any, you enable the preferred
> one on first boot. The preset file can list the default one, and one
> can switch after booting, for example.
> Or it can be all hard-coded and you have different flavours. Both are possible.

Actually we can make it even simpler: just restore the alias. The
maintainer scripts can remain as-is.

Other display managers leave the alias in place as well:

https://sources.debian.org/src/lightdm/1.32.0-6/debian/lightdm.service
https://sources.debian.org/src/sddm/0.21.0%2Bgit20250502.4fe234b-2/debian/sddm.service
https://sources.debian.org/src/wdm/1.28-27/debian/wdm.service

MR: https://salsa.debian.org/gnome-team/gdm/-/merge_requests/33