Hi Jaco,
May I suggest simply calling this USE_EXPAND QUIC_IMPL so that other
packages can potentially re-use as well?
looking through ::gentoo at least net-dns/dnsdist and net-dns/knot also
has a quic support, using ngtcp2 and/or net-libs/quiche.
With openssl 3.2 hopefully approaching stable at some point I suspect
the number of projects that will be adding quic support via one or
another channel (possibly with alternative implementations) will only
increase, thus pinning the USE_EXPAND on a single package seems
potentially short-sighted.
My knee-jerk response was to claim that cURL is unique in the
number of backends supported (and way that it tends to support
configuring for multiple implementations at once), but then I took the
time to look at the various TLS USE flags for things like web servers
and I've warmed up to the suggestion.
I can certainly see some benefit to having a generic USE_EXPAND that
covers QUIC implementations (and maybe one for TLS impls?). We could
probably replace CURL_SSL and CURL_QUIC with the generics, though I'd
still need to retain the existing global USE that this would deprecate
(at least as local USE in net-misc/curl) as the current ebuild logic
relies on both USE and USE_EXPAND for TLS implementation selection.
I'm interested in hearing some other opinions though - is there some
reason this hasn't already been done?
The alternative (doing nothing) still seems appealing given that OpenSSL
seems likely to remain the 'default' implementation as QUIC adoption
rises, and the existing USE (and profile) settings have proven
sufficient (and not too confusing) so far.
Ideally, if the generic USE_EXPAND option is pursued I imagine that
we would want to hit all of the ebuilds (etc) at once and ensure that
an appropriate news item concerning the migration has been distributed.
There's nothing stopping us from implementing this solution as a
separate change that doesn't block the cURL updates while we decide
whether one (or more) generic USE_EXPAND variables make sense.
Thanks,
Matt
