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

[Brian Harring]

On Thu, Apr 01, 2010 at 08:41:02AM +0100, Ciaran McCreesh wrote:
> On Thu, 1 Apr 2010 00:31:09 -0700
> > As demonstrated, that cycle is easily broken.  A lot of the cycles
> > users run into originate that way also.
>
> Congratulations. You just turned on 'build' and 'bootstrap', and turned
> off 'acl'.

Actually, I'm well aware I did.  See, if PMS wasn't developed in a 
void you'd know build, bootstrap, acl and friends were already a known 
issue with use cycle breaking.

Thing is, in checking the problem through we couldn't find a single 
instance where it was the *wrong* thing to do.

Build, boostrap, acl, etc, they're relevant only when you've got 
basically a from scratch system, or are rebuilding enough things you 
need to revert to that level.

Meaning it's the right damn thing to do- same thing the user would 
have to do.


> > 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.
>
> These are exactly the same issues that pkg_setup has. You can't block a
> useful feature simply because developers could theoretically screw
> things up by using it.

Ciaran, seriously stop lieing.  Your own words disprove this claim, 
I quote from pms/ebuild-functions.tex:

"""
The \t{pkg\_pretend} function may be used to carry out sanity 
checks early on in the install process. For example, if an ebuild 
requires a particular kernel configuration, it may perform that
check in \t{pkg\_pretend} and call \t{eerror} and then \t{die} with 
appropriate messages if the requirement is not met.

\t{pkg\_pretend} is run separately from the main phase function 
sequence, and does not participate in any kind of environment saving. 
There is no guarantee that any of an ebuild's dependencies will
be met at this stage, and no guarantee that the system state will not 
have changed substantially before the next phase is executed.
"""

It's ironic that the only example PMS can give for this functionality 
is als one that should not be implemented in pkg_pretend, but I 
digress.  Pure/simple, as I've explained repeatedly:

pkg_setup: ran just before the build of the pkg, after the pkg's 
DEPENDS are all built.  Meaning you *can* do has_version checks, 
kernel config checks, etc, because the proceeding deps are now 
satisfied.

pkg_pretend: ran before *every* *single* *build* has been ran, meaning 
the has_version check, the kernel config check, etc, all can invalidly 
die.

Had they been pkg_setup (check after DEPENDs are satisfied), the 
majority of the checks would pass, but because they're ran prior to 
DEPENDs satisfied, users will have to wind up breaking what was a 
single emerge invocation into multiple to satisfy pkg_pretend being 
wrong.


> > 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.
>
> No, VALID_USE addresses a *subset* of the issues. It's not a
> replacement for pkg_pretend.

Cherry picking the argument again.  Main != whole, meaning the 
majority reason I could see w/in council logs for supporting 
pkg_pretend was USE constraint validation.

As I've said, and as you seem to finally understand, VALID_USE isn't a 
replacement for pkg_pretend- it just replaces the *main* usage of it.


> > > 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.
>
> Simply adding VALID_USE won't let you do cycle breaking. You also need
> extensive lists of which flags for which packages can safely be toggled
> and when without breaking the system, and the only way you'll get those
> lists is if developers care enough to update their ebuilds to provide
> them.

That's one view, but sure, I'll run with it.

The thing is, *without* VALID_USE you cannot do use cycle breaking 
*period*.  executable vs data for the representation of the 
constraints (as I've spelled out for you 3 times now).

So your arguement against VALID_USE basically comes down to "it may 
not be able to do USE cycle breaking"- fine, I disagree, but whatever.  

pkg_pretend however completely disallows even *doing* use cycle 
breaking.  How in the hell is that a better next step?

~harring