On Sun, 29 Dec 2019 at 13:46, Rainer Müller wrote: > On 29.12.19 10:50, René J.V. Bertin wrote: > > On Saturday December 28 2019 21:51:07 Ryan Schmidt wrote: > > > >> If I understood the patch correctly, it adds a fallback so that if > >> fetching via the curl library fails, then it tries fetching via the curl > >> command line program. To my knowledge MacPorts has never had code for > >> using the curl command line program, only the curl library. > > > > It does, and if it didn't then I guess this snippet must have been proposed > > during a discussion on a mailing list, or maybe it had already been > > contributed. > > > > Either way, the idea makes sense even if the implementation leaves to be > > desired, no? > > I see no reason for such a fallback. We use libcurl, why should we > duplicate the code to additionally support curl? > > The real problem here is that your operating system is out of date and > cannot communicate with servers that require modern crypto. Going > forward, this will affect many more applications and not only MacPorts.
Except in this case it requires 10.12., which is newer than what our existing infrastructure hardware supports? Yes, I know that not even 10.11 is supported any longer, so that one also counts as outdated. And the port in question is not even in our port tree, but that's irrelevant to the discussion. > See also: > https://trac.macports.org/ticket/51516 Thinking of it ... the reported/suggested patch doesn't sound as bad after all. Considering the potential alternatives of: - manually downloading and copying the files (out of question, too much work, cannot be automated) - constantly fighting with broken updates & not being able to test anything - shipping our own bundled copy of libcurl (dismissed many times as not feasible) - introducing a cyclic dependency & chicken-and-egg problem of using curl or wget as we ship it (not possible) - installing a second copy of macports just for the sake of being able to build libcurl, manually building the full compiler toolchain just for that simple program, manually compiling macports and getting the change overridden each time MacPorts is outdated (the only acceptable solution that's annoying at least) ... then trying to repeat the download with either ${prefix}/bin/curl or ${prefix}/bin/wget or whatever "default curl" points to (which would always resolve to /usr/bin/curl if port curl is missing) doesn't sound like such a bad idea to me. It could be a non-default configuration option that only interested users on older systems would turn on, or that would only be turned on by default on older systems ... to make their user experience slightly better. (Keep in mind that while this is definitely not our main focus, we are probably the best package manager as far as support for older OSes is concerned.) Mojca
