On Thu, Feb 10, 2022 at 01:09:06PM -0500, Neal Gompa wrote: > On Thu, Feb 10, 2022 at 12:59 PM Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> wrote: > > > > On Mon, Oct 18, 2021 at 10:33:59AM +0200, Kamil Dudka wrote: > > > For example dracut, dnf, and rpm seem to use FTP: > > > > > > https://git.kernel.org/pub/scm/boot/dracut/dracut.git/tree/modules.d/45url-lib/url-lib.sh?h=055#n55 > > Here dracut allows ftp://, by calling curl. If curl does not support > > the protocol, this will fail… I think this is what we want. > > > > (BTW, I think the dracut repo on git.kernel.org seems stale… > > https://github.com/dracutdevs/dracut has commits from this week, but > > kernel.org ends at 2021-05-27.) > > > > > https://github.com/rpm-software-management/dnf/blob/f85cf313/dnf/repo.py#L636 > > I think the story would be the same here: if an url with ftp:// was actually > > configured somewhere, the download would fail. But I don't think we have many > > such urls... > > > > > https://github.com/rpm-software-management/rpm/blob/rpm-4.14.0-release/rpmio/url.c#L25 > > This calls %_urlhelper, i.e. '/usr/bin/curl --silent --show-error --fail --globoff --location -o', > > so it will fail on ftp://. > > > > Anyway, with current libcurl-minimal, dnf and rpm both seem to download > > ftp:// urls just fine… (I used [2] for testing since we don't advertise ftp > > anywhere.) > > > > -- > > > > To move this along, I pushed Suggests:libcurl-minimal to systemd-journal-remote > > and systemd-container [1], because those two systemd subpackages Require libcurl.so.4. > > This saves 5MB (out of 105MB) when installing systemd-journal-remote into an > > empty chroot. But those two subpackages are optional so we might get full libcurl > > when something else pulls it in… I think it'd make sense to do this at some lower > > level so that we always get libcurl-minimal by default. > > > > If we added Suggests:libcurl-minimal in filesystem.rpm, it'd be prefered > > everywhere. But we might also get libcurl-minimal if somebody installs > > filesystem.rpm with weak dependencies, which we don't want. So I think this > > should be only added in packages that actually pull in libcurl. But I don't > > see any great candidate, since none of the low-level packages use libcurl. > > This is a bad idea because it creates a crappy user experience when > someone wants the full curl. I don't think so. If you want the full set of protocols, just pull in curl-full. I'm pretty sure that 99.5% of people will not notice, because they use curl with URLs that are actually available, which nowadays is primarily https://. > If an environment should use the minimal one, the environment creator > should explicitly set it. Minimal packages should *not* be in the > default package selection. ... or the reverse: when libcurl is pulled in as a dependency, pull in the smaller version. This makes sense especially with the recommended practice of limiting supported protocols with curl_setopt() internally in the application. In the (unlikely) scenario that people need telnet:// and dict://, they can request curl-full(*). (*) I'm assuming that other rpms that need those protocols from libcurl, will pull in the full libcurl too. Some packaging adjustments might be needed. So this is only about using strange protocols directly from /usr/bin/curl or such. I now filed https://src.fedoraproject.org/rpms/curl/pull-request/12 and https://src.fedoraproject.org/rpms/rpm/pull-request/22. With #12 curl-minimal prefers libcurl-minimal, and with #22, rpm prefers curl-minimal over curl. This should achieve the desired effect on most installations. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
