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
pgpWNI1A4NRYN.pgp
Description: PGP signature
