Re: [gentoo-dev] pkg_pretend USE validation and VALID_USE alternative

[Brian Harring]

On Wed, Mar 31, 2010 at 08:56:28PM +0100, Ciaran McCreesh wrote:
> On Wed, 31 Mar 2010 12:46:26 -0700
> Brian Harring <ferringb@×××××.com> wrote:
> > Actual name I don't hugely care about, I'm more interested in
> > ensuring we don't rule out doing use cycle breaking via a bad design
> > decision.
>
> Cycle breaking requires explicit instructions from the ebuilds in
> question (many of which are system things, which further complicates it)
> along with support from Portage, so it's a distant future, lot of work
> thing.

Nonsense.  Note I said 'use cycle', not the generic 'cycle breaking'.  
USE induced cycles don't require explicit instructions from the 
ebuild at all- the PM itself can search the solution space (toggling 
flags as needed) to search out a way around the cycle.

Consider user configuration w/ USE=X, pkg_a w/ DEPEND "X? ( pkg_b )", 
pkg_b w/ DEPEND "pkg_a".  To be clear, you're claiming that the 
ebuild itself (and only the ebuild) is the the one able to state-

emerge pkg_a[-X]
emerge pkg_a[X]

As demonstrated, that cycle is easily broken.  A lot of the cycles 
users run into originate that way also.

Reiterating a point you're missing also, any use cycle a user hits is 
currently requires the *user* to sort it out anyways- what VALID_USE 
adds is the ability for the package manager to do it itself.

As for the "portage is developmentally slow" contribute frankly- per 
the norm w/ open source, you want something, ultimately you're the one 
responsible for the work.

Less contentious answer, I've already gotten an estimate of 2 weeks 
out of Luther (the person who has been knocking out EAPI4 features in 
the last month or so)- I'm not that concerned about it.  Actual work 
is a few days, motivation per the norm is the main time sink.


> Since we need pkg_pretend to cover all the things that aren't use flag
> related anyway, it makes sense to just go with that rather than
> delaying things even further.

And as I've already laid out in the bug, pkg_pretend has it's own set 
of issues when compared to pkg_setup due to it being non temporal, 
thus having high false positive potentials.

The main council push for pkg_pretend was to move use constraint 
checking to pre build.  VALID_USE does that cleaner and enabling use 
cycle breaking to be built; as such I'm pushing it up to them unless 
someone can find significant *real* flaws.

Soo... as I've described on the bug and here (repeatedly), exempting 
5-10 cases from the tree, what pkg_pretend enables can either be done 
better via VALID_USE, or is a degradation due to temporal concerns 
when you move the code out of pkg_setup.

Short version: it's a step backwards.


> When in the distant future Portage
> becomes able to deal with cycle breaking, ebuilds can be converted to
> use something like VALID_USE when they're also updated to export
> information on which of their flags can safely be toggled.

You're being short sighted.  VALID_USE is useful now for representing 
use states that are allowed; that data itself is useful for use cycle 
breaking.  Added bonus of enabling better functionality via a superior 
solutions, basically.


~harring