On 2024/06/21 15:15, kan...@gentoo.org wrote:

From: Matt Jolly <kan...@gentoo.org>

The CURL_QUIC USE_EXPAND enables us to sanely manage QUIC (RFC 9000)
backends as they are added to cURL in the future: currently there are
two supported implementations, OpenSSL and ngtcp2,  however it's likely
that other popular TLS libraries will expose QUIC APIs over time,
and that these will be eventually be supported by cURL (see CURL_SSL
for examples of TLS libraries that we support) - we may as well
get ahead of the curve here.

There are already a number of other small players (i.e. OpenSSL Forks)
exposing QUIC support for quite a while, however these have not been
available in ::gentoo and we've only needed the one USE to enable
for HTTP/3 and QUIC to this point.

Signed-off-by: Matt Jolly <kan...@gentoo.org>
  profiles/desc/curl_quic.desc | 7 +++++++
  1 file changed, 7 insertions(+)
  create mode 100644 profiles/desc/curl_quic.desc

diff --git a/profiles/desc/curl_quic.desc b/profiles/desc/curl_quic.desc
new file mode 100644
index 000000000000..372bb9ce8f83
--- /dev/null
+++ b/profiles/desc/curl_quic.desc
@@ -0,0 +1,7 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+# This file contains descriptions of CURL_QUIC USE_EXPAND flags for 
+openssl - Use OpenSSL
+ngtcp2 - Use ngtcp2

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.

Kind regards,

Reply via email to