XPost: linux.debian.policy
On Sun, 03 Aug 2025 at 13:52:29 +0100, Sean Whitton wrote:
There are a few unanswered questions from me in the thread
Please could you remind me what they were? It's been a while!
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)