fetch timeout

[Christopher Jones]

> On 20 Jul 2022, at 6:32 pm, Dave Allured - NOAA Affiliate via macports-dev <macports-dev at lists.macports.org> wrote:
> 
> On Wed, Jul 20, 2022 at 2:30 AM Christopher Jones <jonesc at hep.phy.cam.ac.uk <mailto:jonesc at hep.phy.cam.ac.uk>> wrote:
>> On 20 Jul 2022, at 1:13 am, Dave Allured - NOAA Affiliate via macports-dev <macports-dev at lists.macports.org <mailto:macports-dev at lists.macports.org>> wrote:
>> 
>> Hmmm.  If port curl is already installed and active, then why would subsequent port fetches prefer /usr/bin/curl?  Is this a search path issue?
> 
> No. port does not rely on finding ‘curl’, from PATH. It instead uses the system lib curl which it is liked against. The only way to get port to use a different curl is to rebuild base, configured to use that version.
> 
> Ah, that is what I missed.  How about adding a fallback option to use an alternate command line curl through PATH, when available, after normal fetch attempts have failed?  My hope is that this would ultimately reduce time spent on debugging connection and SSL issues.

Please read the discussion at

https://trac.macports.org/ticket/51516 <https://trac.macports.org/ticket/51516>

and add any comments you might have. 

In short, adding a ‘fallback to curl’ is very non trivial to do, perhaps not even possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220720/a3905fc5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1930 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220720/a3905fc5/attachment-0001.bin>