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:
> 
>> 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).

Just tested it. rev-upgrade works fine. glib2 @2.46.2_0 provides /opt/local/lib/libglib-2.0.0.dylib (compatibility version 4601.0.0, current version 4601.2.0) while glib2-devel provides /opt/local/lib/libglib-2.0.0.dylib (compatibility version 4701.0.0, current version 4701.1.0). The filename has not changed, but the compatibility version has. So old programs can use new libraries just fine, but programs linked against the new library cannot then use the old library without being rebuilt (which rev-upgrade will detect and do, should that situation arise).