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

[Alexis Ballier]

On Thu, 15 Jun 2017 19:38:48 +0200
Michał Górny <mgorny@g.o> wrote:

> On czw, 2017-06-15 at 18:07 +0200, Alexis Ballier wrote:
> > On Thu, 15 Jun 2017 17:59:13 +0200
> > Michał Górny <mgorny@g.o> wrote:
> >
> > > On śro, 2017-06-14 at 16:09 +0200, Alexis Ballier wrote:
> > > > On Wed, 14 Jun 2017 15:57:38 +0200
> > > > Michał Górny <mgorny@g.o> wrote:
> > > > [...]
> > > > > > [...]
> > > > > > > > > > > [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUse
> > > > > > > > > >
> > > > > > > > > > I really don't like the reordering thing. Even the
> > > > > > > > > > restricted syntax does not fix the issue with '^^
> > > > > > > > > > ( a b ) b? ( a )' already mentioned here. It'd be
> > > > > > > > > > much better and simpler for the spec just to assign
> > > > > > > > > > a fixed value and use the solving rules with
> > > > > > > > > > those.
> > > > > > > > >
> > > > > > > > > You're not going to convince me by providing examples
> > > > > > > > > that are utterly broken by design and
> > > > > > > > > meaningless ;-).
> > > > > > > >
> > > > > > > > Well... if it's so obvious that the example is broken by
> > > > > > > > design that you don't even bother to explain why, I
> > > > > > > > assume you have an algorithm for that. Where is the
> > > > > > > > code ? What are the numbers ? How many ebuilds might
> > > > > > > > fail after reordering ? How can this be
> > > > > > > > improved ?
> > > > > > >
> > > > > > > Are you arguing for the sake of arguing here? I just
> > > > > > > presumed that this example is so obviously broken there
> > > > > > > is no point wasting any more time on it. The code of
> > > > > > > nsolve clearly detects that, so I don't really understand
> > > > > > > what you're trying to prove here.
> > > > > >
> > > > > > Those are real questions. You should take breath, think a
> > > > > > bit about it, and try to run the 2 possible orderings of
> > > > > > the ^^ through nsolve or even solve.py. They both are very
> > > > > > happy (and are right to be) with the above ordering. You
> > > > > > might want to think a bit more about what is the relation
> > > > > > between this broken 10 chars example and the 10 lines
> > > > > > python targets one below.
> > > > > >
> > > > > > You should also realize that all the above questions have
> > > > > > already been answered in length if you do as I
> > > > > > suggest.
> > > > >
> > > > > No. I have already spent too much time on this. We're already
> > > > > long past all useful use cases, and now I feel like you're
> > > > > going to argue to death just to find a perfect algorithm that
> > > > > supports every absurd construct anyone can even write, if
> > > > > only to figure out the construct is completely useless.
> > > >
> > > > I'm not going to argue to death. It's already proven reordering
> > > > is broken.
> > > >
> > > > > If you want to play with it more, then please by all means do
> > > > > so.
> > > >
> > > > There is nothing to do for reordering. It's broken by design.
> > > >
> > > > > However, do not expect me to waste any more of my time on it.
> > > > > I've done my part, the code works for all reasonable use
> > > > > cases and solves all the problems I needed solving. If you
> > > > > want more, then it's your job to do it and solve the
> > > > > resulting issues.
> > > >
> > > > Like... writing code handling all the cases and describing how
> > > > it works ? We're past that. The only thing we're not past is
> > > > that you fail to understand it and attempt to block it.
> > > >
> > >
> > > Then please provide a single valid example that:
> >
> > app-text/wklej-0.2.1-r1 ^^ ( python_single_target_pypy
> > python_single_target_pypy3 python_single_target_python2_7
> > python_single_target_python3_4 python_single_target_python3_5
> > python_single_target_python3_6 ) python_single_target_pypy?
> > ( python_targets_pypy ) python_single_target_pypy3?
> > ( python_targets_pypy3 ) python_single_target_python2_7?
> > ( python_targets_python2_7 ) python_single_target_python3_4?
> > ( python_targets_python3_4 ) python_single_target_python3_5?
> > ( python_targets_python3_5 ) python_single_target_python3_6?
> > ( python_targets_python3_6 ) vim? ( ^^
> > ( python_single_target_python2_7 ) )
> >
> >
> > Simplified as:
> > ^^ ( a b ) c? ( b )
> >
> > (see the pattern now ? :) )
> >
> > > a. is completely 'correct' (that is, provides a valid, predictable
> > > and acceptable solution) with the default ordering O_a,
> >
> > c? ( b ) ^^ ( b a )
> >
> >
> > > b. is not 'correct' with at least one reordering O_b (assuming
> > > only
> > > > > , ^^, ?? is subject to reordering),
> >
> > c? ( b ) ^^ ( a b )
> >
> > >
> > > c. nsolve reports O_a as all good, and O_b as not good.
> >
> > I'll let you run this. It does.
> >
> > > The best way to convince me is through valid examples.
> >
> >
> > It is also easier to be convinced when you try to understand and ask
> > for clarifications instead of just rejecting without thinking :)
> >
>
> Ok, now I get your point. Not that I like it but I don't see any sane
> way around it.
>
> The question then is, how can you reliably ensure that developers will
> use the same ordering in cross-relevant packages? For example,
> consider the following:
>
>   ^^ ( provider_ssl_openssl provider_ssl_libressl )
>
> Since those providers block each other, all packages will have to have
> either openssl or libressl consistently (or another provider).

Yep that'd be a problem for things having a global impact but since
REQUIRED_USE is merely local there's not much to be done at that level
I think.

> The reordering idea was mostly addressing this. However, it just
> occurred to me it only solved some the case when user selected both
> and not the one where neither was preferred over the other.
>
> Without reordering, I think we need to enforce the specific ordering
> consistently across the tree. Any idea how to achieve that?

There will always be the case where one developer uses the implication
form with one ordering and another one the form with the other
ordering, so I don't think there would be any solution on the spec or
algorithmic side. It should rather be some policy or guideline that
aims to that. If there's too much duplication then an eclass defining
the proper order and the deps to use could be added (like python
eclasses do); we could add some repoman warning that e.g. openssl must
be preferred over libressl (e.g. there is never a 'libressl? !openssl'
nor '!openssl? libressl'  sub-implication in the implication form). For
the eclass case, it might be that one day we will want to reverse the
order, potentially breaking the solver, but hopefully your CI checks
will catch that.


Alexis.