Re: Making d-i Not Suck
On Sun, Mar 30, 2003 at 06:50:11PM +0100, Alastair McKinstry wrote:
> On Fri, 2003-03-28 at 12:52, Geert Stappers wrote:
> > >
> > > Similarly a possible terminfo-udeb, for remote installs; we currently
> > > build a subset (ansi,vt100, ..) of terminfo data on the rootskel;
> > > suboptimal if you are remote-installing on a different terminal. Imagine
> > > a terminfo-udeb; if [something] spots TERM that is not supported, it
> > > should request a terminfo-udeb, and automatically fix it.
> > >
> >
> > Supporting other "terminals" then ansi and vt100 can indeed be done in d-i.
> > However IMHO it doesn't make sense.
> > Most terminalprogramms can easy be configured to emulate an other terminal.
> > Or when not, then take another terminal programm at the non d-i side.
> >
>
> Yes, it can, but I gave it as an example; its cosmetic. (A better
> example of a real use was given, pulling in the right console fonts).
>
> If someone is installing debian remotely from an eg DECterm, they
> shouldnt have to change TERM=vt100, or whatever. For the most part, how
> it would work, would be eg in the S390 case (*) (see other thread; on
> S390 there is no local console; you boot and then login via telnet).
> The user logs in via telnet, which passes the TERM value.
> if the TERM!={ansi,vt100,linux}, then terminfo-udeb is loaded, and the
> terminfo data installed, and installation continues more beautifully.
>
> > Formatting screen output with terminfo data
> > is an other kind of problem then a floppy disk image that has to provide
> > an driver for the next driver such as harddisk driver or NIC driver.
> >
> I can't parse this; do you mean its different than the driver loading
> problems; if so, yes, I agree; they are critical, this is cosmetic.
Yes, my worries are about critical items like driver loading.
These issues _must_ be solved at install target side.
Choosing a terminal screen protocol that both side understand,
is an issue that _can_ be solved at install target side.
I agree that missing functionality ( disk driver or screen formatting )
can be loaded in an universal way.
>
> > So take a different approach to handle it.
Not so smart.
So give different priorities to handle them.
> >
> >
>
> (*) Actually, it may be useful in other cases too. See the netconsole
> project, that aims to provide an ethernet console (simple TCP/IP stack &
> telnet login) or, I believe the Axis Communications Linux SoCs, which
> provide an ethernet (telnet) login. In these cases, the telnet protocol
> would be used for remote installation, rather than a serial console; and
> so telnetd would be useful, and the terminfo issue would occur.
>
Yes, telnetd has benefits. I hope it stays in d-i
Geert Stappers
Reply to: