Hi! On Wed, 2021-04-28 at 19:11:11 +0200, Simon Josefsson wrote: > Package: inetutils-telnet > Severity: wishlist
> As discussed in https://bugs.debian.org/982253 netkit-telnet is not > (actively) maintained upstream or in Debian. Inetutils may not be the > state of the art as a well-maintained project, but at least there are > upstream releases and good packaging in Debian. > > I believe 'apt-get install telnet' should install inetutils-telnet > rather than netkit-telnet going forward. Once bullseye is released it > is a good time to make the switch. I'm opening this bug to find out > what needs to be done in order to make this happen, if there is > agreement that this is a good idea. Discussed this with Simon off-bts, and it seems I had dropped the ball here because I thought this was blocked on something else or similar. > 1) What needs to be done in d/control for the inetutils-telnet package? > Should it 'Provides: telnet' and 'Replaces: telnet'? Anything more? I think the proper way to do this, would be for src:inetutils to grow (and take over) a couple of telnet (and ideally telnetd) transitional binary packages, that depend on inetutilds counterparts. The inetutils-telnet (and also inetutils-telnetd) to then also gain telnet (and telnetd Provides). Because telnet is managed through alternatives, once netkit-telnet becomes a transitional package, then there's not much to do, the upgrade will take care of cleaning things up. For telnetd this is a bit more tricky, as the programs are named differently so inetd or other init system hooks might be lost during a transition and this needs to be accounted for. We could always start with telnet, and then do telnetd, but I'd rather do both TBH. There are packages that depend only on telnet or telnetd (instead of in addition to the the virtual telnet-client and telnet-server). Those should get bug reports to switch to the «telnet | telnet-client» and «telnetd | telnet-server» forms, so that alternative implementations can be used. But otherwise we can simply use telnet and telnetd as a form of default-<something> virtual package, as used in other parts of the archive. We'd need to send a mail to debian-devel, announcing the transition, to check whether there's any objection. I can prepare something during the weekend. > 2) Is it required for 1) that the netkit-telnet package is removed from > Debian? Maybe the package could live on and ship 'netkit-telnet' > instead of the 'telnet' package? Perhaps that package could continue to > live on in unstable, but never ship with a future release in favor of > inetutils-telnet. That's something I was wondering, after you adopted netkit-telnet. If you'd like to keep the netkit packages, then renaming the binary packages would be the way to go, yes. If so, then we have two options, either netkit keeps the telnet/telnetd packages and turns them into transitional dummy packages pointing at the inetutils ones, and then ships the real things in netkit- namespaced ones, or src:inetutils takes them over, which does not require going through NEW, but then the src:netkit-telnet might get garbage collected. But given that it would need to go through NEW anyway, that might be the quickest way to go about it. > 3) The implementations needs to be analyzed for compatibility. The > --usage outputs are like this: > A quick comparison indicates that inetutils-telnet is missing the '-b > addr' command. I'll try to verify that the parameter actually does the > intended thing in netkit-telnet, and then see if I can implement that > upstream in inetutils. Which you implemented subsequently! Thanks. > Further feature comparisons would be welcome though. Sure. > Similar thoughts applies to inetutils-telnetd vs netkit-telnetd too, but > I wanted to start with something simple so I chose inetutils-telnet. > Since telnet and telnetd is shipped from the same netkit-telnet source > package, it may that if 2) is involved above, something needs to happen > to inetutils-telnetd too, and then so be it. I'm fine with doing this step-wise or wholesale. If doing telnetd at the same time might look like blocking telnet, then we can start with just that one, but that would require going through NEW twice, which does not look ideal. Given the above open questions, I think I'm just going to update to the latest upstream now, and then we can check how to proceed in the coming days. Thanks, Guillem
