Dear Maintainer, I was looking for an update-alternatives group for a simple terminal, but only found x-terminal-emulator. That reference to "x" seems now outdated. This is why I wondered if any of these updates would seem useful to you: * Add a wayland-terminal-emulator counterpart, so people could benefit the two different terminals * Or, mix both x and wayland terminal emulators in a single group named "terminal-emulator" * And possibly shorten the group name to "term"? Thanks for considering these ideas please :-) Warm wishes, Thibi
Hi! dpkg only provides the mechanism, it does not implement nor defines alternatives for other packages. I initially thought this had already been filed in Debian Policy, but I only see a request for wayland-session (#1004522). I think it makes sense to have both a virtual package and an alternative for wayland-terminal-emulator, as using x-terminal-emulator for wayland ones seems wrong to me. Thanks, Guillem
Hi, I tend to agree. As I also mentioned in #1004522 this would greatly improve discoverability of "wayland-ready" terminal emulators. best, werdahias
While there are terminals that work both on x11 and wayland, I think
this makes sense nonetheless.
This is my inital patch:
diff --git a/virtual-package-names-list.yaml b/virtual-package-names-list.yaml
index 9e0089e..0e6cb84 100644
--- a/virtual-package-names-list.yaml
+++ b/virtual-package-names-list.yaml
@@ -223,6 +223,10 @@ virtualPackages:
- name: xserver
description: an X server that (directly or indirectly) manages physical input and display hardware
+# Wayland
+ - name: wayland-terminal-emulator
+ description: a wayland client which emulates a terminal with a terminfo description in the ncurses-term package
+
# Fonts
- name: fonts-japanese-gothic
best,
werdahias
Matthias Geiger [11/Jun 3:37pm +02] wrote: LGTM, though let's check with the ncurses-term maintainers that this makes sent to them too. Ncurses maintainers, could you review this addition to the list of virtual package names, please?
On Fri, Jun 12, 2026 at 12:00:54PM +0100, Sean Whitton wrote: ... ... It's not relevant to ncurses-term, because none of the terminals have adopted any feature which makes displaying in wayland differ from X11.
Hi,
Thanks Sean for letting me chime in.
The part that the terminfo description needs to be in the ncurses-term
package does not really make sense to me. While it is certainly
encouraged to get the terminal description included in ncurses'
terminfo.src file, it is also possible to ship it separately. For
instance the kitty package does that, because the developers made the
mistake to name their terminfo entry xterm-kitty, a name that is not
acceptable for ncurses upstream.
I should also note that policy is inconsistent regarding the
x-terminal-emulator alternative. While virtual-package-names-list.yaml
states that the terminfo description should be in the ncurses-base
package, this requirement is not mentioned in
policy/ch-customized-programs.rst, and at least kitty does not meet this
condition. Should I file a separate bug about this inconsistency?
Cheers,
Sven
Hi Sven,
thanks for chiming in. tbh I just copied the x-terminal-emulator one and
adjusted it. What do you think about this update?
diff --git a/virtual-package-names-list.yaml
b/virtual-package-names-list.yaml
index 9e0089e..0e6cb84 100644
--- a/virtual-package-names-list.yaml
+++ b/virtual-package-names-list.yaml
@@ -223,6 +223,10 @@ virtualPackages:
- name: xserver
description: an X server that (directly or indirectly) manages physical input and display hardware
+# Wayland
+ - name: wayland-terminal-emulator
+ description: a wayland client which emulates a terminal with a
terminfo description
+
# Fonts
- name: fonts-japanese-gothic
best,
werdahias
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
What about sensible-terminal ? Cheers, Bill.
That's closer (it at least has a mechanism for per-desktop defaults),
but has the disadvantage of being Debian-specific, and its per-user
configuration is by creating new tool-specific environment variables.
A non-Debian-specific settings UI like gnome-control-center or KDE's
systemsettings isn't going to be able to configure this in the expected
way for several reasons:
- there isn't a particularly good universal way to set environment
variables for the session: environment.d(5) is the closest, but is
systemd-specific as far as I know
- because of how environment variable inheritance works, changing an
environment variable in environment.d(5) won't take effect until the
user logs out and back in (and perhaps not even then, if session
lingering is enabled)
- the non-Debian-specific settings UIs typically won't want to include
code for a Debian-specific setting, and desktop teams with limited
resources would prefer not to patch new logic into a fork of those UIs
I still think xdg-terminal-exec is the closest thing we have to a good
way to choose an appropriate terminal.
Coming back to the topic of wayland-terminal-emulator, sensible-terminal
has the same limitation as xdg-terminal-exec that it assumes all
terminals are capable of running in any desktop session (Wayland or
X11), which is true for typical X11/Wayland terminals like ptyxis and
konsole, and also true for X11-only terminals like xterm, but not true
for Wayland-only terminals like foot.
smcv
Right, I (naively) assumed this is the same case as wayland-session Right, I agree this warrants further discussion. As Bill described, I agree to have a generic *terminal package, as I believe x-terminal-emulator is not timely anymore in the age of pure wayland-only terminal emulators like foot. best, werdahias
wayland-session isn't a standardized virtual package at the moment. I
proposed it in <https://bugs.debian.org/1004522> a few years ago, along
with x-session, but it was never integrated into Policy. The latest
version of that proposal at the time of writing is
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004522#66>.
The meaning for wayland-session that I proposed in #1004522
intentionally didn't include an update-alternatives(1) registration, and
instead is defined in terms of /usr/share/wayland-sessions/*.desktop,
which is what typical Wayland-capable display managers like gdm and sddm
want to see.
The closest equivalent for a wayland-terminal-emulator would be a
terminal emulator whose .desktop file has Categories that include
System;TerminalEmulator;, and the various keys used by the proposed spec
implemented in xdg-terminal-exec (as a minimum, X-TerminalArgExec or
X-ExecArg).
If that proposed spec gets replaced by a use of Intent Apps, then I'd
expect the requirement to change to something involving a specific item
in the Interfaces list (probably Interfaces=org.freedesktop.Terminal1;
or something similar), which is the "modern" way to declare that an app
implements a specific programmatic interface (often but not necessarily
D-Bus-based, it can equally well be a command-line option convention
like the one involving X-TerminalArgExec). If this gets standardized, it
should preferably be standardized by a cross-distro group like
freedesktop.org, not by Debian, so that there is no barrier to adoption
by upstream projects and other distros that might not consider a
Debian-specific interface.
smcv
Sven Joachim [13/Jun 8:09am +02] wrote: Yes, ideally with a patch to policy/ch-customized-programs.rst :)