If the usage of tls implementations is gnutls over ssl over nss like the ebuild says, we need nss? ( !gnutls !ssl ) and also ssl? ( !gnutls !nss ) and gnutls? ( !nss !ssl ). Probably this also doable with ^^( gnutls ssl nss), but I am not sure whether this is a 0 or 1 implementation or exactly 1. Otherwise the user gets fooled with any USE combination of gnutls ssl nss.
(In reply to comment #0) > If the usage of tls implementations is gnutls over ssl over nss like the > ebuild says, we need nss? ( !gnutls !ssl ) and also ssl? ( !gnutls !nss ) > and gnutls? ( !nss !ssl ). Probably this also doable with ^^( gnutls ssl > nss), but I am not sure whether this is a 0 or 1 implementation or exactly 1. > Otherwise the user gets fooled with any USE combination of gnutls ssl nss. It is exactly 1. You can't have multiple. So, as the ebuild says: RDEPEND=" gnutls? ( ... ) ssl? ( !gnutls? ( ... ) ) nss? ( !gnutls? ( !ssl? ( ... ) ) ) " if two or more of those flags are given, then prefer gnutls over ssl, and prefer ssl over nss. However, as you said, the user can be fooled regarding what she's getting. It would be possible to expand REQUIRED_USE to address this as follows: REQUIRED_USE=" gnutls ( !ssl !nss ) ssl ( !nss !gnutls ) nss ( !gnutls !ssl ) " At least then the user would get an error message if passing more than one. It should then be possible, as you suggest, with just RDEPEND=" gnutls? ( ... ) ssl? ( ... ) nss? ( ... ) " The only information "lost" is the preference gnutls > ssl > nss. If this turns out to be important (and I don't think it is) we can always einfo the user about the preference. Okay. I'll play with this and if it works as desired, I'll put it up without a rev bump. Thanks for the report. I was aware of the issue, but ... well ... laziness :)
> nss), but I am not sure whether this is a 0 or 1 implementation or exactly 1. Oh sorry, I misinterpreted this statement. It is 0 or 1. 0 means no ssl encryption. So you don't need the (gnutls ssl nss) in REQUIRED_USE. Its as I just posted. One minor mistyping though, just to be clear: it should be "gnutls? ( !ssl !nss ) ... " in the REQUIRED_USE, with a ?. I forgot that and of course it makes a difference.
Okay committed. Take a look and if there are no problems, let's close this bug.
Thanks, that was my idea of the fix. My 0/1 question was regarding ^^ ( foo bar ). But it is exactly 1 out of "foo bar" but not none.
What about backporting this fix? All ebuilds are EAPI=4 and they should all suffer from this bug. Big problem is that cmake depends on curl[ssl] which is not necessarily fullfiled because the old way of curl allows having USE="gnutls ssl" enabled, like it was on my system, but only the gnutls support will be build then but not the ssl one. @kde Doesn't this mean, cmake is fine with either gnutls or ssl support in curl? Because on my system curl wasn't built with ssl but gnutls support and cmake worked and installed fine.
(In reply to comment #5) > What about backporting this fix? All ebuilds are EAPI=4 and they should all > suffer from this bug. > Big problem is that cmake depends on curl[ssl] which is not necessarily > fullfiled because the old way of curl allows having USE="gnutls ssl" > enabled, like it was on my system, but only the gnutls support will be build > then but not the ssl one. > > @kde > Doesn't this mean, cmake is fine with either gnutls or ssl support in curl? > Because on my system curl wasn't built with ssl but gnutls support and cmake > worked and installed fine. Okay I can, but since curl-7.24.0 has been marked stable on many arches, I think that I should rev bump to curl-7.24.0-r1. I don't see that this would break anything but just in case.
Do we need to bump? I think portage should scream, if it is installed.
(In reply to comment #7) > Do we need to bump? I think portage should scream, if it is installed. Okay, its in without a rev bump. Portage *will* now scream.
(In reply to comment #8) > (In reply to comment #7) > > Do we need to bump? I think portage should scream, if it is installed. > > Okay, its in without a rev bump. Portage *will* now scream. Okay this was not a good approach and was reverted. See bug #410369 for more details.
Portage *is* screaming. Some packages like liboauth are still depending on net-misc/curl[ssl,nss,-gnutls] -- which is impossible.
(In reply to comment #10) > Portage *is* screaming. Some packages like liboauth are still depending on > net-misc/curl[ssl,nss,-gnutls] -- which is impossible. This should be okay now.
So what is now the reccomended use for this? I currently have Final environment Use flags: +ares, +idn, +ipv6, +kerberos, +ldap, +nss, +ssl, -gnutls, -ssh, -static-libs, -test, -threads
Linux1 ~ # emerge --pretend --update --deep --newuse @system @world These are the packages that would be merged, in order: Calculating dependencies * waiting for lock on /var/db/.pkg.portage_lockfile ... [ ok ] ... done! WARNING: One or more updates have been skipped due to a dependency conflict: net-misc/curl:0 (net-misc/curl-7.25.0-r1::gentoo, ebuild scheduled for merge) conflicts with net-misc/curl[ssl,nss,-gnutls] required by (net-libs/liboauth-0.9.6::gentoo, installed)
(In reply to comment #12) > So what is now the reccomended use for this? > I currently have > > Final environment Use flags: +ares, +idn, +ipv6, +kerberos, +ldap, +nss, > +ssl, -gnutls, -ssh, -static-libs, -test, -threads Because of the growing number of ssl providers, I broke them out into their own use expand flag. Given your old flags, you now want USE="ares idn ipv6 kerberos ldap ssl -threads" CURL_SSL="nss" I just tested and it builds fine.
(In reply to comment #13) > Linux1 ~ # emerge --pretend --update --deep --newuse @system @world > > > > These are the packages that would be merged, in order: > > > > Calculating dependencies * waiting for lock on > /var/db/.pkg.portage_lockfile > > ... > [ ok ] > ... done! > > > > WARNING: One or more updates have been skipped due to a dependency conflict: > > > > net-misc/curl:0 > > (net-misc/curl-7.25.0-r1::gentoo, ebuild scheduled for merge) conflicts > with > net-misc/curl[ssl,nss,-gnutls] required by > (net-libs/liboauth-0.9.6::gentoo, installed) See bug #412343
Could you please put a working solution here for the package.use file, I am not familiar with using use flag subsets and am having trouble setting this Thanks
here is what I did net-libs/liboauth -nss net-misc/curl ares idn ipv6 kerberos ldap ssl -threads CURL_SSL="openssl%* -axtls% -cyassl% -gnutls% -nss% -polarssl%" is this correct? this is with the modified liboauth ebuild
