Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Alexis Ballier]

On Fri, 02 Jun 2017 08:37:30 +0200
Michał Górny <mgorny@g.o> wrote:

> On czw, 2017-06-01 at 23:31 +0200, Michał Górny wrote:
> > On czw, 2017-06-01 at 10:55 +0200, Alexis Ballier wrote:
> > > On Wed, 31 May 2017 21:02:24 +0200
> > > Michał Górny <mgorny@g.o> wrote:
> > >
> > > > On śro, 2017-05-31 at 19:39 +0200, Alexis Ballier wrote:
> > > > > > >  Again, you *need* to process the constraints in order.
> > > > > > > '!a? ( b ) !b? ( a )' is not deterministic when none of a
> > > > > > > and b are enabled otherwise.
> > > > > >
> > > > > > You can't rely on any particular order of constraints,
> > > > > > especially when eclass stacking comes into play. You could
> > > > > > try defining some constraint- sorting algorithm but it's
> > > > > > going to be complex and it's usefulness will be limited
> > > > > > anyway due to various kinds of grouping.
> > > > >
> > > > >
> > > > > Better have some order: If half of the above constraint comes
> > > > > from ebuild and the other half comes from eclass, then PM
> > > > > might toggle 'a' or 'b' depending on the phase of the moon
> > > > > which is specifically what we're trying to avoid.
> > > >
> > > > No, it can't. That's the whole point. The algorithm must be
> > > > defined so that it is always predictable independently of order
> > > > (maybe except the ordering inside ^^, ||, ??) and independently
> > > > of how it's nested (i.e. 'a? ( b? ( c ) )' must give the same
> > > > result as 'b? ( a? ( c ) )').
> > >
> > > This is a lot of handwaving without real description of how it
> > > would work. This starts to look a lot like confluence in
> > > rewriting systems and you want developers to write only confluent
> > > rules and repoman to decide that. Good luck with that.
> >
> > I'm sorry, what I said was quite stupid. I did some thinking and
> > testing today, and the algorithm can be actually quite trivial. The
> > real issue is getting a correct input, that is REQUIRED_USE
> > constraints that have only one solution.

Don't be sorry, it's not stupid actually. There are various ways to
determinize how the constraints should be solved. Once that is defined,
one just needs to apply the rules to the constraints to get a
temptative solution, making the algorithm trivial, indeed. Depending on
how you do actually determinize the whole thing can make ensuring
uniqueness (or even the existence) of a solution quite a pain. That's
where the trade-offs between ebuild writers wishes and solving the issue
come into play. I see this long thread as a quite interesting
discussion where we're trying to converge towards something that leaves
the problem easily solvable without asking too much to ebuild writers.

[...]
> > The biggest issue for me right now is to find a way to determine
> > whether a particular REQUIRED_USE constraint can have only one
> > solution, independently of the order of non-n-ary constraints.
> > However, some of it can be easily eyeball-checked using a graph.
> >
>
> Well, I've looked at it more and you were right. While keeping them
> order-independent is a noble goal, it's not really feasible,
> especially if we assume that n-ary constraints can be reordered. So I
> think we can assume left-to-right ordering now (with multiple passes,
> if necessary).


There are ways to guarantee order-independence, your gtk+ answer in the
previous email suggests one: At most one constraint solving rule can be
applied in any situation; that's what you did by putting the ||
under !xinerama. This is a quite extreme way to ensure confluence but
that works. I've not thought too much about it but I think we'd lose
too much in expressivity though.