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

[Luca Boccassi]

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.