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

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

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

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@gentoo.org> 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@gentoo.org> 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).

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?

-- 
Best regards,
Michał Górny

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