Control: tags -1 patch On Thu, 12 Jun 2025 at 17:23, Luca Boccassi <[email protected]> wrote: > > On Thu, 12 Jun 2025 at 10:13, Simon McVittie <[email protected]> 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 <[email protected]> > > >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@particle-e2ce-7be4:~# deb-systemd-invoke disable display-manager > Removed '/etc/systemd/system/display-manager.service'. > root@particle-e2ce-7be4:~# deb-systemd-invoke enable gdm4 > Created symlink '/etc/systemd/system/display-manager.service' → > '/etc/systemd/system/gdm4.service'. > root@particle-e2ce-7be4:~# deb-systemd-invoke disable display-manager > Removed '/etc/systemd/system/display-manager.service'. > root@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
