Arch Linux

So many reasons not to do this yet, but the 2 biggest reasons that come to mind are:

- http2 has no finalized spec (and won't for at least another year)
- nghttp2 has no release (probably related to the former)

Feel free to compile in support on your own, but this will not be making an appearance in the [core] package until the dust around http2 has settled and it's used for more than experimentation on the greater web.

http2 is now finalized and nghttp2 landed in [extra]

Would require nghttp2 in [core], not in [extra]...

Dave, what is the criteria for nghttp2 to be added to [core]?

I am fine with moving nghttp2 to [core] and can do it myself. Are there any other obstacles with nghttp2?

I've been using curl with nghttp2 support for a while and it seems work fine.

If we add HTTP2 support to this package this means nghttp2 will become hard dependency of curl package. Everyone who uses curl (i.e. almost every Arch user) has to download it. It is additional 0.44M of network bandwidth plus 1.75M disk space for unpacked files.

If additional dependency for curl is not a problem then I am +1 for enabling HTTP2 in curl.

I would love to see support for this land. I have a sufficiently spacious enough system that the extra dependency and bandwidth does not affect me in the slightest. However, I recognize that not all Arch users are in a similar position. I am sure you have considered this and have not brought it up because of the obvious drawbacks; but, if it really is a significant issue, there could be two curl packages, one with nghttp2 support compiled-in and the other without both providing 'curl' so that either will satisfy all current dependencies (à la, how vim used to be packaged).

Again, I recognize this is not ideal, but if that is what it takes to get this into [core], I would support it (recognizing that I am not a Dev or a TU, and thus my say carries little to no weight).

* libcurl only uses libnghttp2 for framing.

* libnghttp2 can be built alone without apps/tools. It actually builds successfully in a clean chroot (with only base and base-devel). No extra dependencies from "extra" or "core" are required.

The x86-64 package built with the simple PKGBUILD attached sizes 0.12MiB compressed, 0.43MiB uncompressed.

I would love to see curl with enabled http/2 support, but I can see that nghttp2 comes in at some weight. If it works without tools why not split the package into 'nghttp2' in [core] and 'nghttp2-tools' in [extra]? Of course, it has to be verified if apache (currently the only package that depends on nghttp2) works with just the library.

What needs to be done to expedite this process and reach a decision?

nghttp2 and its dependencies would need to be added to [core]. As far as I can tell, that means:

- nghttp2
- jemalloc
- libev
- jansson
- libxml2

An alternative would be to carry a separate curl package in extra or community with http2 support, but I wouldn't really condone this.

3 years old bug? wtf??? mainteiners you should use debian or centos and go away! Stop burying my lovely distribution!

atommixz, with that kind of attitude, maybe you're the one that needs to go away.

solution https://aur.archlinux.org/packages/curl-http2/

> An alternative would be to carry a separate curl package in extra or community with http2 support, but I wouldn't really condone this.

Why not add a minimal libnghttp2 package in core, and update nghttp2 with the appropriate conflicts/provides/replaces?

Let's not celebrate this bug's 3d anniversary, shall we?

I opened a bug report in nghttp2 https://bugs.archlinux.org/task/52164 to create spit packages.

I agree with MoSal that the dependencies are all unnecessary for curl, but creating a sole "minimal package" of nghttp2 with just the library and conflicting dependencies would probably complicate things for other users, who need the full nghttp2 toolset.

> but creating a sole "minimal package" of nghttp2 with just the library and conflicting dependencies would probably complicate things for other users, who need the full nghttp2 toolset.

Rehashing what I already wrote more verbosely, just to make my suggestion clearer.

What I'm suggesting is a minimal "core/libnghttp2" package curl can depend on without dragging other dependencies with it.

"extra/nghttp2" users shouldn't even notice (let alone get confused about) anything. Because their updated nghttp2 package will have "provides=(libnghttp2=$pkgver)".

An alternative would be to delete libnghttp2 from "extra/nghttp2". And make the tools depend on "core/libnghttp2".

Due to the lack of HTTP/2 support in curl I was trying to use nghttpx as test client, but that recently broke too due to missing c-ares ( FS#52318 ).
 FS#52164  got closed because nghttp2 would have to end up in core. Is that the only problem, or is the dependency on jemalloc, etc. also undesired?

wrt  FS#52164  - splitting nghttp2 into library and binaries package sounds reasonable. The reason why it is closed is that we want to put libnghttp2 into [core] and nghttp2 into [extra], but currently there is no way to put parts of a split package into different repositories. Thus both split packages need to go to [core] anyway.

@Anatol I have requested re-opening  FS#52164  (splitting into a libnghttp2 and nghttp2 programs package). Split packages reduce the dependencies that have to be pulled in at installation time. Is it allowed to have packages in -core that depend on extra? Normally you would not install "nghttp2" if you just have core enabled, but "libnghttp2" (as dependency of curl).

libnghttp2 is in testing as a standalone package. It's built from a standalone PKGBUILD now so curl can depend on it.

A reminder that libnghttp2 has been in core for sometime.