1 |
On Sun, 20 Sep 2015 09:07:09 +0300 |
2 |
Andrew Savchenko <bircoph@g.o> wrote: |
3 |
|
4 |
> Greetings, |
5 |
> |
6 |
> On Sat, 19 Sep 2015 23:04:14 +0200 hasufell wrote: |
7 |
> > Friends, |
8 |
> > |
9 |
> > I think it is time to import LibreSSL[0]. There are not many |
10 |
> > packages left that don't compile OOTB and those can be patched |
11 |
> > (e.g. dev-lang/ruby). |
12 |
> > |
13 |
> > My idea would be: |
14 |
> > |
15 |
> > 1. import "dev-libs/libressl" (this will block dev-libs/openssl) and |
16 |
> > introduce the global USE flag "libressl" with the following |
17 |
> > description: |
18 |
> |
19 |
> Please try to avoid such block, e.g. install libressl to a separate |
20 |
> location. This is easier to do when introducing package to the |
21 |
> tree, rather when facing large-scale blockers. Otherwise one day we |
22 |
> will face nasty bug like mutual heimdal/mit-krb5 blocker[1], where |
23 |
> foo will work only openssl, bar only with libressl and users will |
24 |
> need both. |
25 |
|
26 |
If they're abi incompatible but share some namespace (symbols, soname, |
27 |
library names, etc.) I think that's a terrible idea since that'd |
28 |
introduce runtime bugs. |
29 |
|
30 |
|
31 |
I've faced something like that recently: opencv can link to qt4 or qt5. |
32 |
but if you link a qt5 program to opencv[qt4] it'll fail in terrible |
33 |
ways. you'd have the same replacing qt4/qt5 by libressl/openssl. |