Swift Package Manager

[Ryan Schmidt]

On Dec 30, 2020, at 10:30, Wowfunhappy at gmail.com wrote:

>> You are one of our strongest proponents of keeping software working on older systems. A build system that forces fetching from a specific upstream server reduces our ability to build on older systems, since that specific server might have https requirements that older system can't meet. We need to be able to mirror files on our servers so that older MacPorts clients can download from them.
> 
> Excuse me for butting in, but I fundamentally don't understand why Apple's https being outdated is causing problems for MacPorts. Doesn't MacPorts try to use it's own versions of things anyway?
> 
> So, MacPorts could:
> 
> 1. Install its modern version of OpenSSL (which supports all modern HTTPS features).
> 2. Link Swift Package Manager to Macports's OpenSSL.
> 
> Perhaps step 2 is more complicated than I'm imagining in my head? I mean, ideally Swift Package Manager would fetch resources over curl (or something) and you wouldn't even need to patch anything, just set PATH to use MacPort's curl (which I assume is also linked to MacPorts's OpenSSL) instead of the system's curl.
> 
> Relying on Apple's SSL implementation creates precisely the same problems as relying on Apple's version of sed or make or whatever else—it differs between systems and is less reliable as a result.

Ok you're right, I was thinking of MacPorts base and not Swift Package Manager.

MacPorts base does its network communications using libcurl, and because it cannot rely on any port that is installed by MacPorts (since when you first install MacPorts, no ports are installed), by default it uses the libcurl provided by macOS. On older versions of macOS, that libcurl is linked with a version of openssl that is so old that it does not support any of the cipher suites that many of today's web sites, including GitHub and SourceForge, require.

I am not familiar with Swift Package Manager but if it can be told to downloading using a newer ssl library from MacPorts, then that would address this part of the problem.


>> Tying us to a specific upstream server also ties us to the reliability of that server. If it goes down, we go down, and users flood us with bug reports about it. We don't want that.
> 
> This seems like the bigger problem, and it's a real one. But now we're back to (what I thought was) Ken's original point—if this is the way the world is going, we can agree that it's bad but to what extent is fighting it worthwhile?

I don't think it's unreasonable to want to be able to download software from an http(s) server, unpack it, and build it. That's how MacPorts is designed to work. I don't think it's unreasonable to engage with projects that make that workflow difficult to figure out how to improve it.