Re: libsdl2 port question

[Ryan Schmidt]

On Nov 14, 2021, at 04:53, Gerben Wierda wrote:

> I was just curious: why does the libsdl2 port which is at version 2.0.16 
> install 2.0.0 libraries? How does that happen? Just learning.

There is no reason why the version of a port needs to have any relationship 
whatsoever with the version of the library(ies) that port installs.

For example, the libiconv port, version 1.16, installs a libiconv.dylib library 
having major version 2 and minor version 9.1.0.

If you have questions about why the versioning of a particular library is the 
way that it is, you should ask the developers of that library.

Re: libsdl2 port question

[Bill Cole]

On 2021-11-14 at 05:53:21 UTC-0500 (Sun, 14 Nov 2021 11:53:21 +0100)
Gerben Wierda via macports-users 
is rumored to have said:

I was just curious: why does the libsdl2 port which is at version 
2.0.16 install 2.0.0 libraries? How does that happen? Just learning.


I assume you mean the fact that the actual dylib file is named 
/opt/local/lib/libSDL2-2.0.0.dylib


It is a norm for dynamically loaded libraries to include a symlink with 
their base name (i.e. /opt/local/lib/libSDL2.dylib) and sometimes 
additional symlinks with partial versions in their names, with the 
versions being indicators of binary compatibility rather than 
whole-project code revision. This allows for multiple incompatible 
versions of the same shared library to be installed simultaneously, with 
the runtime loader picking which version to attempt to load by the name 
linked in the executable. This is a pattern/norm, not a fixed standard, 
so exactly how a specific library handles the possibility of future 
version incompatibility can vary a bit. The libsdl2 devs have apparently 
decided to leave the name of the real library with the lowest version 
that remains compatible with the current version rather than doing 
anything more complex. Others (e.g. pth) use distinct versioning for 
their library names.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

libsdl2 port question

[Gerben Wierda via macports-users]

I was just curious: why does the libsdl2 port which is at version 2.0.16 
install 2.0.0 libraries? How does that happen? Just learning.

Gerben Wierda (LinkedIn )
R&A Enterprise Architecture  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Gerben Wierda via macports-users]

I contacted NLNet Labs, they updated their certs which made NSD fetch on Mojave 
work again for me.

Somewhere during my tests accidentally OpenSSL was activated on my machine (a 
destroot on nsd 4.3.8 maybe?), which killed all the installed ports that were 
dependent on an opensll 1.1.1 dylib (which had been made inaccessible), so 
suddenly a lot of programs couldn’t start anymore (Abort 6) because the dylib 
wasn’t there. That kind of forced me to do a quick update of everything.

So I updated NSD to 4.3.8 and created a pull request for it (as the existing 
MacPorts version 4.1.2 would not compile with OpenSSL3 which is now standard 
and I am an NSD maintainer)

That change has now been merged with MacPorts master (yes! yes! I did it 
correctly! I’m getting the hang of it!)

Everything NSD is back as it should be.

Gerben Wierda (LinkedIn )
R&A Enterprise Architecture  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

> On 8 Nov 2021, at 03:54, Dave Horsfall  wrote:
> 
> On Sun, 7 Nov 2021, Bill Cole wrote:
> 
>>> So I wonder how widespread this problem is?
>> 
>> The problem in this case is not the existence of the cert in the CA bundle, 
>> but the fact that this particular expired cert was used in an alternative 
>> validation path and the logic of verification for multi-path certs isn't 
>> correct. Normally, expired root CAs should stay in there because that allows 
>> positive non-verification of certs supposedly issued by an expired (and 
>> maybe compromised) root CA.
> 
> Gotcha; thanks.
> 
>>> And I'm not happy with those that are set way in the future; I heard 
>>> somewhere that 5 years is the recommended max.
>> 
>> CAs are special. The current limit on server certs is 397 days. I don't 
>> think there's a consensus on CA lifetimes because of the conflicting risks 
>> of too-short and too-long lives.
> 
> One day past a leap year :-)  I don't remember where I saw the 5-year 
> recommendation, unfortunately.
> 
> -- Dave