Please add gnurl to macports

[gnw3]

​http://lists.gnu.org/archive/html/info-gnu/2018-01/msg00009.html

From the README file

libgnurl is a fork of libcurl with the following major changes:

Compilation requirements:

• libgnurl must be compiled so that it supports only HTTP and HTTPS (remove Gopher, SSH, IMAP, etc.)
• libgnurl must be compiled so that it supports only GnuTLS (remove CaySSL, QsoSSL, GSKit, etc.)
• removed support for NTLM, GSSAPI, SPNEGO, LDAP, metalink, HTTP2
• We recommend to build GnuTLS with DANE support, provided by 'unbound'. This is optional.

The goal of the cURL project is clearly to support many crypto backends and many protocols. That is a worthy goal, and I wish them luck with it. The goal for libgnurl is to support only HTTP and HTTPS (and only HTTP 1.x) with a single crypto backend (GnuTLS) to ensure a small footprint and uniform experience for developers regardless of how libcurl was compiled.

[gnw3]

Portfile purloined from curl

[ryandesign (Ryan Carsten Schmidt)]

Any particular reason why we should add this? We already have a curl port and it probably works fine.

[gnw3]

Gnurl is all about the library. Libcurl is very widely used, so has become "mission critical" to life as we know it. In this system, 22 copies of libcurl.[34].dylib (but only 13 of libssl) are provided by macOS, Adobe CS, Gimp, LibreOffice, two IDL versions, Anaconda Python, and macports. Some of these are linked against /usr/lib/libssl and /usr/lib/libcrypto. On my work PC, 13 copies are provided by Msys, Gimp, McAfee, Notepad++, MATLAB, ArcGIS, Esri, QGIS, and IDL. A multi-user linux system has copies in several scientific applications installed by users, Anaconda Python, and both libcurl.so and libcurl-gnults.so. Ubuntu linux offers libcurl-openssl, libcurl-gnutls, and libcurl-nss "flavours" of openssl, but the -dev packages conflict, so you can only do development with one flavour.

Libcurl has rarely used "features" (support for a many different SSL librtaries and rarely used protocols) that can only degrade reliability and security. The gnurl fork was created to provide "libcurl-light":

$ ls -l /opt/local/lib/lib*url*.?.dylib
-rwxr-xr-x  1 root  admin  418208 24 Jan 07:14 /opt/local/lib/libcurl.4.dylib
-rwxr-xr-x  1 root  admin  310720 31 Jan 14:08 /opt/local/lib/libgnurl.4.dylib

By changing the name but keeping the API, libcurl (usually built on openssl) can coexist with libgnurl for both development and runtime. At this stage, the main reason to have gnurl in macports is to allow other ports that use libcurl to provide a libgnurl variant. For GNU projects this should only require adding support for configure arguments. Going forward, if libgnurl gains traction it will become the default for many GNU applications.

[ryandesign (Ryan Carsten Schmidt)]

I hate forks. If there's a bug in curl, report it to the developer of curl so it can be fixed; don't fork curl and call it something else. I'm not wild about the idea of offering a competing libcurl implementation, for the same reason that I'm not wild about offering an alternative openssl implementation; see #54744 for the havoc that offering libressl has caused.