On Sun, 20 Sep 2015 10:22:59 +0200 Alexis Ballier wrote: > > > My idea would be: > > > > > > 1. import "dev-libs/libressl" (this will block dev-libs/openssl) and > > > introduce the global USE flag "libressl" with the following > > > description: > > > > Please try to avoid such block, e.g. install libressl to a separate > > location. This is easier to do when introducing package to the > > tree, rather when facing large-scale blockers. Otherwise one day we > > will face nasty bug like mutual heimdal/mit-krb5 blocker[1], where > > foo will work only openssl, bar only with libressl and users will > > need both. > > If they're abi incompatible but share some namespace (symbols, soname, > library names, etc.) I think that's a terrible idea since that'd > introduce runtime bugs. > > I've faced something like that recently: opencv can link to qt4 or qt5. > but if you link a qt5 program to opencv[qt4] it'll fail in terrible > ways. you'd have the same replacing qt4/qt5 by libressl/openssl.
Probably slotting of opencv will help here: have both qt4 and qt5 versions. Other distributions are being able to handle mit-krb5 and heidmal on the same system simultaneously, so should we. Situation with openssl/libressl, ffmpeg/libav and so on is effectively the same: when we have couples of libraries deliberately incompatible with each other why sharing pretty much common namespace. Best regards, Andrew Savchenko
pgptGoyvixpNt.pgp
Description: PGP signature
