steamdeps knows how to use Debian's x-terminal-emulator interface, so we can probably just put a | x-terminal-emulator on the end of the list of terminals.

If you're taking steps to work around this in order to avoid installing xterm, then that might be a factor that's contributing to #9350 happening.

Steam is quite large and the games that you can install via Steam are larger still, so going to significant lengths to avoid installing xterm is probably not worth your time. To put this in perspective, xterm and all of its non-Essential dependencies seem to be approximately 16M, which is worth around 0.1% of a copy of The Witcher 3 (approximately 16G).

steamdeps knows how to use Debian's x-terminal-emulator interface, so we can probably just put a | x-terminal-emulator on the end of the list of terminals.

If you're taking steps to work around this in order to avoid installing xterm, then that might be a factor that's contributing to #9350 happening.

Yes, I found that issue avoiding xterm installing. I just don't wanna see xterm on my apps list because I don't even use Xorg

steamdeps knows how to use Debian's x-terminal-emulator interface, so we can probably just put a | x-terminal-emulator on the end of the list of terminals.

Actually, maybe not. The steam-launcher package itself does not specifically ask for xterm or gnome-terminal, but Steam tells steamdeps that it needs xterm | gnome-terminal (via ~/.steam/root/steamdeps.txt), which is why steamdeps tries to make sure that one of those is installed.

@TTimo, do you know of a reason why Steam requires one of those two terminals specifically?

steamdeps could override this with logic like "when Steam says xterm | gnome-terminal, it really means xterm | gnome-terminal | x-terminal-emulator" if that's valid to do, but if something in Steam genuinely needs either xterm or gnome-terminal then steamdeps shouldn't be second-guessing that.

According to a quick grep through the Steam beta: steam-runtime-launch-options specifically wants xterm (which seems OK without a dependency since it's a debugging tool for advanced users who can figure out that sort of thing), while bin_steam.sh, steam.sh and steam_msg.sh all use xterm (unconditionally, with no fallback) if zenity is broken.

@TTimo, do you know of a reason why Steam requires one of those two terminals specifically?

I do not. I see no sign in the Steam binaries that we may be trying to spawn a process by either the name xterm or gnome-terminal. Iirc we normally offload that responsibility to scripts outsite of steam binaries.

Sounds to me x-terminal-emulator would be fine, but afaik it's a thing that only exists on Debian, and there's no conventional way to consitently abstract "I need a terminal" across distributions?

Sounds to me x-terminal-emulator would be fine, but afaik it's a thing that only exists on Debian, and there's no conventional way to consitently abstract "I need a terminal" across distributions?

Correct, although it's really "all Debian derivatives" (Debian, Ubuntu, others) rather than specifically Debian. There have been some recent attempts at standardizing an abstraction for "run this argv[] in the user's preferred terminal" (xdg-terminal-exec looks the most promising, IMO) but at the moment there is nothing suitable.

bin_steamdeps.py currently tries to run GNOME's gnome-terminal, KDE's Konsole, the traditional xterm, or Debian's x-terminal-emulator, in that order - so from that point of view, we already support x-terminal-emulator. We can add more terminal emulators there, within reason, and it's relatively harmless to add more if they don't exist.

debian/control is only used by Debian derivatives, and all Debian derivatives inherit the x-terminal-emulator API from Debian. So given this:

I see no sign in the Steam binaries that we may be trying to spawn a process by either the name xterm or gnome-terminal

I think we can safely resolve this issue by adding | x-terminal-emulator to the dependencies in debian/control. The practical impact will be that if a user like @sarisan has installed an x-terminal-emulator that is not one of the ones we specifically look for, we'll harmlessly fall through the list of specific terminals gnome-terminal → ... → xterm without finding them; then find x-terminal-emulator, run that, and stop.

If there was a good interface for "run this argv[] in the user's preferred terminal", then it would be subtly better than Debian's x-terminal-emulator, which means "run this argv[] in the sysadmin's preferred terminal" (not necessarily the same on a multi-user system, or a system with multiple desktop environments installed). I'm hoping that either xdg-terminal-exec or one of the various competing proposals will become a freedesktop.org recommendation at some point.

On non-Debian-derived systems like Arch or Fedora, looking for x-terminal-emulator is harmless: it will not usually help, but it will not make things any worse either, so it's worth trying whenever we're iterating through a list of terminals. A user of a non-Debian-derived system might even have made a symlink like ~/.local/bin/x-terminal-emulator -> rxvt if they happen to know about the Debian-specific interface, and that would make this work the way we intend.

Also, our implementation of bin_steamdeps.py is completely Debian(-and-derivatives)-specific anyway, so it's fine to use Debian-specific interfaces in there.

Unfortunately, after some more investigation, x-terminal-emulator does not necessarily do what we need here.

The behaviour we need for steam-launcher is that we can run a terminal emulator containing a command, and wait for it to finish. However, if you're already running some terminal emulators (including at least MATE Terminal and gnome-console), the terminal emulator command exits immediately, leaving the specified command running in the background. This means Steam will try to start, and usually fail, while its dependencies are being installed in the background.

The x-terminal-emulator interface does not specify whether the terminal emulator should wait or not, and also does not specify a way to force the terminal emulator to wait.

For GNOME Terminal, we know how to use a modern --wait option and an older disable-factory option, both of which are specific to GNOME Terminal. Similarly, for KDE's Konsole we can use --nofork, and we know that xterm always waits; but x-terminal-emulator has no such guarantee.

gnome-console (kgx) does have a --wait option, but it's unimplemented and doesn't have any effect (which to me seems worse than not having the option).

This is a pre-existing bug, but it's masked by the fact that either gnome-terminal or xterm is usually installed, and if we try harder to avoid needing to install one of those, then we make the bug more likely to appear. So in the short term, I'm afraid this is probably going to have to stay as "won't fix".

I just don't wanna see xterm on my apps list

You can exclude individual apps from your desktop environment's menus by copying its .desktop file from /usr/share/applications to ~/.local/share/applications, and adding NoDisplay=true to the [Desktop Entry] group.

Unfortunately, after some more investigation, x-terminal-emulator does not necessarily do what we need here.

xdg-terminal-exec can't guarantee to do what we need either.