[ On Wednesday, April 2, 2003 at 08:04:18 (+0200), Matthias Scheler wrote: ]
> Subject: Re: ncurses on broken on Solaris (Re: pkg/20881)
>
> On Wed, Apr 02, 2003 at 12:01:46AM +0200, Klaus Heinz wrote:
> > > Do you know why the screen entry was removed ?
> > 
> > No. Further digging in the CVS log reveals, that Matthias Scheler
> > committed this workaround last year. Maybe he can remember why he did it
> > this way.
> 
> Because it conflicted with the "screen" package.

The "screen" package must not install any terminfo or termcap entries on
the host where the package is installed!

Terminal emulation is sort of like the very first kind of client/server
systems -- i.e. you have to think about who's providing the service and
who's making use of it.  Screen just splits this relationship into a
pair of mirrored relationships, but it also allows the mirror to be bent.

I.e. one does not necessarily use the "screen" terminal type on the host
system, but rather only on the targets you login to with your individual
screen sessions (which may be the local host, or may not be).  It's like
cross-compiling the OS on the same system you'll be installing the
resulting product files on....

Since "ncurses" provides the emulation drivers for applications on the
target hosts that screen users login to, "ncurses" _must_ be responsible
for installing the "screen" terminfo entries, if there are to be such
things.

Certainly there must not ever be any difference in the deciding policy
of which pkgsrc package owns the "screen" terminfo files between
different pkgsrc platforms!!!  The current situation with a difference
between SunOS and other pkgsrc platforms is very broken!

Of course the whole idea of a "screen" terminal type is fundamentally
flawed right from the get-go and can only ever lead to confusion like
what we see in pkgsrc today.

From the target host's perspective the terminal type _must_ be one that
applications on those target systems can drive so that they may continue
to believe they are driving the same "normal" terminals they would
expect to be normally connected to their hosts.  Traditionally screen
has taken the standards based approach and has implemented one standard
ANSI terminal emulation which it presents to the target hosts.  This
works well enough for screen because the applications on most/all target
hosts know how to drive standard ANSI-compatible terminals.

However if screen's terminal emulation is diverging from the standard
ANSI X3.64 (ECMA-48) for terminals to the extent that it works better
with its own terminal type definition for most target platform curses
libraries then someone needs to clue-by-4 screen's current maintainers.

Either way screen's maintainers are only making the situation much worse
by providing a differently named terminfo/termcap entry for use on
target hosts.  If they simply called their entry "ansi" and only
suggested it be installed when the target system didn't have a (working)
"ansi" entry then I couldn't and wouldn't complain.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>