Swift Package Manager

[Wowfunhappy@gmail.com]

>  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.

> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20201230/1708132b/attachment.htm>