Am 03.09.22 um 15:17 schrieb Simon Josefsson:
Bastian Germann <b...@debian.org> writes:
Thanks for preparing the transition from netkit-telnet to the inetutils version.
We can get rid of this source package by recommending the netkit-telnet-ssl
packages on inetutils instead.
Why have the same non-maintained upstream source twice?
Hi. That's a great observation, thanks for sharing it. I didn't look
too close at the netkit-telnet-ssl package, and merely assumed it was
widely different compared to netkit-telnet thus saving it for another
rainy day.
They at least share the same orig.tar.gz:
jas@latte:~/n$ sha1sum netkit-telnet_0.17.orig.tar.gz
netkit-telnet-ssl_0.17.41+0.2.orig.tar.gz
41213dedaf242126b54a3ac51b905a351eb22b15 netkit-telnet_0.17.orig.tar.gz
41213dedaf242126b54a3ac51b905a351eb22b15
netkit-telnet-ssl_0.17.41+0.2.orig.tar.gz
jas@latte:~/n$
So all changes between the packages are derived from the debian/
differences, which reduces the comparison surface, but digesting the
diff wasn't that simple. I started focusing on debian/patches and even
that was non-trivial:
Only in netkit-telnet/patches/: 110-markup_errors.diff
markup_errors is not included in -ssl.
Only in netkit-telnet/patches/: 124-support_uservar.diff
included in -ssl as 610-support_uservar.diff
Only in netkit-telnet/patches/: 140-telnetlogin_name_check.diff
Included in -ssl within 514-mixed_up_to_24_7_1.diff
Only in netkit-telnet/patches/: 142-numeric_hosts.diff
included in -ssl as 512-numeric_hosts.diff.
Only in netkit-telnet-ssl/patches/: 500-implement_ssl.diff
Only in netkit-telnet-ssl/patches/: 510-can_2004_0640_and_0998.diff
Only in netkit-telnet-ssl/patches/: 512-numeric_hosts.diff
Only in netkit-telnet-ssl/patches/: 514-mixed_up_to_24_7_1.diff
Only in netkit-telnet-ssl/patches/: 516-telnet_up_to_24_7_1.diff
Only in netkit-telnet-ssl/patches/: 518-telnetd_up_to_24_7_1.diff
Only in netkit-telnet-ssl/patches/: 520-from_7_1_to_14.diff
Only in netkit-telnet-ssl/patches/: 530-from_14_to_21.diff
Only in netkit-telnet-ssl/patches/: 540-buffer_overflow.diff
Only in netkit-telnet-ssl/patches/: 545-track_scm.diff
Only in netkit-telnet-ssl/patches/: 600-better_diagnostic.diff
Only in netkit-telnet-ssl/patches/: 610-support_uservar.diff
Only in netkit-telnet-ssl/patches/: 630-recent_libssl.diff
Only in netkit-telnet-ssl/patches/: 650-improve_abilities.diff
diff -ur netkit-telnet/patches/series netkit-telnet-ssl/patches/series
Only in netkit-telnet/patches/: telnet-netwritebuf-fix.diff
telnet-netwritebuf-fix is not included in -ssl.
diff -ur netkit-telnet/patches/use-cmake-as-buildsystem-debian-extras.patch
netkit-telnet-ssl/patches/use-cmake-as-buildsystem-debian-extras.patch
diff -ur netkit-telnet/patches/use-cmake-as-buildsystem.patch
netkit-telnet-ssl/patches/use-cmake-as-buildsystem.patch
Reaching confidence that netkit-telnet-ssl and netkit-telnet are
sufficiently similar so that there is no use-case where one of the
packages fail to work but the other does seems difficult. Is anyone
interested in doing that analysis?
I have just uploaded a -ssl QA upload that should include all work done in your
package
and be good enough to continue work there.
Another option is that we let time and bug reports perform the
confidence analysis for us, so we could ship netkit-telnet and
netkit-telnet-ssl with bookworm, since that will be the first time
inetutils becomes the "default" telnet/telnetd, and people may want to
go back with netkit-telnet for some reason. The release notes could say
that we want to drop netkit-telnet* and people should report any
compatibility problem they encounter with GNU InetUtils so we can plan
accordingly.
I think that we should not ship both source packages with bookworm.
When people see issues with one of them, there should only be one place to fix
them.
telnet-netwritebuf-fix is an example that was just fixed for the non-ssl
version.
Alternatively, work on netkit-telnet and netkit-telnet-ssl to sync them.
I'm happy to do that in netkit-telnet but cannot speak for the
maintainers of netkit-telnet-ssl. Then if we incrementally make them
closer to each other it will become clear if netkit-telnet provides
anything that netkit-telnet-ssl cannot.
There are no maintainers for netkit-telnet-ssl. It is orphaned.
I suggest you adopt that package, recommend the -ssl version on inetutils,
and file a RM bug for the non-ssl package.
I don't have a strong opinion on any solution, but I think we should be
conservative in what we do -- it may years for people to realize
civilization depends on a particular behaviour of netkit-telnet...
Yes, but they still have that behaviour with netkit-telnet-ssl.
