Emerge php-5.2.1-r3 fails in pkg_setup with the following error message: * * USE flag 'recode' conflicts with these USE flag(s): * imap * * You must disable these conflicting flags before you can emerge this package. * You can do this by disabling these flags in /etc/portage/package.use: * =dev-lang/php-5.2.1-r3 -imap * !!! ERROR: dev-lang/php-5.2.1-r3 failed. Call stack: ebuild.sh, line 1630: Called dyn_setup ebuild.sh, line 702: Called qa_call 'pkg_setup' ebuild.sh, line 44: Called pkg_setup php-5.2.1-r3.ebuild, line 106: Called php5_2-sapi_pkg_setup php5_2-sapi.eclass, line 316: Called php5_2-sapi_check_use_flags php5_2-sapi.eclass, line 207: Called phpconfutils_use_conflict 'recode' 'mysql' 'imap' 'yaz' phpconfutils.eclass, line 163: Called die However, the devmanual <http://devmanual.gentoo.org/general-concepts/use-flags/> says: # Conflicting USE Flags # # Occasionally, ebuilds will have conflicting USE flags for functionality. # Checking for them and returning an error is not a viable solution. # Instead, you must pick one of the USE flags in conflict to favour.
Sorry, nothing we would fix here. We won't be choosing between two completely different functionalities; it's up to the user.
(In reply to comment #1) > We won't be choosing between two completely different functionalities; Have you read the paragraph cited from the devmanual? :-( Or, on the same page, further above: # No combination of USE flags should cause a package to fail to build. > it's up to the user. Of course the choice is up to the user, but there should be some default. It is really annoying to start an update for 100+ packages only to find later that it has stopped early due to an USE flag check.
(In reply to comment #2) > Of course the choice is up to the user, but there should be some default. It is > really annoying to start an update for 100+ packages only to find later that it > has stopped early due to an USE flag check. Sorry, there's no sane default among recode/mysql/imap/yaz. We won't be guessing what the user wants, producing potentially totally unexpected result for users. That plain doesn't make sense.
I still believe that this is a policy violation... Reopening and assigning to php herd.
Jakub is part of the PHP herd, and I fully agree with him. We already had this issue once (bug 120088), and while we know it is not optimal, it's the only real solution that satisfies us completely, we've already minimized the cases in which the die on confliciting USEs happen, and we can't do much else unless the package managers support ways to detect this before starting a merge, pretty sure there are a few bugs open about this already. ;) So, this will remain as it is, since there is no technically better solution that satisfies everyone involved at the moment (the only other option is to choose some default, build the whole thing with it and then tell the user to re-emerge it if he maybe wanted something else... and we can't choose a sensible default cause in the few cases where we still die, there is no sensible default at all (like recode VS imap/mysql, or pdo VS pdo-external)). Thanks for your concern though, best regards, CHTEKK.
Thanks for the pointer; I was not aware of bug #120088. (Obviously there is no need to resume its discussion here ...)
