Consider the case of a package supporting multiple backends or incompatible forks of libraries. Whenever there are only two choices to be considered, we can make do with a single USE flag to switch between them. It's a bit confusing on users but quite reasonable. Whenever there are at least three different choices, things get really rough. Developers either introduce N flags for N choices, or sometimes N-1 and e.g. leave out the flag for the default. Then, they either use REQUIRED_USE or (more commonly) do some implicit logic that selects one of the requested backend with no clear indication which one is actually being used. The latter solution frequently comes with horribly unreadable dependency specifications, or partially incorrect dependencies. To solve this problem, I'd like to propose an extension of the current REQUIRED_USE ||, ?? and ^^ operators with an implicit 'prefer leftmost' logic. The <|| operator ('prefer-leftmost at-least-one-of'): <|| ( A B C ... ) would mean that at least one of the flags must be selected. However, if none of the flags is selected by the user, the package manager implicitly enables the first flag specified (i.e. A in this case). The <?? operator ('prefer-leftmost at-most-one-of'): <?? ( A B C ... ) would mean that at most one of the flags must be selected. If more than one flag is selected, the left-most of the selected flags will be used and the remaining flags would be implicitly disabled. The <^^ operator ('prefer-leftmost exactly-one-of'): <^^ ( A B C ... ) would mean that exactly one of the flags must be selected. If none of the flags were selected by user, the package manager will implicitly enable the first flag specified (A). If more than one flag was enabled by the user, the package manager will use the left-most of the selected flags, and implicitly disable remaining ones. Now, for the common case of SSL/TLS backend, one could state: REQUIRED_USE="ssl? ( <^^ ( openssl libressl gnutls ) )" which would: a) clearly indicate to the user that those three flags are used to control SSL/TLS backend and which one is actually used, b) implicitly force exactly one option to be selected while respecting user preferences whenever possible, c) keep dependency specifications and logic in ebuilds simple, d) keep effective USE flag combinations low and each one of them meaningful.
I'd rather drop REQUIRED_USE in the next EAPI than complicate it further.
(In reply to Ulrich Müller from comment #1) > I'd rather drop REQUIRED_USE in the next EAPI than complicate it further. Why not drop USE dependencies as well? If you're so much into making them useless.
USE dependencies mostly work. REQUIRED_USE has completely failed at the simple task it was designed (and never tested before being shoved in at the last minute) for, and there's a perfectly good mechanism already available which doesn't have its problems.
Some people are very happy with REQUIRED_USE, and others are not so happy. For those that want to drop it from the next EAPI, I think it would be worthwhile to do conduct a poll of gentoo developer opinions on the subject.
What I find problematic with this proposal (as well as the one in bug 609338) is that it reuses the REQUIRED_USE variable for a purpose that is the opposite of what we have now. Currently the spec says: "If the package manager encounters a package version where REQUIRED_USE assertions are not met, it must treat this package version as if it was masked." Whereas what is sought here is a method to resolve such unmet assertions by switching some of the flags for the ebuild in question. So maybe it would be cleaner not to squeeze this into the existing REQUIRED_USE syntax, but (for example) introduce a new DEPEND style variable for it? (The wider scope of this is of course that if there are n USE flags and m valid package configurations, then often one will find that m < 2**n.)
Let's abandon this in favor of GLEP73 (which implies prefer-leftmost behavior anyway).
