[MacPorts] #65056: curl: Enable http2 by default (was: Enable http2 by default)

MacPorts noreply at macports.org
Sat Apr 23 02:03:25 UTC 2022


#65056: curl: Enable http2 by default
--------------------------+------------------------
  Reporter:  dgilman      |      Owner:  ryandesign
      Type:  enhancement  |     Status:  accepted
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  curl         |
--------------------------+------------------------
Changes (by ryandesign):

 * status:  new => accepted
 * owner:  (none) => ryandesign


Old description:

> Please enable the http2 variant by default. http2 is common enough that
> in the past year I've had to recompile with +http2 twice to test stuff
> out. There is even a HTTP 3 now.
>
> I also note that [Debian is shipping
> curl](https://packages.debian.org/unstable/libcurl4) built with nghttp2,
> brotli, zstd, libssh2, librtmp, openldap, and even gssapi. I think it's
> worth reviewing that list to see what else should be built by default. In
> my opinion anything Debian is shipping is going to be considered an
> effective default for any distribution.

New description:

 Please enable the http2 variant by default. http2 is common enough that in
 the past year I've had to recompile with +http2 twice to test stuff out.
 There is even a HTTP 3 now.

 I also note that [https://packages.debian.org/unstable/libcurl4 Debian is
 shipping curl] built with nghttp2, brotli, zstd, libssh2, librtmp,
 openldap, and even gssapi. I think it's worth reviewing that list to see
 what else should be built by default. In my opinion anything Debian is
 shipping is going to be considered an effective default for any
 distribution.

--

Comment:

 Just to set your expectations, I don't generally look at what Debian or
 another package manager enables in their packages, and I don't know if any
 other MacPorts maintainers do that.

 I don't know how Debian's packages work. I don't know if they have a
 concept like MacPorts variants which let the user choose which features to
 enable. If they don't, that would be a good justification for them
 enabling many features automatically, whereas in MacPorts it's a good
 reason not to, since not all users need all features and some of them come
 with a lot of dependencies.

 I'm happy to enable http/2 support unconditionally since http/2 is
 mainstream now, even though I would not expect the lack of http/2 support
 to have caused many problems since I would expect servers that support
 http/2 to still support http/1.1 as well, although maybe I'm out of date
 with that expectation.

 http/3 appears not to be final yet. [https://curl.se/docs/http3.html
 curl's support for http/3] appears to be experimental. Looks like it could
 use any of several different libraries for http/3 support, none of which
 are in MacPorts yet, I think. If you want http/3 support in MacPorts curl,
 we'd have to add at least one of those ports first. Let's table that until
 later. Feel free to file another ticket for that, or to submit tickets or
 pull requests for any of those needed dependencies.

 I'm happy to add brotli compression support to curl since that's also
 gained mainstream acceptance. The curl port already has zstd compression
 support enabled unconditionally.

 libssh2, openldap, and gssapi support seem more esoteric to me,
 justifiably hidden in non-default variants. The gss variant has a comment
 explaining that it requires macOS gss, not MacPorts gss, and therefore it
 declares a conflict with the MacPorts gss and kerberos5 ports. If we
 enabled that variant by default (or enabled that feature unconditionally
 without a variant) it would cause an inconvenience for users who also had
 the gss or kerberos5 ports installed every time they wanted to upgrade the
 curl port -- at least those users who did not receive binaries from us.

 librtmp support also seems esoteric, to the extent that there hasn't even
 been a variant for it in the curl port and I'm not aware of anyone having
 mentioned it before you. I can certainly add a variant for it.

-- 
Ticket URL: <https://trac.macports.org/ticket/65056#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list