Re: the usage of nano-tiny, and a patch for 3.2

[Jordi Mallach]

Hey Benno!

El dv. 24 de 01 de 2020 a les 13:40 +0100, en/na Benno Schulenberg va
escriure:
> Hello Jordi,
> 
> More than three years ago I included the word-jumping routines
> (normally: Ctrl+Left/Ctrl+Right) also into the tiny version. [1]
> But soon afterward I noticed that the Ctrl+Left/Right keystrokes
> don't actually work when nano is built with Slang (--with-slang),
> due to some bug in Slang. [2]
> 
> A few weeks ago, I found a different bug that occurs when nano is
> built with Slang: the cursor is absent when nano is suspended. [3]
> It was introduced with version 2.9.0, and no one noticed so far.

Oh dear.

> This made me wonder: how is the tiny nano used in Debian?  Is the
> user free to start it in any way she likes?  Or is nano always
> started from within another program (the installer)?  Without any
> command-line options?  The latter would explain why nobody reported
> the absence of the cursor when nano is suspended, because it will
> not be possible to suspend such a nano.  Or... maybe no one ever
> suspends the tiny nano?  If that is the case, then we might exclude
> suspension from the tiny version and make it still a little smaller.

OK, so there's two scenarios here:

1) nano-udeb, aka nano for the really tight and limited debian-
installer environment: it provides the only editor in the d-i shell, so
it's pretty important there. The reason it's compiled against slang is
that there is no libncurses-udeb in debian-installer, and for this to
exist, d-i should be ported to ncurses as well. This is something I've
been wanting to do for like 4 years, but time has been scarce due to
parenting and so on (however, I'm sloooowly catching up lately!).

2) nano-tiny is a convenience package with a trimmed down version of
nano that can be useful in embedded projects or for rescue operations.
However, it was introduced so many years ago that I doubt it is really
useful these days. We could probably switch this one to ncurses without
breaking people's setups. I have done this for 4.7. Sorry about the
lack of updates, btw.

> Anyway, this bug is fixed in git and you may want to apply the
> attached patch to version 3.2 in Debian stable.

I'm trying to decide if this is worth it. The patch is mininal and
would be accepted by the release team for sure, so as it impacts d-i,
maybe it is worth it.

> You may also wish to apply it to 4.5 in testing, or better: to 4.7.
> Or you could wait until 4.8 comes out, in about two weeks.

I'll just wait. It only affects d-i now. :)

> Yesterday I found another bug that occurs when a nano built with
> Slang
> has returned from suspension: ^C no longer works. [4]  This seems to
> be a bug in Slang and thus unfixable.  It has been visible in nano
> since version 2.2.0 from ten years ago.  This made me wonder: does
> it really make sense to support Slang when it has so many bugs?

Not really, in fact I assume you keep Slang support because us. I'll
try to get cdebconf to use ncurses. We need to package ncurses as udebs
and so on, it's not trivial, but can be done, and cdebconf needs to be
tested thoroughly to see that everything works like it did. It's been
many years and installs using floppies or on devices with so little ram
than a few extra kbs loaded into memory are a problem should not be
supported anymore by the kernel anyway.

> To see how much a Debian install depends on Slang, I downloaded a
> net install image:
> 
>   wget
> https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
>   sudo mount -t iso9660 ./debian-testing-amd64-netinst.iso /OTHER
>   zcat /OTHER/install.amd/initrd.gz  |  cpio -i
> 
> Then I ran:
> 
>   ldd {usr/,}{s,}bin/* | grep -A4 -B2 slang
> 
> bin/nano:
>       linux-vdso.so.1 (0x00007ffd6dd79000)
>       libslang.so.2 => /lib/x86_64-linux-gnu/libslang.so.2
> (0x00007fa098118000)
>       libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> (0x00007fa097d27000)
>       libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> (0x00007fa097b23000)
>       libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
> (0x00007fa097785000)
>       /lib64/ld-linux-x86-64.so.2 (0x00007fa0985fa000)
> 
> The only binary that is linked against Slang is nano!  Surely there
> must be
> other stuff on that file system that links against Slang, but where
> is it?

:)

>   grep -r libslang * | grep Binary | grep -v slang
> 
> Binary file bin/nano matches
> Binary file usr/lib/libnewt.so.0.52.21 matches
> Binary file usr/lib/cdebconf/frontend/newt.so matches
> 
> Okay.  However, I cannot figure out how this newt stuff gets used by
> the
> installer.  I'm guessing that .../frontend/newt.so itself gets
> executed.

Indeed, it's the Debconf frontend (the blue screens Debian presents
every now and then when configuring or preconfiguring packages).

Debconf supports a number of frontends, and cdebconf is a special,
lightweight, possibly incomplete implementation of the debconf spec for
use in d-i. For the same reasons as nano-udeb, it links against Slang,
and this is what needs to be changed as described above.

So yeah, the newt.so frontend is basically the way d-i presents
*everything* during the install: menus, progress bars, etc.

> Anyway, I looked at the size of libslang.  It's 1350K!
> 
> I've also downloaded the .deb files for a full nano, libncursesw, and
> libtinfo.  After unpacking those files, I can run the contained nano:
> 
>   LD_LIBRARY_PATH=./lib/x86_64-linux-gnu/ bin/nano
> 
> So all that nano needs to run is libncursesw and libtinfo.  The first
> is
> 230K and the latter 184K in size.  However, libtinfo is already
> present
> on the initrd (it is used by usr/bin/screen), so to get a nano that
> is
> free from the bugs of Slang, all it needs is the 230K of libncursesw.
> And possibly just libncurses (without UTF-8 support) is enough, which
> would be just 160K.  Seeing that the initrd contains 2.5 MB for
> brltty,
> surely a mere 160K can be added to get a fully functional nano?

At this point in time, surely yes. 10 or 15 years ago, there were
install scenarios where any extra KB increase would break installs in
stuff like Pentium Pros and stuff like this. ;)

I'll bring this up with the d-i maintainer, but as I said it's
basically bringing libtinfo-udeb and libncurses-udeb to the the archive
and switching newt or whatever to use it.

Note that IIRC the real debconf just relies on whiptail or dialog to
show stuff in blue screens.

> Building the tiny nano against ncurses instead of Slang would mean
> that
> it works better, but also that it gets much more testing, so that it
> is
> unlikely to acquire bugs that go unnoticed for a long time.

As I said, I just switched nano-tiny to ncurses. nano-udeb will have to
wait for these changes to happen first.

Thanks for the lengthy analysis, it's about time I did something about
the -tiny/slang situation.

Jordi
-- 
Jordi Mallach <address@hidden>
Debian Project