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