If you have a setup that strictly relies on openssl vs its SSL alternatives (nss, gnutls, etc) setting the retroachievents flag is a *hard* block for building the package because it'll force gnutls on curl, which will thereby force you to switch entirely to gnutls, and if you set these specific USE flags for curl: "openssl -ssl gnutls" (-ssl is just something for openssl) Portage will then throw a fit and suggest you use backtracking (not technically necessary, of course, but not desirable) Ideally, a compromise of this magnitude should not be required. Reproducible: Always Steps to Reproduce: 1. Build a system on OpenSSL 2. Add the "retroachievements" USE flag to duckstation 3. emerge duckstation Actual Results: Attempt to emerge will fail, forcing an SSL ultimatum the user didn't ask for Expected Results: Emerge should succeed
Not sure this is really a bug :/ Did you test it, does it actually work with curl[openssl]?
It wasn't possible to do so. The moment I enabled the retroachievements use flag, portage immediately started complaining because the flag requires gnutls but curl requires that only one SSL provider is used: it doesn't permit you to have it both ways. And if other packages don't have support for gnutls but do with OpenSSL, which they were built upon via curl (a good example is dev-cpp/coeurl::guru), you can see where that suddenly becomes an issue
Sorry about this; digging deeper, I found that curl has some explicit flags for itself that aren't mentioned on the USE flags webpage. This specific setup was required for building with retroachievements: openssl gnutls -nss -curl_ssl_mbedtls -curl_ssl_nss -curl_ssl_openssl -curl_ssl_rustls
