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

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4666 bytes --]

On pią, 2017-06-02 at 13:18 +0200, Alexis Ballier wrote:
> On Fri, 02 Jun 2017 08:37:30 +0200
> Michał Górny <mgorny@gentoo.org> 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@gentoo.org> 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.

For the xinerama rule, you may prefer the opposite rule, i.e.:

  !X? ( !xinerama )

If you did so, I can't think of a way to express it correctly while
preserving full allowance of reshifting ||. So yes, we'd lose too much.

One thing we lose is the ability to clearly check whether the constraint
'makes sense'. Previously, we could (at least theoretically) check
whether it has a single solution and complain otherwise. With left-to-
right, I don't see any way to tell the developer 'something stupid is
going to happen now, you probably meant something else'. But I guess
that's still an improvement over what we have now.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 988 bytes --]