On Mon, 29 May 2017 17:33:13 +0200 Michał Górny <mgo...@gentoo.org> wrote:
> Hello, > > For a long time we seem to be missing appropriate tools to handle USE > flag constraints efficiently. EAPI 4 brought REQUIRED_USE but all > things considered, it has proven to be far from an optimal solution. > I would therefore like to discuss adding a better tool to amend or > replace it, to allow for automated handling of USE flag constraints. This has been discussed in the past and I'm basically all for it. Some more detailed comments below. [...] > 2. Specification > ================ > > 2.1. Forced USE flag constraints > ================================ > > This proposal introduces USE flag constraints that are meant to be > solved automatically by the package manager. This is somewhat similar > to REQUIRED_USE, except that it does not require the user to take any > explicit action. In that regard, it is closer to conditional > package.use.force/mask. > > In the basic form, it can be used to conditionally force a specific > flag to be enabled or disabled. For example: > > foo? ( bar ) > > would mean that the bar flag is implicitly enabled (forced) if foo is > enabled as well. Appropriately: > > foo? ( !bar ) > > would mean that the bar flag is implicitly disabled (masked) in that > case. All good here. > It can also be used with multi-flag ??, ^^ and || constraints, i.e.: > > - ?? means that at most one of the flags can be enabled. If user > configuration causes more than one of the flags to be enabled, > additional flags are implicitly disabled (masked) to satisfy > the constraint. > > - || means that at least one of the flags must be enabled. If user > configuration causes none of the flags to be enabled, one of them is > enabled implicitly (forced). > > - ^^ means that exactly one of the flags must be enabled. The behavior > is a combination of both above constraints. > > The automated solving of USE constraints would require the developers > to consider the implicit effect of the constraints they are writing. Can you provide an efficient algorithm for the above syntax? That is, given a set of +/- useflags forced by user, output the set of effective useflags (or a rant if it is inconsistent). Maybe I'm mistaken, but I doubt it is possible with n-ary constraints. Now the extra question: Do those n-ary operators have any advantage ? The point is to express some preference, below you suggest to leave that to the user, but what about leaving that to the ebuild developer? That way, e.g., || can be rewritten as implications: '|| ( a b c )' becomes '!b? !c? a' meaning if none is enabled then a is automatically enabled. Note that with only unary constraints, computing the set of effective useflags becomes trivial (linear in the # of useflags + constraints): take the constraints as a list, solve the first one, add its consequences (if any) to the set of forced useflags, continue with next constraint or rant if the set of forced flags is inconsistent. > 2.2. UI implications > ==================== [...] I really like that part. It becomes even simpler with only unary constraints :) [...] > 2.4. Backwards compatibility > ============================ > > Before choosing the exact way of implementing this, we need to answer > how far we want to provide backwards compatibility. In particular: > > a. Do we need the REQUIRED_USE requiring explicit user selection? Or > can we rely completely on other solutions (automatic solving, > pkg_pretend())? > > b. Would changing REQUIRED_USE behavior in place cause unintended side > effects? Are we going to accept those effects until the packages are > fixed? (e.g. selecting less preferred solution of constraint) I would prefer changing REQUIRED_USE in a new EAPI. We definitely do not need a new variable, REQUIRED_USE is good enough, but PMS has been vague enough not to define that so we can't assume the selection of auto-enabled useflags will be what was meant rather than something completely stupid. I'm even more inclined towards changing that in a new EAPI since using the current REQUIRED_USE syntax seems to introduce yet another exponential algorithm in the critical path of 'emerge -uDN world'... [...] > 2.5. Ebuild interface > ===================== > > This section is most flexible as I don't really care how it's done, > as long as it's done. Depending on our preferences, and the answers to > questions in the preceding section, the options include: > > 1. changing behavior of REQUIRED_USE retroactively -- i.e. making > Portage start solving USE constraints automatically, and being able to > rely on that a few months from now, > > 2. changing behavior of REQUIRED_USE in a future EAPI, > > 3. adding ENFORCED_USE with the new behavior in a future EAPI > (and either keeping or removing REQUIRED_USE), > > 4. adding special syntax to REQUIRED_USE to indicate which constraints > can be solved automatically, > > 5. adding special syntax to IUSE to indicate which flags can be > enabled or disabled automatically via REQUIRED_USE (a little > different from the exact proposal), > > 6. adding a dedicated variable to indicate USE_EXPAND sets that can be > solved automatically via REQUIRED_USE (partial solution). In that order: 2 1 4 _reopen_nominations 3 5 6 [...] > 4. Comments > =========== > > What do you think? +1 Alexis.
