| 1 |
On Fri, Jan 18, 2019 at 09:13:34PM +0100, Michał Górny wrote: |
| 2 |
> Firstly, it is confusing to developers. Let's analyze the dependencies |
| 3 |
> on dev-libs/openssl. A quick grep reveals seven patterns. They are |
| 4 |
> listed below, along with occurrence counts and percentages: |
| 5 |
> |
| 6 |
> dev-libs/openssl 278 7.8% } |
| 7 |
> dev-libs/openssl:* 49 1.4% } 14.2% |
| 8 |
> dev-libs/openssl:= 178 5.0% } |
| 9 |
> dev-libs/openssl:0 660 18.6% |
| 10 |
> dev-libs/openssl:0= 2381 67.0% |
| 11 |
> dev-libs/openssl:0/0 4 0.1% |
| 12 |
> dev-libs/openssl:0/1.1 2 0.1% |
| 13 |
This was based just on ebuilds right? |
| 14 |
|
| 15 |
> So apparently 14.2% of dependencies allow any slot of OpenSSL which is |
| 16 |
> most likely wrong, and 1.4% explicitly claim that's what the package |
| 17 |
> wants. This could be valid only if e.g. the package supported multiple |
| 18 |
> ABIs of OpenSSL libraries and used dlopen() with a few possible SONAMEs |
| 19 |
> which I honestly doubt any of those packages is doing. |
| 20 |
There's a valid case for accepting ANY openssl: tooling that explicitly |
| 21 |
calls the binary tools provided by OpenSSL, and does link or dlopen any |
| 22 |
of the openssl libraries. |
| 23 |
|
| 24 |
Such usage has to be careful, because it could depend on OpenSSL |
| 25 |
compile-time options, like 'srp', which used to depend on USE=bindist. |
| 26 |
|
| 27 |
Your solution however will also improve this case. |
| 28 |
|
| 29 |
-- |
| 30 |
Robin Hugh Johnson |
| 31 |
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer |
| 32 |
E-Mail : robbat2@g.o |
| 33 |
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 |
| 34 |
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 |
Archives