On Dec 29, 2019, at 10:58, Mojca Miklavec wrote:
> On Sun, 29 Dec 2019 at 13:46, Rainer Müller wrote:
>
>> 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:
[snip]
> - shipping our own bundled copy of libcurl (dismissed many times as
> not feasible)
I still believe bundling libcurl and libressl or openssl with MacPorts is the
correct solution, as I have previously argued in #51516. There is also a link
in that ticket to an implementation, so it is definitely feasible. I have not
had the energy to renew the argument in that ticket after the latest objection,
and there are only so many ways that I can express the views that I've already
expressed there.
> 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.
[snip]
It is a bad idea in as much as it means we are writing all of our curl code
twice: once for libcurl and a second time for the curl program. This is a
duplication of effort and presents a great opportunity for us to mess up such
that a MacPorts feature works when using libcurl but not when using curl or
vice versa.
