Mike Gilbert wrote:
> > It is important to me that you can choose dev-libs/libretls instead of
> > having any libretls code on your systems, but I reject you forcing that
> > choice of yours on everyone else.
>
> I'm having trouble making sense of this sentence. Did you mean to
> write "libressl" instead of "libretls" somewhere?
Sorry, yes, that's right. "having any libressl code" is what I intended.
> Anyway, it seems like the people maintaining libressl in Gentoo are
> really not interested in keeping it going.
I don't know? There wasn't much discussion about my suggestion to keep
libressl code available in Gentoo in some ways causing no interference
with same SONAMEs openssl.
So again what I'm advocating for is creative ways to at the very least
not have to remove it completely, which I think becomes easy, by
redefining what a libressl ebuild installs for now. At the moment I'm
thinking about these two:
1. no-brainer: libtls .so with libressl implementation
2. more novel: lib{crypto,ssl} static-libs in non-standard location
with libressl.pc in default search path
> A libtls wrapper around openssl seems much more manageable to me,
> and that should probably be the default option for people.
I disagree on both points.
I'm still working on checking what 1. above requires. So far it looks like
the answer will be "nothing"; an ebuild wouldn't need any patch at all,
meaning zero overhead on bumps.
And I for one certainly expect libressl libtls to be the default - that
is the canonical upstream.
Thanks
//Peter
