#3215 Potential reversion for wget2 as wget F40 change might be needed
Closed: Rejected by zbyszek. Opened by amoloney.

Hi FESCo,

A discussion has come to my attention that may require your guidance, so I am opening this ticket for your awareness in case a revision on the wget2 as wget change for F40 is needed. The issue is more detailed on the upstream tracker and was raised on the discussion topic only recently. My ask is to review the concerns please and determine whether a revision on the F40 change is in fact needed or not.

Thank you kindly!
Aoife


I don't think we need to do anything. The switchover was already acknowledged to have some missing functionality (around FTP stuff), but Wget2 is actively developed, and since we switched, new folks have started contributing to fill in other gaps as needed.

One particular example: https://src.fedoraproject.org/rpms/wget2/c/ff3ad5a501070454ea53915644b52dedb89dc40c

And Wget2 supports newer HTTP standards that Wget 1.x does not.

I think there's a reasonable discussion to be had for RHEL/CentOS Stream 10 here, but as for Fedora... I think I'd actually rather keep with wget2 as the default wget implementation going forward. As @ngompa notes, the upstream has seen a flurry of activity and contributions since we made this switch, which is definitely a positive outcome.

That said, I wouldn't be opposed to optionally also shipping the wget 1.x package as /usr/bin/wget1 for people to use in places where adapting to the changes in the 2.x release is too difficult for one reason or another. I'd warn against trying to do anything like using the alternatives system here though; they're not truly drop-in replacements for one another.

Yeah, I think it's unfortunate that upstream wasn't ready for this, but I don't know that we can easily go back...

I think its encouraging that some real bugfixes have been made as a result.

I also think that this isn't something that we'd want to do. I'll close this ticket.

FWIW, I think that people who rely on parsing command line tool pretty output in scripts deserve to keep all the pieces when inevitably this pretty output is changed. So I don't consider that part particularly important. OTOH, some option names were changed, and that is unfortunate. It's always better to avoid and minimize such changes, but it's also acceptable to make such a change at release boundary. In this case we even had a Change page, so I think the breakage is acceptable. At this point, going back would probably cause problems too and it seems to late to do that. And as said, the new implementation has some advantages over the old one.

Metadata Update from @zbyszek:
- Issue close_status updated to: Rejected
- Issue status updated to: Closed (was: Open)

Metadata