fetch ssl errors on _some_ buildbots

Mihai Moldovan ionic at macports.org
Sun Mar 22 15:19:56 PDT 2015


Sorry, I was typing away at my other answer and haven't seen yours prior
to sending my last mail.


On 22.03.2015 11:07 PM, Rainer Müller wrote:
> On 2015-03-22 20:47, Ryan Schmidt wrote:
>> We should totally ship a newer version of curl and openssl or gnutls with MacPorts, like we already ship a version of Tcl.
> 
> I don't think it is worth to invest resources into this. The usual
> policy is to support the latest two releases of OS X. Any release older
> than OS X 10.9 Mavericks should be considered legacy.

So... what's the best way to deal with issues like this one? Ignore
them? Change the fetch type to HTTP if possible? (Note: this may not be
supported by all servers -- for instance because they are automatically
redirecting to HTTPS. I've personally set up a few (sub-) domains in
that vain.) Manually mirror the distfiles? (I don't even know if it's
currently possible to manually upload distfiles.)


> Pulling more dependencies into base means we need to actively maintain
> them. This is especially critical for SSL libraries and a certificate
> bundle. I am afraid we would start to implement our own package
> management for the base of our package manger.

That's unfortunate and true.


> Also, I am reluctant to pull software into base that is not covered by a
> BSD license. OpenSSL has an advertising clause, GnuTLS is LGPL.

On 22.03.2015 11:12 PM, Ryan Schmidt wrote:
> I agree with that.


Pulling in a package under LGPL license is probably better than one
under the OpenSSL license. But I also agree that it's better to plainly
avoid legal complications.



Mihai


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150322/d12791b6/attachment.sig>


More information about the macports-dev mailing list