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

[Michał Górny]

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.
>
> That is the whole problem I was signaling, and which I seem to have lost
> sight of: solving is trivial, ensuring that the constraint can have only
> one solution isn't. Hopefully, most of the simple constraints in use
> will 'just work'.
>
> 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).

-- 
Best regards,
Michał Górny