Yeah, not unlike how we bundle Tcl/tk now. Once upon a time, we used the system version of that too. With Apple looking to ditch supporting a "system version" of things like python, I imagine we might be better off with libcurl/openssl. The only problem there is ssl has a lot of security patches so we might have to make a lot of point releases.
—Mark On Fri, Jan 3, 2020 at 2:22 AM Ryan Schmidt <[email protected]> wrote: > > > 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. > > >
