GNOME's gdm3 and KDE's sddm both enumerate possible Wayland sessions in
/usr/{,local/}share/wayland-sessions/*.desktop and make them available
as desktop sessions that users can choose, in addition to listing the
X11 sessions that they traditionally did.

At the moment, installing gdm3 pulls in either gnome-session (a minimal
GNOME desktop), or some sort of X11 thing (usually a session manager,
but sometimes a window manager or an xterm), but it should ideally
be possible to install gdm3 as a login prompt from which to launch a
non-GNOME Wayland session like weston or sway.

I propose this entry for virtual-package-names-list.yaml:

- name: wayland-session
  description: a Wayland desktop session (/usr/share/wayland-sessions/*.desktop)

According to `apt-file search`, it should initially be provided by these:

gnome-session: /usr/share/wayland-sessions/gnome.desktop
phosh: /usr/share/wayland-sessions/phosh.desktop
plasma-workspace-wayland: /usr/share/wayland-sessions/plasmawayland.desktop
sway: /usr/share/wayland-sessions/sway.desktop
weston: /usr/share/wayland-sessions/weston.desktop

and perhaps also (I don't know how practical this one is for actual use):

mir-demos: /usr/share/wayland-sessions/mir-shell.desktop

Rationale for not using the names people are probably going to suggest:

- wayland-compositor would be wrong, because it's too low-level. Some
  Wayland compositors are a somewhat complete desktop environment in their
  own right, but for example plasma-workspace-wayland and gnome-session
  are larger components that merely *depend on* a Wayland compositor, plus
  the additional components needed to get a practical desktop environment;
  meanwhile, kwin-wayland and gnome-shell are Wayland compositors, but
  are not desktop environments on their own.

- wayland-session-manager seems like it would be misleading, because an X
  session manager has specific functional expectations (XSMP) separating
  it from an mere x-window-manager, but there's no such thing in Wayland.

    smcv

Simon McVittie <smcv@debian.org> writes:

I trust Simon to understand the issues here and nothing about this jumps
out as a problem, so seconded.  This seems like an appropriate use of a
virtual package because this is a fairly broad-ranging interface that will
require coordination between separate packaging teams (such as the GNOME
and KDE teams).

Hello,

Seems fine.  Just to confirm, the primary use case is so that if a
package providing wayland-session is installed, a display manager like
gdm3 won't try to install GNOME?

I like the idea. Just another idea for the naming, about
wayland-desktop-session?

Regards,
Stephan

I like the idea. Just another idea for the naming, about
wayland-desktop-session?

Regards,
Stephan

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.

It's longer and Phosh is not exactly a "desktop" ;)

Kind regards,
Andrei

file location (/usr/share/wayland-sessions/*.desktop) is also a bit
off, right? I guess this depends on how one defines "desktop" ;)

Actually, just out of curiosity: the folder is called
"wayland-sessions", but the files are all called "*.desktop". Are
there other possibilities than "*.desktop", and if so what is the
difference? If yes, then maybe there is a point to make for
"wayland-desktop-session", else the shorter name is preferable of
course.

Regards,
Stephan

.desktop is just a standard file format used to register applications
with desktop environment, see
<https://www.freedesktop.org/wiki/Specifications/desktop-entry-spec/>

I prefer wayland-session over wayland-desktop-session.

Cheers,

Ah thanks! I somehow didn't expect it to be the same as the usual
.desktop file format as for applications.

Then I agree on the "wayland-session" name. But maybe the description
should remove the word "desktop" then.

Regards,
Stephan

For X at least, the X session might be running on a different host so
requiring a x-session package to be installed locally is not helpful.

Cheers,

Well, a more generic option would be "Wayland graphical session", though
it's a bit of a tautology :)

Would "Graphical session using the Wayland display protocol" be too
long?

Kind regards,
Andrei

Hello Simon,

Some time has passed without objections so I would be happy to add these
two virtual packages.  My only concern is that there are going to be
quite a few virtual packages in this area, now, and the virtual packages
list will contain only terse descriptions of each one.  Someone
packaging a new session/display manager/WM might have a hard time
figuring out what to use, unless they happen to stumble across the
discussion in this bug.

What do you think about adding a condensed version of your reasoning to
the Policy Manual somewhere?

I'm slightly regretting opening this can of worms now, but here's my
best attempt at Policy wording.

§(Packages providing an X session manager) might be incomplete: it's not
clear to me whether there are any particular requirements for an
x-session-manager (does it have to implement XSMP?) or whether it's as
vague as "anything that is a larger X11 session than an x-window-manager".

    smcv

Hi,
thanks for the effort to get this started. The proposed patch reads very
well to me. Since we have at least 7 wayland compositors in the archive
now it is IMO high time have wayland-session so users can discover
window managers easier. While X will be probably be around for quite
some time, it is effectively not getting any development upstream.

I fully support this proposal, are there any strong objections to get
this merged ?

best,

werdahias

Hello,

There are a few unanswered questions from me in the thread, and you'd
want to second the proposal.

You said "Just to confirm, the primary use case [of wayland-session] is
so that if a package providing wayland-session is installed, a display
manager like gdm3 won't try to install GNOME?". I didn't explicitly
answer that, but the answer is: yes, ish.

gdm3 currently Depends on gnome-session | x-session-manager |
x-window-manager | x-terminal-emulator and Recommends gnome-session |
x-session-manager, which you could read as "Depends on something that it
can log into; Recommends a somewhat full DE that it can log into".
However, users of non-GNOME Wayland environments might reasonably want
to use gdm3 to log in to some non-GNOME Wayland-native session like
weston or sway, which is not the GNOME session, but is also not an X11
environment and therefore cannot correctly implement x-session-manager.
gdm3 does allow this, but its dependencies do not.

Installing gdm3 but not gnome-session is not actually amazingly useful,
because the gdm3 "greeter" (login prompt) is just
gnome-session/gnome-shell in a special mode, so installing gdm3 pulls in
90% of a minimal GNOME session already, and the additional cost of
installing the rest of gnome-session is small; but a standalone, minimal
Wayland login manager like greetd would presumably prefer to depend on
wayland-session, after it exists.

A secondary use-case (as werdahias mentioned) is discoverability:
`apt-cache search wayland-session` is easier than `apt-file search
/usr/share/wayland-sessions`.

As a follow-up I also proposed adding x-session, because I realised that
gdm3 Recommends x-session-manager is not really right. It would be
correct for a login manager in group (1.) as defined in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004522#30, like xdm,
but is wrong for gdm3. gdm3 is in group (2.) as defined in that message,
and really wants either /usr/share/wayland-sessions or
/usr/share/xsessions, but AIUI there is no guarantee that an
x-session-manager actually provides /usr/share/xsessions/*.desktop (and
I did find a counterexample). Instead, it should depend on gnome-session
| wayland-session | x-session.

You said "My only concern is that there are going to be
quite a few virtual packages in this area ... What do you think about
adding a condensed version of your reasoning to the Policy Manual
somewhere?" and I responded by proposing a patch that I intended to be
an implementation of that, which I hope is reasonably self-contained and
self-explanatory (reviews/improvements welcome of course). In general I
agree that it's a good idea for virtual packages to have somewhere (not
necessarily Policy, maybe a relevant team's mini-policy) describing what
it means to implement the virtual package, particularly if it interacts
with the alternatives mechanism, so that while following up on bug
reports we can assess whether an implementation of the virtual package
actually meets the specification or not.

A secondary reason to describe the wayland-session and x-session
interfaces in Policy is that there is currently nothing in Debian
telling desktop session implementors "you should write a .desktop file
in /usr/share/wayland-sessions or /usr/share/xsessions, because that's
the de facto standard for how modern display managers decide what
choices they should offer to the user", and that seems like an important
omission!

Bonus content, answering questions you didn't ask:

There have been suggestions elsewhere that gdm3 should just drop its
Depends on x-session-manager etc., because it isn't a login manager's
job to install something that you can log into. I have been reluctant to
do that because gdm has had some version of that dependency since 2004
(at which point it was still gdm 2), and if we removed the dependency, I
find it depressingly easy to imagine a contributor using RC bugs of the
form "gdm3 is unusable due to missing dependency on something to log
into" as a stick to beat the GNOME team with. However, if there is
project consensus that this would be a non-bug (which we could point to
when closing those bugs as not-a-bug) then we could do that.

Stephan Lachnit suggested naming the virtual package
wayland-desktop-session instead. Others explained why wayland-session
would be a better name, in messages to the bug. I also mentioned why not
wayland-compositor or wayland-session-manager.

Known issues that I do not know how to resolve:

§(Packages providing an X session manager) might be incomplete: it's not
clear to me whether there are any particular requirements for an
x-session-manager (does it have to implement XSMP?) or whether it's as
vague as "anything that is a larger X11 session than an
x-window-manager". I don't think this needs to be a blocker: the
specification I proposed is better than what we have now, which is a
single sentence.

Were there other questions or objections?

     smcv

Hi,

consider this proposal tenatively seconded from me.


best,

werdahias

Hello,

I think this message covers everything, thanks, but please give me some
time to go through it carefully.

Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.