openssl vs. libressl

[Ryan Schmidt]

On Nov 10, 2015, at 11:59 AM, Jeremy Huddleston Sequoia wrote:
> 
> On Nov 10, 2015, at 00:17, Ryan Schmidt wrote:
>> 
>> On Nov 9, 2015, at 6:10 PM, Jeremy Huddleston Sequoia wrote:
>> 
>>> On Nov 9, 2015, at 13:10, René J.V. Bertin wrote:
>>> 
>>>> On Monday November 09 2015 15:05:26 Ryan Schmidt wrote:
>>>> 
>>>>> In r139229 Jeremy made libressl a drop-in replacement for openssl. If a rebuild is needed to make things work, then this
>>>> 
>>>> Yes, but at least on Linux libressl installs libraries with different numbers (libssl.so.35 vs libssl.so.1.0.0). I haven't yet checked on OS X, but if this is the case there too then Jeremy's modification (using path: style dependencies) is not enough.
>>> 
>>> Yes, the dylib identifiers (and filenames) are different.
>>> 
>>> This is the same solution we've used elsewhere in MacPorts (eg: ffmpeg-devel).
>> 
>> That's not the same situation. If a user had been using glib2 and then later needed to switch to glib2-devel for some reason, everything should still work.  All the ports they've installed based on glib2, or all the ports they might download from the buildbot in the future that were built against glib2, should continue to work with glib2-devel installed. glib2-devel might install a later version of the libraries, but they should be backward compatible.
> 
> That is until glib2-devel becomes ABI-incompatible and has a newer dylib identifier.
> 
>> Granted, the user might need to then stay on glib2-devel until the next stable version of glib2 is released, after which time the user could switch back to glib2. Or else the user would need to rev-upgrade.
> 
> rev-upgrade only helps if the dylib identifiers changed.  In your scenario, you seem to indicate that glib2-devel and glib2 won't have different identifiers (which is why just swapping out glib2 worked).  As such, going back to glib2 from glib2-devel won't trigger any rev-upgrade hits because rev-upgrade looks at the image links and not the symbol linkage (AFAIK).
> 
>> I don't know how carefully the ffmpeg developers version their software.
> 
> There are (or have been in the past) very frequent ABI-breaking changes.  As you may know, almost every major version of ffmpeg requires that we revbump all dependent ports.  Before the ffmpeg upgrade, ffmpeg-devel is not compatible with ffmpeg.

So in that regard, I consider ffmpeg the exception. Well-behaved software would not have such frequent breaking changes, and the other -devel ports I mentioned don't.


> On Nov 10, 2015, at 02:46, Ryan Schmidt wrote:
> 
>> The alternative is variants, but it's not a good solution because of the extra effort it imposes on port maintainers and users.
>> 
>> It might be better to take the choice away from the user and just make a decision that we want libressl to be our default ssl library in MacPorts. Change the libressl and openssl ports so that they do not conflict, but rather install in different locations. Then ports that are currently using openssl can be switched to use libressl instead, if they are compatible, while those that are not compatible can continue to use openssl.
> 
> The issue is discoverability.  Every dependent port would need to know how to look in those alternate locations, and it wouldn't "just work" for developers that are trying to use openssl or libressl.

I was assuming that whatever we decide is the default library -- currently openssl, I propose switching it to libressl -- gets installed in the default location that all software already knows to look in. And the other one -- openssl -- gets installed in a nonstandard location, and only those presumably few ports that require openssl and are not compatible with libressl would be configured to use it.

If we don't want to switch to libressl as a default, then I don't know why libressl is in MacPorts.


> On Nov 10, 2015, at 06:21, Daniel J. Luke wrote:
> 
>> One other way to handle it would be how we tried to handle perl5 for a while (which doesn’t really work that well for perl, but may apply here).
>> 
>> We could have a port “mp-ssl-lib” that defaults to depending on one of the ssl libs (say openssl). It could also be installed as mp-ssl-lib +libressl which would modify it’s dependencies and install libressl and not openssl.
>> 
>> Other ports would all depend on ‘mp-ssl-lib’ and not directly only openssl or libressl.
>> 
>> It’s not a perfect solution, but may be nicer than adding +openssl/+libressl to every possible port.
> 
> Yeah, it's kinda like what we're doing with the ld64 port.  It's like using a port to force a particular 'port select ...'
> 
> It would be better if we could force 'port select XXX' to just not be none, and then eliminate these meta/pointer ports, but that's not functionality we currently have.

It's functionality we don't have because it would go against our stated purpose of the port select mechanism, which is that it's for the user to use, not for MacPorts ports to rely on, because it would lead to non-repeatable builds / ports that build differently on different users' systems with no indication of that in the selected variants. That's not compatible with the concept of binary archives delivered from our server.