Bug#987729: inetutils-telnet: provide upgrade path for orphan netkit-telnet
Hi! On Fri, 2022-08-05 at 22:13:15 +0200, Simon Josefsson wrote: > Guillem Jover writes: > > Sure. As per the plan on debian-devel, whenever you have some time, could > > you prepare the netkit-telnet update targeting experimental, which > > renames the binary packages to be prefixed with netkit-*? Then once these > > get ACCEPTED from NEW, we can coordinate the upload of netkit-telnet and > > inetutils into unstable. > > Hi! Great. I have uploaded it now, and my main problem is thinking > about upgrades. In git, I have renamed telnet(d) to netkit-telnet(d) > now, and added Replaces/Breaks on the old versions. How do we test > upgrade paths? It is not clear to me what should happen in all cases > (e.g., system with telnet+inetutils-telnet installed, alternatives > pointing to netkit, do we want that to upgrade both packages and change > alternative?). And it seems it was ACCEPTed yesterday! I've prepared the following changes inetutils: https://git.hadrons.org/cgit/debian/pkgs/inetutils.git/log/?h=pu/default it seems to handle the upgrade correctly. For telnetd we need to remove the inetd entry otherwise update-inetd will prompt, for telnet we should remove the alternative otherwise there are warnings about disappearing implementations for the alternative. I've tested this by installing the telnet/telnetd package and then just running the equivalent of «apt install ./inetutils-telnet*.deb ./telnet*.deb». If you can have a peek that would be nice, then once we are satisfied we can decide on a day, where I upload inetutils to sid first, to take over the telnet/telnetd, then once that's accepted you could upload the netkit from experimental to sid. Thanks, Guillem
Bug#987729: inetutils-telnet: provide upgrade path for orphan netkit-telnet
Hi Simon! On Fri, 2022-07-08 at 20:40:01 +0200, Simon Josefsson wrote: > Guillem Jover writes: > > 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. Which I did, and there didn't seem to be objections to the actual plan. > >> 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. > > I'm open to anything here -- my idea with adopting netkit-telnet it was > to be able to control the transition. Sure. As per the plan on debian-devel, whenever you have some time, could you prepare the netkit-telnet update targeting experimental, which renames the binary packages to be prefixed with netkit-*? Then once these get ACCEPTED from NEW, we can coordinate the upload of netkit-telnet and inetutils into unstable. > I'm happy to co-maintain netkit-telnet with you on salsa, if you have > ideas how that package should evolve. Thanks for the offer, although I think I'd rather not maintain more abandoned upstream packages. :) > >> 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. > > It is easier to do one thing at a time, so if starting with only telnet > gets us going anywhere, I'm in favor of that. As you probably saw, after some thought, it seemed like doing both seemed fine. I'm going to be filing the bug reports mentioned in the mail to debian-devel, and prepare an inetutils branch for the switch during the weekend. Thanks, Guillem
Bug#987729: inetutils-telnet: provide upgrade path for orphan netkit-telnet
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- 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
Bug#987729: inetutils-telnet: provide upgrade path for orphan netkit-telnet
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. 1) What needs to be done in d/control for the inetutils-telnet package? Should it 'Provides: telnet' and 'Replaces: telnet'? Anything more? 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. 3) The implementations needs to be analyzed for compatibility. The --usage outputs are like this: Usage: telnet.netkit [-4] [-6] [-8] [-E] [-L] [-a] [-d] [-e char] [-l user] [-n tracefile] [ -b addr ] [-r] [host-name [port]] Usage: inetutils-telnet [-468acdEKLrx?V] [-e CHAR] [-l USER] [-n FILE] [-k REALM] [-X ATYPE] [--ipv4] [--ipv6] [--binary] [--login] [--no-rc] [--debug] [--escape=CHAR] [--no-escape] [--no-login] [--user=USER] [--binary-output] [--trace=FILE] [--rlogin] [--encrypt] [--realm=REALM] [--disable-auth=ATYPE] [--help] [--usage] [--version] [HOST [PORT]] 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. Further feature comparisons would be welcome though. 4) The man page for inetutils-telnet is less useful than the netkit-telnet man page. I think this could be improved upstream in inetutils, and will work on that. 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. Thoughts? /Simon signature.asc Description: PGP signature
