Created attachment 527244 [details, diff] multi backend patch It'd also make hacks like this less of a hack (I think) https://github.com/anyc/steam-overlay/blob/master/net-libs/libcurl-debian/libcurl-debian-4.ebuild
I first looked at the curl configure.ac file, which didn't seem to preclude multiple backends (though we can define a default if we wish). Then I just google'd around, https://curl.haxx.se/mail/lib-2017-08/0120.html was found. https://curl.haxx.se/libcurl/c/libcurl-env.html shows the envvar that's used to define the backend you want to use.
(In reply to Matthew Thode ( prometheanfire ) from comment #1) > I first looked at the curl configure.ac file, which didn't seem to preclude > multiple backends (though we can define a default if we wish). Then I just > google'd around, https://curl.haxx.se/mail/lib-2017-08/0120.html was found. > https://curl.haxx.se/libcurl/c/libcurl-env.html shows the envvar that's used > to define the backend you want to use. I'm not sure switching between backends with an envvar is such a good idea. Can you give me a use case where we would want to switch between ssl providers with an envvar?
It's not just an envvar (I think). Some things (spotify) seems to want libcurl-gnutls (at least the debian package by that name), so I think it makes sense to optionally have that machinery around to be called upon if a package requires it. It'd be nice not to have to deal with use flag conflicts. This is done via https://curl.haxx.se/libcurl/c/curl_global_sslset.html As far as using the client side and selecting the env-var, it can be useful to access the different back-end features. https://curl.haxx.se/docs/ssl-compared.html
(In reply to Matthew Thode ( prometheanfire ) from comment #3) > It'd be nice not to have to deal with use flag > conflicts. > > This is done via https://curl.haxx.se/libcurl/c/curl_global_sslset.html > right that's the advantage, but isn't it going to be a pita for users to set some global variable to make sure they get the provider they want? i haven't looked into this carefully, but i think we're going to need a better view of just what will be required of our users to implement this. none of the links you've give really answer those questions.
A defailt can either be defined via env.d or at build time with --with-default-ssl-backend=gnutls (or something).
(In reply to Matthew Thode ( prometheanfire ) from comment #5) > A defailt can either be defined via env.d or at build time with > --with-default-ssl-backend=gnutls (or something). okay but right now you don't have any of that in there. the ideal would be to have a multissl USE flag. If the flag is off, we retain the current behaviour. If its on, then we must make sure that its easy for the user to control the backends. an env.d file could do that.
the discussion on the list didn't seem to resolve anything and I'm still worried that this will introduce maintenance nightmares for people. if you come up with a clearer solutions along the lines of comment 5, with all the proper working pieces in there, then we can look at this again.
