Bug#473478: strict dependency on xterm only
Josip Rodin
Version: 3.19.1-4
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.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
tony mancill
Hash: SHA1
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:
> Package: clusterssh
> Version: 3.19.1-4
>
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH8CGIpdwBkPlyvgMRAh9AAJ9L/MkgC2eHO/ObqhDlp49Yp1PRJACeIojd
R8cwn5th1SFTWXE6h1R7BCQ=
=3Sci
-----END PGP SIGNATURE-----
Josip Rodin
On Sun, 30 Mar 2008 16:26:00 -0700, tony mancill wrote:
> 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.
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.
tony mancill
> Hi,
>
> On Sun, 30 Mar 2008 16:26:00 -0700, tony mancill wrote:
>> 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.
>
> 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.
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
Josip Rodin
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.
--
2. That which causes joy or happiness.
--
tony mancill
Hash: SHA1
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAktGTT0ACgkQpdwBkPlyvgM6DQCdF9+o0eKx49z1iGFkpfd5d3k2
RKEAn0xS66CF+Jjl74FLEWoGsMp4T/Yr
=QW42
-----END PGP SIGNATURE-----
Josip Rodin
> This clearly changes how the upstream clusterssh works.
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.
> 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.
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.
--
2. That which causes joy or happiness.
--