openssl vs. libressl

Jeremy Huddleston Sequoia jeremyhu at macports.org
Tue Nov 10 09:59:58 PST 2015


> On Nov 10, 2015, at 00:17, Ryan Schmidt <ryandesign at macports.org> 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.

---

> On Nov 10, 2015, at 02:46, Ryan Schmidt <ryandesign at macports.org> 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.

---

> On Nov 10, 2015, at 06:21, Daniel J. Luke <dluke at geeklair.net> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4118 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20151110/08d68267/attachment.p7s>


More information about the macports-users mailing list