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