Hi,

README.Debian clearly states that xterm is not the only x-terminal-emulator
which is tested and believed to work - why is it necessary to force the
installation of the xterm package on users of those other six programs,
particularly rxvt which has no noted caveats?

Please use the piped dependency as appropriate. TIA.

Hi Josip,

In the case of clusterssh, it's inappropriate to have it simply launch
/usr/bin/x-terminal-emulator because clusterssh has no way of knowing
whether /usr/bin/x-terminal-emulator points to a terminal emulator that
supports the VT100.allowSendEvents property.  A piped dependency may ensure
that a terminal emulator exists that works with clusterssh, but doesn't
guarantee that the alternatives system has selected it.

I'll consider this, but there's something to be said for a package that
works out of the box without the user having to edit .csshrc or modify
alternatives.  rxvt is smaller and has fewer dependencies, so it may be a
better default choice.

Thanks,
Tony

Josip Rodin wrote:

Hi,

I never got your original message because the submitters get mail only when
you send it to them, either directly or via nnn-submitter@bugs alias. Just a
reminder :)

The code currently does:

    $config{terminal}           = "xterm";
    $config{terminal} = find_binary( $config{terminal} );

Since an auxiliary function find_binary() is used already, it could easily
be amended to figure things out. For example, the default value could be a
special string such as !terminalwithevents!, and a simple handler inside
the function would intercept that and check for xterm and rxvt in order.
If it finds neither, it can proceed to fail just as it does now.

Josip Rodin wrote:

Sure, it's not a question of whether it's difficult to code, only one of it
whether there's any point in coding up a patch that isn't likely to be accepted
upstream.  find_binary() only tries various path prefixes and is used for for
more than just the terminal.  The work-around is quite simple, you only have to
edit .csshrc with your preference of terminal.

In your proposed solution, the code would always select xterm and then rxvt if
both were installed, which may just result in another bug report requesting that
 the order be reversed (or that other terminals be added to the list, again with
ordering issues).  It just seems arbitrary when users who have a preference of
terminal emulator can easily configure clusterssh to suit their needs, and it
works as packaged for people who don't have a preference, using the same
terminal emulator configured by default by the upstream author.

I'm changing the severity of this to minor (it's arguably wishlist), and will
discuss with the Upstream author once he releases the 4.00 rewrite (should be in
the next few weeks).

Thank you,
Tony

Yes, I can configure it and work around the exact functional issue, but that
still doesn't make it right for the cssh package to force me to have xterm
installed even if I don't need it. That's not an upstream issue, it's ours.

Josip Rodin wrote:

I disagree.  Upstream explicitly uses the command 'xterm' to invoke a terminal
emulator and allows the user to override this in the configuration.  Debian's
x-terminal-emulator is not a suitable replacement for reasons already discussed
in this bug report, therefore the dependency on is xterm.  Your claim is that
you shouldn't have to install the xterm package to use clusterssh because it
works with other terminals, and that the functionality of clusterssh should be
extended to support automatically searching through an arbitrary list of
terminal emulators.  This clearly changes how the upstream clusterssh works.

In any event, what is the issue with having to install xterm?  Do you think the
dependency should be on rxvt (and the clusterssh source patched as part of
packaging to invoke that instead)?  This seems arbitrary and capricious, other
users may find mrxvt or wterm or some other terminal more suitable and disagree
with the fact that either xterm or rxvt has to be loaded on their systems.  I
see no reason to address this in code so long as the xterm package is available
and functioning on all architectures.

Technically yes, but it doesn't *conflict* with the upstream defaults, it
just adjusts them to automatically suit more users than what upstream had
intended. That's supposed to be a good thing.

I don't have anything particular against xterm, and indeed I never suggested
to demote it, I said explicitly it should continue to be tried first.
I just want more of an equal opportunity status for rxvt, and we shouldn't
force users to have excess packages installed as a matter of principle,
even if we're talking about relatively insignificant things like xterm.

You may be able to handle this by doing:

Depends: x-terminal-emulator
Recommends: xterm

This way in the normal case xterm will be installed, but someone
(i.e. a more advanced user) can uninstall it if they wish, but in
any case a terminal emulator will be available.

 	-Ariel

Hi Ariel,

The problem is that not all packages that provide x-terminal-emulator
will work with clusterssh, and we definitely don't want to install the
package and have it be broken.  There are details and discussion of this
already in the bug report.  More advanced users can always configure up
the terminal they want, and I just don't buy the argument that having to
install the xterm package on a modern system is some kind of burden.  As
is in the bug report, rxvt is smaller, but then the choice is arbitrary,
and I don't get the impression that clusterssh is commonly installed on
embedded systems.

The best solution (at least for this type of issue) would be if all
packages that provide x-terminal-emulator also supported, by Debian
policy, the allowSendEvents property.  However, they may be valid
arguments for why a terminal doesn't want/need to implement this.

Cheers,
tony