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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making d-i Not Suck
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. > So take a different approach to handle it. > > (*) 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. > Geert Stappers -- Alastair McKinstry <[EMAIL PROTECTED]> GPG Key fingerprint = 9E64 E714 8E08 81F9 F3DC 1020 FA8E 3790 9051 38F4 He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself. - --Thomas Paine signature.asc Description: This is a digitally signed message part
Re: Making d-i Not Suck
> > 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. 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. So take a different approach to handle it. Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]