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
