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