Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Alexey Sokolov]

вт, 29 дек. 2020 г. в 13:33, David Seifert <soap@g.o>:
>
> On Tue, 2020-12-29 at 13:21 +0000, Peter Stuge wrote:
> > Michał Górny wrote:
> > > > 2.  Install them into different prefixes (eg /usr/lib/openssl +
> > > > /usr/lib/libressl and have the linker link to a specific version,
> > > > /usr/include/{openssl,libressl} too).
> > >
> > > For the record, this is something I've been wondering about for a
> > > long
> > > time.  However, there are two problems with that: a small one
> > > and a huge one.
> > >
> > > The small problem is that this requires a lot of additional
> > > downstream
> > > work.  I mean, you have to explicitly support the choice in ebuilds,
> > > and this means making things even harder for newcomers.
> >
> > pkg-config/pkgconf and .pc files can help with this part, taking care
> > of all abstraction if/when downstream uses a libressl.pc.
>
> As we have learned from the ncurses[tinfo] debacle, 80% of build systems
> don't use the .pc files, and just guess "-lssl" flags and a bunch of
> include dirs. Hence, this boils down to patching a mountain of build
> systems again, which while being the ultimately correct way, is a pipe
> dream.

If it's the ultimately correct way, such patches can be sent upstream,
regardless of whether libressl stays.

>
> > > The big problem is that (unless I'm mistaken) we won't be able to
> > > load
> > > LibreSSL and OpenSSL to the same executable.  So we'd actually have
> > > to
> > > enforce that the whole link chain links to the same SSL provider,
> > > and effectively land pretty close to where we are now.
> >
> > I'd suggest investigating whether symbol versioning could help with
> > this,
> > or if the only way forward would indeed be to require some symbol
> > mangling/rewriting.
>
> While this sounds like a theoretical solution, it isn't tractable
> because
> 1. We're inventing our own ABI that is incompatible with everyone else's
> 2. We'd have to maintain a huge swamp of downstream patches
> 3. ABI can still break even with perfect symbol versioning
>
>