From: Matt Jolly <kangie@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH 1/3] profiles/desc: add curl_quic
Date: Mon, 24 Jun 2024 12:01:00 +1000 [thread overview]
Message-ID: <e7181a64-3dc7-4cae-94e0-52988bc2da3e@gentoo.org> (raw)
In-Reply-To: <9a8a4517-0f1c-4e7c-8922-cda1823148b6@uls.co.za>
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
next prev parent reply other threads:[~2024-06-24 2:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-21 13:15 [gentoo-dev] [PATCH 0/3] net-misc/curl: add curl_quic USE_EXPAND kangie
2024-06-21 13:15 ` [gentoo-dev] [PATCH 1/3] profiles/desc: add curl_quic kangie
2024-06-21 14:41 ` Jaco Kroon
2024-06-24 2:01 ` Matt Jolly [this message]
2024-06-21 13:15 ` [gentoo-dev] [PATCH 2/3] profiles/base: make.defaults: add CURL_QUIC kangie
2024-06-21 13:55 ` Mike Gilbert
2024-06-21 13:15 ` [gentoo-dev] [PATCH 3/3] net-misc/curl: wire up live ebuild for openssl-quic kangie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e7181a64-3dc7-4cae-94e0-52988bc2da3e@gentoo.org \
--to=kangie@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox