On Jan 11, 2018, at 01:08, Jan Stary wrote:
> On Jan 10 15:53:59, Daniel Luke wrote:
>> On Jan 10, 2018, at 2:49 PM, Jan Stary wrote:
>>> these ports specify a hard dependency on openssl with "port:openssl".
>> 
>> is libressl now ABI compatible with openssl? IIRC some ports moved from path 
>> back to port style dependencies on openssl since libressl was only 'source' 
>> compatible and so if you have a path-style dependency and users get things 
>> from the buildbot (that were built against openssl) they get non-working 
>> ports
> 
> If you have libressl installed and install e.g. lynx with
> 'port install lynx', it downloads the precompiled lynx,
> installs  it, and reports it as broken, offering to rebuild.
> If you agree to rebuild, it recompiles against the installed libressl.

Correct.

> How exactly is the decision made about lynx being 'broken'
> in this situation?

When a port such as lynx that has a dependency on path:lib/libssl.dylib:openssl 
builds on our buildbot, it always builds with openssl. This is because when the 
buildbot begins building any port, no ports are activated, so there is no file 
at the path ${prefix}/lib/libssl.dylib.

libssl.dylib is actually not a file, but a symlink, pointing to the version of 
the library the port provides.

openssl provides libssl.1.0.0.dylib. The absolute path 
/opt/local/lib/libssl.1.0.0.dylib is baked into the lynx executable as a 
library that it needs in order to run. This is not special to lynx or openssl; 
this is how programs and libraries work on macOS.

libressl does not provide libssl.1.0.0.dylib; it provides libssl.43.dylib.

rev-upgrade runs after every install and upgrade, and checks the library paths 
baked into all the executables and libraries installed by MacPorts. If a port 
contains a program or library, and that program or library specifies the path 
of another library that does not exist, the port is considered broken.

This is why it was a mistake for MacPorts to use a "path:lib/ssl.dylib:openssl" 
dependency for the purpose of allowing a user to switch an openssl-using port 
to libressl. openssl and libressl do not use the same library versioning scheme 
so they are not drop-in replacements for one another. We should have done it 
differently, e.g. with variants. See https://trac.macports.org/ticket/54744.

Reply via email to