Bug#1136306: debian-policy: Proposing new wayland-terminal-emulator alternative and virtual package

On Sun, 14 Jun 2026 at 10:30:45 +0200, Matthias Geiger wrote:
>+# Wayland
>+ - name: wayland-terminal-emulator
>+   description: a wayland client which emulates a terminal with a 
>terminfo description

What's the intended purpose of this virtual package? Which packages are 
expected to interact with it?

If providing the virtual package requires implementing a specific 
alternative (via dpkg's update-alternatives), then I think the entry in 
Policy's list should say so. But I'm already not a fan of the use of 
alternatives for x-terminal-emulator, because I think it's a bad fit for 
what desktop environment users expect.

The alternatives mechanism is great for choices that are necessarily 
one-per-machine and must be chosen system-wide, like the display manager 
(graphical login prompt) or other system services, and it can make a 
good fallback for the last-resort implementation of some app, but it has 
some quite serious limitations as a primary way to select user-facing 
apps. If George and Kay install a shared computer with both GNOME and 
KDE, George uses GNOME and Kay uses KDE, and neither user has configured 
a personal preference, then it's a reasonable expectation that George's 
default terminal emulator should be the one that GNOME recommends 
(currently ptyxis) and Kay's should be the one that KDE recommends 
(currently konsole). Neither terminal is better than the other in the 
abstract, but ptyxis is a better fit for GNOME, and Konsole is a better 
fit for KDE. But if their applications start x-terminal-emulator, then 
there's no way to represent that expectation, and at most one of our two 
users can get what they want.

Worse, only the sysadmin can configure what an alternative means (and, 
again, when they do, it is system-global); the best the users can do 
without privileges is to create a directory like ~/.local/bin, add it to 
their PATHs (not done by default!), and create a symlink 
~/.local/bin/x-terminal-emulator -> /usr/bin/ptyxis or similar, which is 
not particularly discoverable, and not something that a settings UI can 
reasonably be expected to do for them, especially if that settings UI is 
not designed to be Debian-specific.

I think a better model for applications that want to start "some 
suitable terminal emulator" is xdg-terminal-exec, which implements a 
proposed freedesktop.org spec modelled on fdo MIME-type and URI-scheme 
handlers, with a system-wide fallback, a per-desktop-environment 
preference and a per-user configuration override. Or, this 
terminal-specific proposal might be replaced at some point by an 
interface name for the more general "intent apps" spec proposal, 
<https://specifications.freedesktop.org/intent-apps/latest/>, which is 
syntactically different but the same general shape.

A limitation of these .desktop-based specifications is that they don't 
currently accommodate terminal emulators that *only* implement Wayland: 
they assume that GUI apps are GUI apps, and will work in any reasonable 
environment, perhaps via switchable backends (like in GTK, Qt, SDL) or 
perhaps by using X11 via Xwayland as a lowest-common-denominator GUI 
protocol (like xterm). The same is true for fdo MIME-type handlers, fdo 
URI-scheme handlers, and the .desktop specification in general. If you 
consider Wayland-only, non-X11-compatible apps to be an important 
use-case, then the way to accommodate them would be to extend 
https://specifications.freedesktop.org/desktop-entry/latest/recognized-keys.html 
with new keys similar to OnlyShowIn/NotShowIn, but based on 
$XDG_SESSION_TYPE (x11/wayland) instead of $XDG_CURRENT_DESKTOP 
(GNOME/KDE/etc.).

Does your proposed design mean that anything that starts a terminal via 
a wayland-terminal-emulator alternative (which could include non-GUI 
libraries like GLib!) is expected to be able to detect whether the 
session is Wayland or not, and use wayland-terminal-emulator 
alternatives as a candidate for starting a terminal if and only if the 
session is Wayland? At the moment GLib only has a list of terminals (to 
which we apply a Debian-specific patch to include x-terminal-emulator), 
and assumes that they will all work in any "reasonable" desktop 
environment, similar to how .desktop files work - which in practice is 
true because all the terminals on its list either use GTK/Qt to support 
any desktop environment, or are X11-only (like xterm) and will operate 
via Xwayland on Wayland desktops.

And how does this work for terminals that don't/can't know whether they 
implement native Wayland? GTK 3+ applications can typically be both a 
Wayland client and an X11 client, using whichever protocol is more 
appropriate at runtime, and I know there are also Wayland-only terminal 
emulators like foot and X11-only terminal emulators like xterm. But if I 
understand the Qt ecosystem correctly, a Qt-based application like 
Konsole might or might not be able to implement native Wayland, 
depending on whether the plugins in the qt6-wayland package are 
installed, with no code changes to the application itself - so is 
konsole a wayland-terminal-emulator or not?

     smcv