Re: [gentoo-dev] [RFC] Global USE=gui

[Michael Orlitzky <mjo@gentoo.org>]

On 06/07/2016 04:59 PM, Michał Górny wrote:
>>
>> I'll believe this when I see it =P
> 
> You won't because the Gentoo way is to create a shitload of hacks
> instead of fixing the root issue.
> 

I'm not arguing for anything here, I'm just toying around with an idea
for fun. What we want is a way to declare USE flag constraints within an
ebuild that,

  1) Runs quickly
  2) Prevents a package from being installed with conflicting flags
  3) Preferably has a simple grammar and doesn't require bash
  4) Outputs a sensible message to the user upon conflict

The error message is the one clear point that pkg_pretend holds over
REQUIRED_USE. If we can make portage do something sensible when it hits
a REQUIRED_USE conflict, that would be ideal. But aren't (2) and (4) the
most important points?


>>
>> So 7 minutes for an understandable English description of the error and
>> how to fix it, versus 5 minutes for line noise? There's a great story in
>> The Psychology of Computer Programming that ends like this:
> 
> Not 5 minutes. Depending on the context, Portage can complain about
> REQUIRED_USE in a few seconds because it has no further point
> in evaluating the depgraph.
> 

It doesn't do this, does it? I think it waits until the end. It *could*
run pkg_pretend earlier, too, but it doesn't.


> 
>>> 3. REQUIRED_USE can take USE dependencies into account. pkg_pretend()
>>> can't.  
>>
>> What do you mean here?
> 
> I mean that if A depends on B[gtk2], and you have ^^ ( gtk2 gtk3 ),
> Portage will clearly know gtk2 is the only solution. Your pkg_pretend()
> will tell user to enable gtk3, then Portage will hit unsolvable deps.
> Congratulations, your helpful output just resulted in even worse
> output!
> 

gtk2 is not the only solution: I could set B[gtk2] and A[gtk3] in
package.use. (If gtk2 *were* the only solution, then why would you have
the REQUIRED_USE in the first place? Just pass --with-gtk2.)

In practice, I would set A[gtk3] in package.use, and then try to emerge
it again. Portage would tell me that I needed to set B[gtk2] first, and
I would do that and start over.


>> See #2, but "each package" is an overestimate. Only the ones with a
>> non-trivial pkg_pretend() phase would take any time.
> 
> Have you tried it, or is it wild guess? What I'm saying is that
> *pkg_pretend implementation in Portage is TERRIBLY SLOW*. Even
> a complete no-op takes a lot of time because Portage needs to do a lot
> of setup to run it, and can't do multiple packages in parallel.
> 

Of course I haven't tried it =)

One of two scenarios holds, though:

 * if a trivial pkg_pretend() is slow, then one that checks for USE
   flag conflicts isn't actually that much slower.

 * if a trivial pkg_pretend() is fast, then only those packages that
   have a non-trivial pkg_pretend() make it slower.

REQUIRED_USE should be faster either way, but that's currently at the
expense of the error messages and I'm not sure those *can* be fixed.