Despite the fact that net-libs/glib-networking has a build option for OpenSSL, and appears to build with it enabled (and with GNUTLS disabled) just fine, the ebuild for this package has the the OpenSSL build option hardcoded as disabled, and thus forces a dependency on GNUTLS for no apparent reason. I also find it slightly odd that net-libs/glib-networking has an `ssl` USE flag which does not have any apparent impact on whether or not the package is built with SSL support, although maybe there's a good reason for that.
USE=ssl pulls in ca-certificates to ensure https stuff will actually work in practice. This could be important for cases where glib-networking ends up being used only in glib CLI apps or such, I suppose. OpenSSL is highly discouraged by upstream at this point, it was recently introduced (and thus is still a bit experimental) with the option very clearly documented as: > The OpenSSL backend is provided for systems where licensing considerations > prohibit use of certain dependencies of GnuTLS. General-purpose Linux distros > should leave it disabled. Please don't second-guess our defaults. Up to this point I have had no reason to second-guess upstreams defaults.
