Bug 2283867 - Wget2 is not recommended to be used by Fedora 40
Summary: Wget2 is not recommended to be used by Fedora 40
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: wget2
Version: 40
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Neal Gompa
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-05-29 21:48 UTC by Mace Moneta
Modified: 2025-05-27 04:25 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-05-30 00:06:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Mace Moneta 2024-05-29 21:48:04 UTC
Description of problem:
Fedora shipped wget2 as a replacement for wget. I've encountered multiple issues as a result, and backed out to wget-1.21.4-1.fc39.x86_64. When checking for wget2 issue reports upstream, I found this:

https://gitlab.com/gnuwget/wget2/-/issues/661

"It has recently come to our attention that Fedora 40 made the decision to ship GNU Wget2 as GNU Wget. While both the projects are maintained by the same developers and Wget2 is indeed supposed to be the natural successor to Wget, it is just not ready. Upstream was NOT asked for its opinion on this matter. If we had been asked about this, we'd have stated our concerns and said that it's a bad idea."

Version-Release number of selected component (if applicable):
wget2-2.1.0-9.fc40

How reproducible:
Some issues always, some intermittent.

Steps to Reproduce:
1.Various
2.
3.

Actual results:
Errors, incompatibilities, processing hangs

Expected results:
Normal wget operation

Additional info:
Based on the upstream recommendation, wget2 should probably be backed out.

Comment 1 Neal Gompa 2024-05-30 00:06:39 UTC
Sorry, we're not going to back this out. As it is, it seems people are starting to contribute to improve the compatibility with wget 1.x CLI interface now, so this may resolve itself over time.

That being said, you should not be parsing wget output (either 1.x or 2.x) beyond return codes, as everything else is not declared as stable.

Comment 2 Szymon Janc 2025-01-03 11:12:01 UTC
Hello,

This issue is affecting more and more people and should be reopen and fixed (ie wget binary should be provided by wget package, not wget2-wget wrapper)

wget2 is not drop-in replacement for wget [1], it is not compatible not only in output produced, but there are also command line options differences and feature discrepancies (ie no FTP support in wget2)


[1] https://gitlab.com/gnuwget/wget2/-/issues/661

Comment 3 Jaka Jaksic 2025-01-26 03:17:51 UTC
Wget2 breaks not only FTP, it breaks *everything*.

According to its author, Wget2 was never intended to be a Wget replacement or to be in any way backwards compatible with it. It was intended to be used side-by-side!
See here: https://github.com/rockdaboot/wget2/issues/314#issuecomment-2080858803

If Wget2 is to be used at all, it should be installed side-by-side with Wget 1. Creating a symlink via wget2-wget and removing wget entirely is completely misguided, because it prevents even fixing the issue without installing an old RPM.

Wget2 is NOT going to be backwards compatible anytime in the foreseeable future. Unless Redhat itself is going to add implement the missing features (such as FTP) and command line options, this change needs to be reverted. Or rather, now that the damage is done, wget2-wget should become an empty package and just install wget.

Comment 4 Red Hat Bugzilla 2025-05-27 04:25:02 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days


Note You need to log in before you can comment on or make changes to this bug.