On Sun, 20 Sep 2015 12:17:11 +0300
Andrew Savchenko <birc...@gentoo.org> wrote:
> 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.
Yes, that's what gnome team is doing with gtk2 vs gtk3; however, I'm
not sure how much work it is. Only package I know of providing
different slots depending on what it's built upon is webkit-gtk.
I can't imagine every library using {open,libre}ssl provide two slots,
two different libraries, two different pkg-config and the like files,
etc. And every package using a library that uses a library that uses a
library that uses {open,libre}ssl to have to chose what ssl library to
use.
