I try to merge net-misc/curl[-quic], but portage errors out because of unsatisfied condition (which looks upside down): The following REQUIRED_USE flag constraints are unsatisfied: curl_quic_openssl? ( quic ) I didn't touch CURL_QUIC Reproducible: Always
version number? emerge --info? please reopen when the necessary info is added
All versions in gx86. Issue lies in REQUIRED_USE: curl_quic_openssl? ( ... quic ... ) curl_quic_ngtcp2? ( ... quic ... ) emerge --info would only add noise.
please add emerge --info before reopening the bug
Greg, please stop closing this bug for burocratic reason. Let knowledgeable people see it (or read the ebuilds or whatever).
The knowledgeable people saw it, read the ebuild and decided that you need to provided the information you were asked for. When and only when you do that reopen the bug. Otherwise there is nothing anyone can do for you given that you reconfigured something that we can't see. The RESOLVED/NEEDINFO closure is exactly for those cases where the reporter failed to provide required information.
I think Greg is asking for `emerge --info` because the curl ebuilds enable quic by default, so this indicates that you must have explicitly disabled USE=quic somewhere. (Which seems like an odd thing to do) Unfortunately, portage doesn't have the ability to automatically disable USE flags in the way you want (and I want... see bug 790422) The only currently available alternative we have today is what media-libs/mesa does -- not use REQUIRED_USE and instead ignore enabled USE flags. That makes sense for mesa for reasons I won't go into here, and I don't know if it makes sense for curl[quic]. I suppose that's a question for the maintainer. If you're explicitly disabling USE=quic somewhere, you could just also disable all CURL_QUIC options. E.g. a package.use entry like this: > net-misc/curl -quic CURL_QUIC: -*
Thank you Matt, I knew i could disable all curl_quic_*, but the whole point of the bug is that it makes no sense to choose implementation for a feature i disabled (disabled because of circular build dependencies). I thought it was a policy to ignore those implementation use-flags if feature were disabled (even if that spammed the use-flags), this is where i might have been wrong.
