From: bugzilla@busybox.net
To: buildroot@uclibc.org
Subject: [Buildroot] [Bug 16027] problems building on fedora-40
Date: Wed, 01 May 2024 15:08:52 +0000 [thread overview]
Message-ID: <bug-16027-163-aZsG6fmB5S@https.bugs.busybox.net/> (raw)
In-Reply-To: <bug-16027-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=16027
--- Comment #10 from Yann E. MORIN <yann.morin.1998@free.fr> ---
Hello.
> How about just switching to curl, instead
> of playing around the legacy stuff as wget is?
1. wget is not legacy. cURL and wget were initialy released at about the
same period, in 1996 [0] [1]; both saw their latest release in March 2024.
Hard to say that wget is legacy without saying so for cURL.
[0] https://en.wikipedia.org/wiki/Wget => January 1996
[1] https://en.wikipedia.org/wiki/CURL => November 1996
2. cURL can be configured without FTP support [2], so if switching from wget
to wget2 was done, knowing that FTP was dropped, and considering that was
acceptable on the basis that FTP is legacy (broken, insecure...), then it
is not inconceivalbe that distros may consider truning FTP off in their builds
of cURL, ion the same basis (broken, insecure...). Switching to cURL would
not solve the issue. Yes, it is a bit far-fetched, but given the reasoning
behind wget2 switch, it is legit to consider it for other tools that are not
FTP-only.
[2] https://github.com/curl/curl/blob/master/configure.ac#L631
3. Existing packages (in external trees) may use wget's authentication options
yo authenticate to an HTTP server; switching to cURL would break them. That
also applies to existing (def)config files that use non-standard options, like
--no-proxy to talk to internal servers, or --load-cookies with a pre-build
script that authenticates against an internal server or filled by a CI/CD
job, etc...
4. For all things HTTP-related, wget2 is expected to be option-compatible with
wget.
5. As a consequence, it feels more appropriate to keep using wget for HTTP/S
downloads, and use a tool dedicated to FTP for FTP downloads, and implemented
as a separate backend in Buildroot.
Regards,
Yann E. MORIN,
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2024-05-01 15:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-09 18:45 [Buildroot] [Bug 16027] New: problems building on fedora-40 bugzilla
2024-04-09 19:21 ` [Buildroot] [Bug 16027] " bugzilla
2024-04-09 19:23 ` bugzilla
2024-04-09 19:42 ` bugzilla
2024-04-30 14:13 ` bugzilla
2024-04-30 14:59 ` bugzilla
2024-05-01 5:30 ` bugzilla
2024-05-01 7:25 ` bugzilla
2024-05-01 9:53 ` bugzilla
2024-05-01 10:08 ` bugzilla
2024-05-01 15:08 ` bugzilla [this message]
2024-06-08 13:00 ` bugzilla
2024-06-15 15:22 ` bugzilla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-16027-163-aZsG6fmB5S@https.bugs.busybox.net/ \
--to=bugzilla@busybox.net \
--cc=buildroot@uclibc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox