curl: Split package to openssl, winssl and gnutls

[orgads]

openssl keeps the default name. The other packages have suffixes.

[lazka]

Why do you need this?

[orgads]

For deploying ScummVM without ca dependencies. See the complex instructions here.

[lazka]

@dscho I see git4win uses winssl and you added mutli backend support to curl some time ago (https://curl.se/mail/lib-2017-08/0118.html). Do you have any thoughts on this change? What would make your life easier (or not harder)?

[orgads]

I don't know how to fix (or test locally) clang64. It fails when linking gnutls. Is it possible to opt out some of the sub-packages on clang?

[dscho]

@dscho I see git4win uses winssl and you added mutli backend support to curl some time ago (https://curl.se/mail/lib-2017-08/0118.html).

Right. In many ways, what I did is the opposite of what this change does. My intention was to have a single package providing all SSL backends, while this PR intends to host the different SSL backends in different packages.

Do you have any thoughts on this change?

I can see how it makes more sense for MSYS2 to have the three separate packages. After all, users specify precisely what packages they want, and they can then specify which backend they want by using the appropriate package name.

The main problem I see with this is dependencees. I.e. if there is a package that depends on mingw-w64-curl (such as mingw-w64-git), and the user installs mingw-w64-gnutls, that dependencee will now have an unfulfilled dependency.

I am not familiar enough with pacman to know whether there is a correct way to specify "we have multiple alternative variants of this package; any will do as dependency of XYZ".

What would make your life easier (or not harder)?

Since Git for Windows builds its own curl packages, this PR has no impact on my life that would it either harder or easier ;-)

[orgads]

Regarding the dependency issue, it is already handled. The alternative packages have provides, which means they can serve as a dependency for packages that depend on mingw-w64-curl.

[dscho]

Regarding the dependency issue, it is already handled. The alternative packages have provides, which means they can serve as a dependency for packages that depend on mingw-w64-curl.

Thanks, for some reason I had missed that (I did see the conflicts entries in the package_*() functions, though...)

[Biswa96]

Let me solve the gnutls build issue if possible.

The gnutls issue falls under lld issues, I gave it up.

[orgads]

I don't mind. But anyway, you can always pull out the exclusions here in the same commit when you fix the gnutls build. Either way is fine with me.

[orgads]

@Biswa96 did you report to lld? From my experience, they're glad to help with reported bugs.

[Biswa96]

Nope. Experts are discussing things here https://github.com/msys2/CLANG-packages/issues/39

[orgads]

Waiting for review then. @lazka?

[msink]

Will curl-winssl package use default Windows cert store?

https://stackoverflow.com/a/37553616:

Starting with libcurl 7.71.0, due to ship on June 24, 2020, it will get the ability to use the Windows CA cert store when built to use OpenSSL. You then need to use the CURLOPT_SSL_OPTIONS option and set the correct bit in the bitmask: CURLSSLOPT_NATIVE_CA.

Or "curl with default Windows certs" should be yet another package, and separate PR?

[orgads]

Will curl-winssl package use default Windows cert store?

https://stackoverflow.com/a/37553616:

Starting with libcurl 7.71.0, due to ship on June 24, 2020, it will get the ability to use the Windows CA cert store when built to use OpenSSL. You then need to use the CURLOPT_SSL_OPTIONS option and set the correct bit in the bitmask: CURLSSLOPT_NATIVE_CA.

Or "curl with default Windows certs" should be yet another package, and separate PR?

Looks like it does. No further changes are needed.

[jeremyd2019]

I'd be willing to work on that in a follow-up pull request though, don't need to hold this up for that

[jeremyd2019]

gnutls and rtmpdump are now in staging for clang32, so it is now safe to remove the *-clang-* exclusion for the -gnutls variant. clangarm64 is also built.

[jeremyd2019]

BTW, if you rebase to master you'll get a CLANG32 CI job to verify that works.

[orgads]

Done

[jeremyd2019]

the changes LGTM technically, but I have no opinion as to their desirability

[orgads]

Time to merge?

[msink]

@jeremyd2019 ability to statically link libcurl to single executable without any .dll and certificates folder dependencies is desired for years: #436 #823 #950 #3617

[msink]

Thinking it over once more - maybe better choice was to leave packages mingw-w64-curl and mingw-w64-libssh2 (almost) as is, and just clone them to completely new packages mingw-w64-curl-winssl, mingw-w64-curl-gnutls and mingw-w64-libssh2-wincng, in separate folders and their own PKGBUILD.
It would be less potentially breaing change for build infrastructure.
But not sure here.

[orgads]

But all the build logic and version number is exactly the same. What's the point in duplicating it? This will require the maintainers to remember to update 3 different packages on every new release, or when the build script should change.

What's the advantage?

[msink]

Well, as it done now - it have to change something .ci in not tested and potentially breaking way.
With cloned packages - no need to change .ci.
But again - I'm not sure it's good idea.

[jeremyd2019]

I have no objection to this, but it's complicated enough that I leave it to a more experienced member/collaborator to review and merge.

[orgads]

ping? 7.77 is released...

[orgads]

Rebased and adapted to static/shared separation (hopefully).

[lazka]

thanks, I'll have another look shortly

[orgads]

ping?

[orgads]

Hello?

[orgads]

@lazka? Anybody else?