RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
Hi!
There's been talk about switching away from netkit-telnet and
netkit-telnetd as the default implementations for some time now,
and replacing them with the ones from inetutils, which is a maintained
project and does see releases (even though with a long cadence).
This has been discussed somehow in #982253 and #987729.
These packages currently use a pair of virtual packages to denote
that they are a telnet or telnetd implementation (telnet-client and
telnet-server). One problem is that currently the netkit implementations
use the generic telnet and telnetd package names, which is a clear way
to mark them as the default implementations (instead of say the other
convention of naming or providing a default-foo package). Another is
that several packages depend on these generic names instead of the
virtual packages, see below for a list that would deserve a non-blocking
"mass" bug filing, which I can handle as part of the switch.
The inetutils-telnet recently got support for the missing «-b» option
for compatibility with netkit-telnet.
The inetutils-telnetd and netkit-telnetd have diverging options and some
conflicting ones, but after pondering about it I don't think this should
be a major issue, as the daemon does not tend to get called by users from
scripts and similar. For completeness the divergences are these:
inetutils-telnetd netkit-telnetd
----------------- --------------
short and long options short options
<missing> -D (unimplemented «exercise» mode)
-D (debug modes «auth», «encr») -edebug
-S, --server-principal -S (used to set the IP TOS)
-E, --exec-login -L
-l, --linemode <missing>
-U, --reverse-lookup -N (related but not exactly the same)
Simon Josefsson (CCed), who is one of the inetutils upstream maintainers,
recently adopted the netkit-telnet source package in Debian, which he'd
prefer to keep around for a smoother transition period, in case users
want or need to revert back.
So, the idea would be for src:inetutils to take over the telnet and
telnetd binary packages and make them transitional packages depending
on the inetutils variants, for a smooth upgrade, and in addition also
start providing them by the inetutils-<name> packages.
The src:netkit-telnet would then switch to ship netkit-telnet and
netkit-telnetd binary packages (this would ideally be uploaded to
experimental first, so that once ACCEPTED it can be uploaded to sid
once we start the switch, with no missing implementation in between).
I'm inclined to do it in this order to potentially avoid two trips over
NEW, and to reduce any potential disruption period.
In the future (after the next stable release) the telnet/telnetd
packages could be switched to be pure virtual packages, taking the role
of denoting the current default implementation, instead of introducing
default-<foo> variants, as that's what users are currently used to, and
it would keep working even if the depending packages below do not update
their dependencies.
We'd file an override request against ftp.debian.org to get the
inetutils-telnet Priority bumped to standard to match the current
telnet package (which could get then its Priority lowered to optional).
Currently inetutils and netkit have the same alternative priority
for telnet, I'd probably bump it also to 150 for inetutils to take
precedence.
If there are no objections, we could probably start working on this
switch in a couple of weeks or so.
List of packages depending on telnet (but not telnet-client):
forensics-extra (Depends)
lava (Depends)
live-task-standard (Depends)
mininet (Depends)
vland (Depends)
zssh (Depends)
dish (Recommends against all current implementations)
lava-dev (Recommends)
lava-dispatcher (Recommends)
live-task-extra (Recommends)
pdudaemon (Recommends)
libtelnet-dev (Suggests)
libtelnet-utils (Suggests)
procserv (Suggests)
ser2net (Suggests)
tucnak (Suggests)
List of packages depending on telnetd (but not telnet-server):
telnetd-ssl (Conflicts)
nyancat-server (Conflicts)
Thanks,
Guillem
Reply to: