On Sat, 29 Jan 2022 at 20:12:21 +0000, Simon McVittie wrote:
> I propose this entry for virtual-package-names-list.yaml:
> 
> - name: wayland-session
>   description: a Wayland desktop session 
> (/usr/share/wayland-sessions/*.desktop)

Having looked more closely at display managers, I think we should also
consider adding:

- name: x-session
  description: an X11 desktop session registered via 
/usr/share/xsessions/*.desktop

because there are three common ways for an x-display-manager to choose what
sessions to offer:

1. Older or simpler display managers (xdm, nodm) unconditionally run
   /etc/X11/Xsession or equivalent, which results in running ~/.xsessionrc,
   /etc/alternatives/x-session-manager or various similar things

2. Newer display managers (gdm3, sddm, slim, lxdm) look for Wayland
   sessions and/or X11 sessions represented by .desktop files in various
   locations[1], of which the most suitable for distribution packagers are
   /usr/share/xsessions and /usr/share/wayland-sessions

3. Some of the .desktop-based display managers (lightdm and historically
   gdm3) additionally install their own .desktop file to make the
   xdm-style /etc/X11/Xsession or equivalent (from 1.) appear in the menu
   of .desktop files (from 2.)

If a display manager is in category 1, it would be appropriate for it to
depend on x-session-manager | x-window-manager | x-terminal-emulator.

However, if a display manager is in category 2, then that dependency is
actually incorrect, because not every x-window-manager is designed to
be usable as a desktop session in its own right (some of them are just
components of a larger desktop environment, like KDE's kwin-x11 as a
component of the Plasma desktop), and therefore not every x-window-manager
has (or should have!) a file in /usr/share/xsessions/*.desktop.

Strictly speaking I don't think there's any guarantee that every
x-session-manager has /usr/share/xsessions/*.desktop either, although
it seems to be 90% true for current packages in unstable[2].

So I think x-display-manager implementations in category 2 should be
depending on [their preferred session] | wayland-session | x-session
(omitting wayland-session if they are X11-only), perhaps with
x-session-manager as an additional alternative for backwards compatibility.

Alternatively, display managers could relax that dependency to a Recommends
or Suggests, or omit it completely (in fact this seems to be what most
display managers do at the moment). However, gdm3 has historically had a
dependency on something resembling a desktop environment, and I would not
want to drop that dependency unless there is consensus that installing
gdm3, without also installing a desktop environment that it can log into,
is a sysadmin error rather than a bug in gdm3.

I tested all x-display-manager implementations in sid and it looks like
they break down like this:

1. traditional /etc/X11/Xsession: xdm, nodm
1a. /etc/X11/Xsession plus a hard-coded list of extra options?: wdm
2. xsessions/*.desktop: gdm3, sddm, slim, lxdm
3. combining (1.) and (2.): lightdm

I think category 3 leads to a bad user experience, which is why I removed
the equivalent from gdm3: the display manager cannot predict what will
happen if /etc/X11/Xsession is chosen, so it has to name the option
something very general, like lightdm's "Default Xsession" or older gdm3
versions' "System X11 Default". This is particularly misleading if the
display manager actually has a different default, as gdm3 has done since
the switch to Wayland-by-default. (See also lightdm bug #1004559.)

    smcv

[1] For example gdm3 currently searches /usr/{,local/}share/xsessions,
    /etc/X11/sessions, /etc/gdm3/Sessions, /usr/share/gdm/BuiltInSessions
    and /usr/{,local/}share/wayland-sessions, some of which are gdm-specific
[2] cinnamon-session Provides x-session-manager, but
    /usr/share/xsessions/cinnamon.desktop is in cinnamon-common, a
    "larger" package.
    lxsession Provides x-session-manager, but
    /usr/share/xsessions/LXDE.desktop is in openbox-lxde-session, again
    a "larger" package.

Reply via email to