| 1 |
On Sun, 20 Sep 2015 12:17:11 +0300 |
| 2 |
Andrew Savchenko <bircoph@g.o> wrote: |
| 3 |
|
| 4 |
> On Sun, 20 Sep 2015 10:22:59 +0200 Alexis Ballier wrote: |
| 5 |
> > > > My idea would be: |
| 6 |
> > > > |
| 7 |
> > > > 1. import "dev-libs/libressl" (this will block |
| 8 |
> > > > dev-libs/openssl) and introduce the global USE flag "libressl" |
| 9 |
> > > > with the following description: |
| 10 |
> > > |
| 11 |
> > > Please try to avoid such block, e.g. install libressl to a |
| 12 |
> > > separate location. This is easier to do when introducing package |
| 13 |
> > > to the tree, rather when facing large-scale blockers. Otherwise |
| 14 |
> > > one day we will face nasty bug like mutual heimdal/mit-krb5 |
| 15 |
> > > blocker[1], where foo will work only openssl, bar only with |
| 16 |
> > > libressl and users will need both. |
| 17 |
> > |
| 18 |
> > If they're abi incompatible but share some namespace (symbols, |
| 19 |
> > soname, library names, etc.) I think that's a terrible idea since |
| 20 |
> > that'd introduce runtime bugs. |
| 21 |
> > |
| 22 |
> > I've faced something like that recently: opencv can link to qt4 or |
| 23 |
> > qt5. but if you link a qt5 program to opencv[qt4] it'll fail in |
| 24 |
> > terrible ways. you'd have the same replacing qt4/qt5 by |
| 25 |
> > libressl/openssl. |
| 26 |
> |
| 27 |
> Probably slotting of opencv will help here: have both qt4 and qt5 |
| 28 |
> versions. Other distributions are being able to handle mit-krb5 and |
| 29 |
> heidmal on the same system simultaneously, so should we. Situation |
| 30 |
> with openssl/libressl, ffmpeg/libav and so on is effectively the |
| 31 |
> same: when we have couples of libraries deliberately incompatible |
| 32 |
> with each other why sharing pretty much common namespace. |
| 33 |
|
| 34 |
Yes, that's what gnome team is doing with gtk2 vs gtk3; however, I'm |
| 35 |
not sure how much work it is. Only package I know of providing |
| 36 |
different slots depending on what it's built upon is webkit-gtk. |
| 37 |
|
| 38 |
I can't imagine every library using {open,libre}ssl provide two slots, |
| 39 |
two different libraries, two different pkg-config and the like files, |
| 40 |
etc. And every package using a library that uses a library that uses a |
| 41 |
library that uses {open,libre}ssl to have to chose what ssl library to |
| 42 |
use. |
Archives