On Sep 2, 2021, at 05:12, Steven Smith wrote:
> How can this node version conflict be resolved?
The node ports should be fixed so that they do not conflict with one another.
> On Oct 2 2021, at 05:30, Ryan Schmidt wrote:
>
>> On Sep 2, 2021, at 05:12, Steven Smith wrote:
>>
>> How can this node version conflict be resolved?
>
> The node ports should be fixed so that they do not conflict with one another.
Agreed, and tracked by open issue:
https://trac.macports.org
openssl 3.0.0 is out, with a new and very favourable Apache-2 license that will
let many previously non-distributable ports become distributable. However,
there are 758 ports that indicate they link against openssl. That is a daunting
number of ports indeed.
One option might be to move all of
I hope the question that I'm about to ask doesn't induce "Inception"-style
migraines, but since it directly relates to one of the ports I maintain,
here goes. What if one of my ports indirectly uses openssl through one
of its dependencies, and the licensing terms in the current version of my
port o
Blender is GPL-2+, which means it can be distributed when linked with
OpenSSL 3.0, since GPL-3 is compatible with Apache-2.
- Josh
On 2021-10-3 05:09 , Jason Liu wrote:
I hope the question that I'm about to ask doesn't induce
"Inception"-style migraines, but since it directly relates to one of
That was also the Blender devs' claim, which I assume is why they decided
it wasn't necessary to include the GPL-OpenSSL exception text, since any
licensing conflicts would self-resolve once Blender starts using OpenSSL
3.0. But currently, their pre-built release binary downloads and compiles
OpenS
All the pythons build against openssl 3.0.0, so that python issue with all it's
trail-down conflicts will disappear with the upgrade and python revbump.
A very very large % of ports do as well (and those that don't now soon will, as
everyone moves to openssl 3.0.0 as the default, which homebrew
Hi,
Personally I would strongly recommend following a migration path that does not
require an enmass change but allows ports to migrate at their own pace. I
would personally very much recommend an approach similar to that we used for
boost recently
1. Introduced a set of new isolated opensslX
That is exactly the approach that I don't find workable, Chris.
Specifically:
1. every single port (think: rust, ghc, blah blah) will have to be needlessly
managed to build against an alternate openssl location.
2. there will be no default openssl ever in prefix.
So I am not on board for trying
