Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 177860 - [Future EAPI] Add pkg_pretend()
Summary: [Future EAPI] Add pkg_pretend()
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
: 75936 (view as bug list)
Depends on:
Blocks: future-eapi
  Show dependency tree
 
Reported: 2007-05-09 20:48 UTC by Petteri Räty (RETIRED)
Modified: 2011-05-28 07:53 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petteri Räty (RETIRED) gentoo-dev 2007-05-09 20:48:16 UTC
pkg_pretend would be run with --pretend on the version to be installed and the ebuilds could show output based on the current version. Useful for for example mysql && postgresql updates where one needs to dump the DB. This is in the same territory as the GLEP 42 but there are still uses for news. For example changes affecting multiple packages etc.
Comment 1 SpanKY gentoo-dev 2007-05-10 22:43:26 UTC
i dont recall seeing this discussed anywhere on gentoo-dev ?  i dont quite understand the point of the function as you've described
Comment 2 Petteri Räty (RETIRED) gentoo-dev 2007-05-10 23:11:03 UTC
(In reply to comment #1)
> i dont recall seeing this discussed anywhere on gentoo-dev ?  i dont quite
> understand the point of the function as you've described
> 

The point is to allow ebuilds to show output when a user runs emerge --pretend. I don't think it has had a dedicated thread but it pops up every once in a while in posts.
Comment 3 Ciaran McCreesh 2007-05-10 23:29:53 UTC
(In reply to comment #1)
> i dont recall seeing this discussed anywhere on gentoo-dev ?  i dont quite
> understand the point of the function as you've described

It was my proposed solution to Stuart's pretend-time conflict problem.

Comment 4 Petteri Räty (RETIRED) gentoo-dev 2009-01-31 23:45:40 UTC
Now that Portage supports DEFINED_PHASES this should be quite easy to implement efficiently. This probably does not need a new EAPI but pkg_pretend could just be added to ebuilds using existing EAPIs?
Comment 5 Ciaran McCreesh 2009-01-31 23:48:06 UTC
If it doesn't go in in a new EAPI ebuilds have to duplicate logic across pkg_pretend and pkg_setup to be sure it's done.
Comment 6 Petteri Räty (RETIRED) gentoo-dev 2009-02-01 11:13:34 UTC
(In reply to comment #5)
> If it doesn't go in in a new EAPI ebuilds have to duplicate logic across
> pkg_pretend and pkg_setup to be sure it's done.
> 

Well that would be just be a minor inconvenience but zmedico pointed out that:
01:46 < zmedico> well, if you don't bump the EAPI, you can't trust existing DEFINED_PHASES cache
Comment 7 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2009-02-01 17:07:38 UTC
How does this relate to pkg_depcheck() proposed in bug 75936 ? Would this pkg_pretend() function only display stuff or can do dependency-resolution-time checks and die too? Will it run only with --pretend or always?
If not, do we need two different functions?
Comment 8 Ciaran McCreesh 2009-02-01 17:16:23 UTC
They're the same thing. pretend's just a more general name.
Comment 9 Ciaran McCreesh 2009-06-29 18:32:32 UTC
*** Bug 75936 has been marked as a duplicate of this bug. ***
Comment 10 Brian Harring gentoo-dev 2010-03-31 07:35:27 UTC
Not sure how this slipped in, but this *really* should be removed.

The only scenario where this can be properly used is checking use configuration for the target pkg; as stated in this bug, mysql || postgres.

That's the *only* instance I can come up w/ where pkg_pretend won't invalidly crap out, and that can be addressed via adding a new metadata key that specifies allowed USE states.

VALID_USE="^^ ( mysql postgres )"

Roughly, that adds a ^^ xor operator; from there, basically the same constraint machinery used for dependency handling can be used to verify that the state is either matchable or not.

VALID_USE="gtk? ( x11 ) build? ( !gtk !x11 !random-crazy-linkages !python )"

Is a slightly more complex example.  Admittedly the syntax can get ugly during deep constraint specification, but it's also a helluva lot less likely to be accidentally misused like the hair-trigger nuke that is pkg_pretend.

@ciaran, I'm fairly sure you've seen this proposal also (it was leveled at the same time as yours during stuarts php mayhem), so counter arguments to the rough VALID_USE approach proposed above would be useful.

Additionally, if you've got *any* examples of pkg_pretend usage that are real world and not sensitive to the build steps itself, please enumerate them.
Comment 11 Ciaran McCreesh 2010-03-31 07:45:51 UTC
VALID_USE addresses a small subset of what we're trying to solve here. Yes, in certain situations it is nice, but as we're limited by how long it takes Portage to implement something, we've had to stick with the single most general option for this.
Comment 12 Brian Harring gentoo-dev 2010-03-31 07:53:53 UTC
(In reply to comment #11)
> VALID_USE addresses a small subset of what we're trying to solve here.

I asked you to please spell out other usages of it that aren't addressed by the VALID_USE alternative.

Preferably ones that won't invalidly false positive like the kernel configuration check that is given as an example in PMS (prior to the node that owns that pkg_pretend being built, a new kernel could be swapped in or the config changed for existing kernel by a proceeding built step- basically it's temporal sensitive thus cannot be done).


> Yes, in certain situations it is nice, but as we're limited by how long it 
> takes Portage to implement something, we've had to stick with the single most > general option for this.

Ciaran... you know as well as I that that doesn't justify a shitty solution.
Comment 13 Ciaran McCreesh 2010-03-31 07:58:21 UTC
If a new kernel could be swapped in, you need to rerun pkg_pretend, in just the same way that you need to rerun if a new kernel is swapped in after pkg_setup. You're deliberately being silly here.

As for other examples, you can check the tree just as easily as anyone else can.

There's nothing shitty about pkg_pretend. It's a simple, general solution that was voted in by the Council after careful discussion.
Comment 14 Brian Harring gentoo-dev 2010-03-31 08:06:31 UTC
(In reply to comment #13)
> If a new kernel could be swapped in, you need to rerun pkg_pretend, in just the
> same way that you need to rerun if a new kernel is swapped in after pkg_setup.
> You're deliberately being silly here.

I'm not.  Your proposing people move their die checks from pkg_setup into pkg_pretend.  pkg_setup is executed prior to the actual build steps, after all proceeding DEPEND deps have been satisfied.

Meaning stupid things like kernel checks and active python checks can succeed as long as their deps are specified properly.

What you're proposing is to move all of those checks up front, and run them after the graph calculation, prior to any of the build steps.  It's a nice theory, but w/out the temporal bit pkg_setup gives ebuilds, the checks will false positive.

At best, it'll result in users having to manually break up their emerge invocations into multiple steps.  This is actually a *regression* from the current behaviour (which sucks, but sucks less then false positives up the ying yang from pkg_pretend).

> As for other examples, you can check the tree just as easily as anyone else
> can.

I've checked the tree a couple of times in the past; every time, the pkg_setup based dies are *always* build sensitive, meaning previous merge steps influence them.

> There's nothing shitty about pkg_pretend. It's a simple, general solution that
> was voted in by the Council after careful discussion.

Bluntly, the council screwed up.  Also a reason we should be using gleps for crap like this.

Up front, if your intention is to keep this functionality in eapi4, please enumerate alternative examples that don't false positive.  I'll be taking it to the council for a reversion- you'll want the examples to keep it in.

Of course if you just *stated* the examples now, that would be easier- so please do.

Comment 15 Ciaran McCreesh 2010-03-31 08:18:33 UTC
You will note that PMS specifically addresses your concerns about the state of the system.

With that in mind, if you want to go to the Council and try to persuade them to remove the fix for a major user annoyance, go right ahead. The discussion's already been had on pkg_pretend, EAPI 4 is already settled, and it's not a productive use of anyone's time to repeat the same discussions over and over again.
Comment 16 Brian Harring gentoo-dev 2010-03-31 08:30:03 UTC
(In reply to comment #15)
> You will note that PMS specifically addresses your concerns about the state of
> the system.

PMS isn't even fricking self-correct in that regard.  The example it gives is contradicted by the very next paragraph: I quote-

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.

As I already spelled out in this discussion, the kernel can be replaced/modified by merges proceeding the owner of the pkg_pretend.  It's a pkg_setup blow up (build step sensitive), not a pkg_pretend.

If PMS can't provide a non USE example in it's own documentation, that doesn't speak well for the feature.

> With that in mind, if you want to go to the Council and try to persuade them to
> remove the fix for a major user annoyance, go right ahead. The discussion's
> already been had on pkg_pretend
Where is this discussion?  URLs would be rather useful here.

Note also, again, reinforcing documenting this crap somewhere rather then "yeah, we talked about it and you missed it" ;)

> EAPI 4 is already settled, and it's not a
> productive use of anyone's time to repeat the same discussions over and over
> again.

If you can't provide justification for a feature apparently speced out in a void, that's not a good sign.  The only discussion I see is the council agreeing to it from the use angle... that's it.
Comment 17 Brian Harring gentoo-dev 2010-03-31 08:35:12 UTC
Also, please point me at a council log where they decided EAPI4 was 'settled'.  It was punted, at one point they decided to not open the feature list, but that sure as hell isn't accepting it from my interpretation of things...
Comment 18 Ciaran McCreesh 2010-03-31 08:38:25 UTC
Alright, take it to the Council then. They can spend their time discussing it with you if they want, or they can just ask for the feature to be removed, which only takes a couple of minutes to do.

EAPI 3 was approved pending Portage implementation on 20090514, and was renamed to EAPI 4 on 20100118. Also note the vote on 20090611 not to reopen the EAPI 3 feature list for further discussion.
Comment 19 Brian Harring gentoo-dev 2010-03-31 08:41:26 UTC
(In reply to comment #18)
> EAPI 3 was approved pending Portage implementation on 20090514, and was renamed
> to EAPI 4 on 20100118. Also note the vote on 20090611 not to reopen the EAPI 3
> feature list for further discussion.

Thanks for the council references- found 20090611, aware of 20100118, but hadn't seen 20090514.

Meanwhile I'll take it up to them.
Comment 20 Tiziano Müller (RETIRED) gentoo-dev 2010-03-31 11:13:19 UTC
Another use case:
Warn the user _before_ upgrading to a new PostgreSQL major version to dump the db instead of warning somewhere in between where he usually sees it after he has updated.
Comment 21 Brian Harring gentoo-dev 2010-03-31 11:32:58 UTC
http://pkgcore.org/~ferringb/isolated.log

^^^ that is basically the pkg_setup's ripped out of every eclass/ebuild, and some minor crap intermixed in (patches to filter-env are welcome, that said pkg_setup comes through cleanly).

Quick scan of the first 20-30 dies in it results in the following *NON* USE state based dies: note if I state something is temporal, I mean that it should be pkg_setup since a proceeding pkg build step could fix it (possibly):

* random symlinks hanging around that break the build; technically it could be temporal, but I highly doubt it.
* kernel related checks.  Temporal.
* use state enabled has_version checks- for example 
 if use nsplugin && ! use npplugin && has_version ">=net-libs/xulrunner-1.9.2" ...
 temporal
* specific use flag combined w/ a specific current active JVM, or active python... can you say temporal?
* built_with_use sys-devel/gcc hardened invocations.  Temporal (a rebuild of gcc in the build plan from a new use would solve that just fine)
* check for cfsd running.  Non temporal.
* upgrade version checks.  vast majority are nontemporal, but corner cases can exist.
* unset env var (oracle crap, go figure it's doing special things).  Can you say "temporal"?  that's assuming ORACLE_HOME is set via env.d rather than user configuration forcing it somewhere
* gcc targeted architecture check (i586 and i686 supported only)... temporal, although admittedly unlikely to be solved by a proceeding node (CHOST isn't something that exactly varies, only would occur during a -e)
* FEATURES check for unmerge-orphans combined w/ has_version.  Violation of PMS first of all, mostly non temporal.
* whole crapload of built_with_use checks which are blatantly temporal.

Etc.  Think that gets the point across- there are some valid uses for pkg_pretend (better name is pkg_sanity frankly), but the vast majority is easily covered by VALID_USE which has superior properties to using pkg_pretend for USE validation as outlined in
http://archives.gentoo.org/gentoo-dev/msg_b0e868626019f497eba47194c34e5421.xml
Comment 22 Ciaran McCreesh 2010-03-31 11:35:41 UTC
Given emerge --jobs, your argument about temporal things applies to anything run in pkg_setup equally as it does to pkg_pretend anyway.
Comment 23 Brian Harring gentoo-dev 2010-03-31 11:38:01 UTC
(In reply to comment #22)
> Given emerge --jobs, your argument about temporal things applies to anything
> run in pkg_setup equally as it does to pkg_pretend anyway.

That's a nonsensical statement.  A proper --jobs implementation w/ full dependencies results in deps being built prior to the consumer (as you very well know), meaning temporal applies.

If you're claiming otherwise, feel free to spell it out for my feeble mind.  Just spare me the rant towards portage it's probably going to turn into...
Comment 24 Ciaran McCreesh 2010-03-31 11:41:07 UTC
It's simple.

pkg_setup for a is run.
pkg_setup for b is run, which changes one of the things a assumes is true.
a reaches the part of its build where it assumes the thing that was true in pkg_setup remains true.
Comment 25 Brian Harring gentoo-dev 2010-03-31 11:44:27 UTC
(In reply to comment #24)
> It's simple.

Simple, and yet faulty...

> pkg_setup for a is run.
> pkg_setup for b is run, which changes one of the things a assumes is true.
> a reaches the part of its build where it assumes the thing that was true in
> pkg_setup remains true.

Pkg a, if it's able to be affected pkg b, should have a dependency on pkg b.  Note I said *full* dependencies, implicit system deps are an orthogonal problem (one that is nearing the point we can properly solve it due to increased resolver intelligence).

If you're claiming that pkg a and pkg b have zero relation to each other and somehow manage to trip each other up, *and* neither pkg a nor pkg b are doing blatantly malicious retarded things like trashing env.d, I'd love to hear that example.

Comment 26 Ciaran McCreesh 2010-03-31 11:47:44 UTC
Why should first-foo-implementation have a dependency upon second-foo-implementation? They're both independent implementations of foo, and both can be installed in parallel.
Comment 27 Brian Harring gentoo-dev 2010-03-31 11:52:10 UTC
(In reply to comment #26)
> Why should first-foo-implementation have a dependency upon
> second-foo-implementation? They're both independent implementations of foo, and
> both can be installed in parallel.

Pure nonsense- if they can be installed in parallel that means they should not be sensitive to each other at all during build.  If they are, it's an ebuild bug.

Concrete example from the tree would be nice btw- I kept a build farm going for a year relying on --jobs and I know the chrome folk are pretty fricking reliant on it (their issues have been purely implicit system deps for from scratch rebuilds)...

Real world examples of ebuilds that cannot be built in parallel, but are *properly written/maintained* ebuilds would be very useful for strengthening your argument.
Comment 28 Ciaran McCreesh 2010-03-31 11:56:05 UTC
A whole bunch of things call eselect opengl during pkg_setup...
Comment 29 Brian Harring gentoo-dev 2010-03-31 12:13:49 UTC
(In reply to comment #28)
> A whole bunch of things call eselect opengl during pkg_setup...
Suggest you look through that isolated.log I posted.  "Whole bunch" is 5 in this case- further, you screwed up, anything that could be influenced by that should have a subgraph that traces back to a dependency on virtual/opengl, which those invokers is involved w/ as a satisfier for it.

Meanwhile this particularly thread of discussion is circling the drain (that's what 4 claims, 4 disputed?).  If you've got a problem w/ --jobs, take it up w/ QA please.

Regardless, there still is one core fact about pkg_pretend vs pkg_setup that is undeniable- for the vast majority of instances that are temporal while ran w/ --jobs=1, it'll force the user to break up the emerge invocation into multiple separate invocations to sidestep the pkg_pretend's false-positively going boom.

That's a pretty significant user experience regression for cases that previously worked...
Comment 30 Brian Harring gentoo-dev 2010-03-31 12:14:55 UTC
Sidenote, when you dispute the --jobs 1 claim, please point out concrete examples from the tree instead of being vague requiring 4-5 comments to draw out something that is actually real world in use.  Use isolated.log if necessary. Crashing meanwhile, will resume when you have example and I have sleep...
Comment 31 Ciaran McCreesh 2010-03-31 12:19:46 UTC
So you're saying that because all of those packages dep upon eselect-opengl, they won't be parallelised? Every package deps upon glibc. Therefore no package will be parallelised.

But this is getting away from the point. The point is, pkg_pretend is useful for all kinds of things, including a lot of them that can't be solved by something like MYOPTIONS, and it introduces no new developer screw-up possibilities that aren't already there with pkg_setup.
Comment 32 Brian Harring gentoo-dev 2010-03-31 12:28:16 UTC
(In reply to comment #31)
> So you're saying that because all of those packages dep upon eselect-opengl,
> they won't be parallelised? Every package deps upon glibc. Therefore no package
> will be parallelised.

Either you're trolling, or you're being daft.  Consumers of a library cannot be built until that library is built, pure and simple.  Once you're past that point parallelization can open up, but that is a core bottleneck.

You know this.

> But this is getting away from the point. The point is, pkg_pretend is useful
> for all kinds of things, including a lot of them that can't be solved by
> something like MYOPTIONS, and it introduces no new developer screw-up
> possibilities that aren't already there with pkg_setup.

Almost every fricking use of pkg_pretend that is listed I've pointed out better ways of doing it, or instances where it's a regression in UX from existing mechanisms... if you're going to throw up a mission accomplish banner and strut and ignore the reality of things, hey, go nuts.

I'm still taking it to the council, you're just demonstrating w/in this bug that pkg_pretend isn't good enough for a sane defense to be mounted for it (especially in light of VALID_USE).  Either way enough of this.  If you've got concrete examples I'm more than willing to listen, but I'm not going to be deflected from going after it via cyclical justification/discussion.
Comment 33 Ciaran McCreesh 2010-03-31 12:39:07 UTC
(In reply to comment #32)
> Either you're trolling, or you're being daft.  Consumers of a library cannot be
> built until that library is built, pure and simple.  Once you're past that
> point parallelization can open up, but that is a core bottleneck.
> 
> You know this.

Please explain to me how two packages that both call eselect monkey in pkg_setup can never be built in parallel. Keeping this nice and simple, let's say we have two packages, foo and bar, both of which simply depend upon eselect-monkey and a particular monkey provider, and both of which are targets. How does the package manager know that foo and bar cannot be built together? Let's also say that we have two packages, moo and oink, both of which simply depend upon glibc, and both of which are targets. How does the package manager know that moo and oink can be parallelised?

> Almost every fricking use of pkg_pretend that is listed I've pointed out better
> ways of doing it, or instances where it's a regression in UX from existing
> mechanisms... if you're going to throw up a mission accomplish banner and strut
> and ignore the reality of things, hey, go nuts.

The key word being "almost". Since we can only expect Portage to implement one thing, not several, we need to go for the most general solution.

> I'm still taking it to the council, you're just demonstrating w/in this bug
> that pkg_pretend isn't good enough for a sane defense to be mounted for it
> (especially in light of VALID_USE).  Either way enough of this.  If you've got
> concrete examples I'm more than willing to listen, but I'm not going to be
> deflected from going after it via cyclical justification/discussion.

VALID_USE doesn't cover everything pkg_pretend does. Unless you're claiming that it's reasonable to expect Portage to implement both in the target timeframe for EAPI 4, the one that covers most use cases should be taken.
Comment 34 Brian Harring gentoo-dev 2010-04-01 07:44:25 UTC
(In reply to comment #33)
> Please explain to me how two packages that both call eselect monkey in
> pkg_setup can never be built in parallel. Keeping this nice and simple, let's
> say we have two packages, foo and bar, both of which simply depend upon
> eselect-monkey and a particular monkey provider, and both of which are targets.
> How does the package manager know that foo and bar cannot be built together?

Guess you don't know this.  Fair enough.  As you're consuming the graph (walking the topo sort of the graph alternatively), you trace the deps of the node you want to work on.  Is anything it needs being built/mangled currently (including rdepends/prdepends?), specifically, is that node now satisfied?  If not, it can't be built till it is.  Parallelization is the exact same thing.

As for foo/bar from your example above, they can go parallel as long as they're effectively separate subgraphs at that point.

> Let's also say that we have two packages, moo and oink, both of which simply
> depend upon glibc, and both of which are targets. How does the package manager
> know that moo and oink can be parallelised?

See algo above.  It's a continual sorting specifically, pulling from the graph- moo's DEPEND are finished, thus moo can be started.  If there is a build/job slot available and oink's DEPENDs are finished, it can be started.  Implicit in this is that they can go parallel as long as they don't ref each other, and they cannot be started (parallel or otherwise) till their DEPENDS are finished.

Throughly off track from your pkg_setup claims also, but per the norm.

> > Almost every fricking use of pkg_pretend that is listed I've pointed out better
> > ways of doing it, or instances where it's a regression in UX from existing
> > mechanisms... if you're going to throw up a mission accomplish banner and strut
> > and ignore the reality of things, hey, go nuts.
> 
> The key word being "almost". Since we can only expect Portage to implement one
> thing, not several, we need to go for the most general solution.

And we can expect you consistantly to point at portage as why you must get your way.  Give it a rest.  We can't standardize FEATURES because paludis doesn't support it.  Nyah nyah nyah.

Seriously, this is tiresome.

> > I'm still taking it to the council, you're just demonstrating w/in this bug
> > that pkg_pretend isn't good enough for a sane defense to be mounted for it
> > (especially in light of VALID_USE).  Either way enough of this.  If you've got
> > concrete examples I'm more than willing to listen, but I'm not going to be
> > deflected from going after it via cyclical justification/discussion.
> 
> VALID_USE doesn't cover everything pkg_pretend does. Unless you're claiming
> that it's reasonable to expect Portage to implement both in the target
> timeframe for EAPI 4, the one that covers most use cases should be taken.

Read exactly what I stated.  VALID_USE covers the main thrust of pkg_pretend, and the vast majority of the other things it claims to improve are actually regressions.

But cherry pick your arguments all you want, I want real examples.  You're not providing them, thus I'm finished with this discussion.
Comment 35 Ciaran McCreesh 2010-04-01 07:52:39 UTC
(In reply to comment #34)
> (In reply to comment #33)
> > Please explain to me how two packages that both call eselect monkey in
> > pkg_setup can never be built in parallel. Keeping this nice and simple, let's
> > say we have two packages, foo and bar, both of which simply depend upon
> > eselect-monkey and a particular monkey provider, and both of which are targets.
> > How does the package manager know that foo and bar cannot be built together?
> 
> Guess you don't know this.  Fair enough.  As you're consuming the graph
> (walking the topo sort of the graph alternatively), you trace the deps of the
> node you want to work on.  Is anything it needs being built/mangled currently
> (including rdepends/prdepends?), specifically, is that node now satisfied?  If
> not, it can't be built till it is.  Parallelization is the exact same thing.
> 
> As for foo/bar from your example above, they can go parallel as long as they're
> effectively separate subgraphs at that point.

Which is exactly the eselect opengl point: foo and bar *can't* be built in parallel, because both call 'eselect monkey' in pkg_*, and neither depends directly or indirectly upon the other.

> > The key word being "almost". Since we can only expect Portage to implement one
> > thing, not several, we need to go for the most general solution.
> 
> And we can expect you consistantly to point at portage as why you must get your
> way.  Give it a rest.  We can't standardize FEATURES because paludis doesn't
> support it.  Nyah nyah nyah.

No, we can't standardise FEATURES because a value being in FEATURES isn't a reliable indication that it's enabled. If ebuilds were able to use FEATURES correctly, Paludis would implement it, but there is *no* legitimate use for FEATURES and there are equally powerful but correct alternatives.

> > VALID_USE doesn't cover everything pkg_pretend does. Unless you're claiming
> > that it's reasonable to expect Portage to implement both in the target
> > timeframe for EAPI 4, the one that covers most use cases should be taken.
> 
> Read exactly what I stated.  VALID_USE covers the main thrust of pkg_pretend,
> and the vast majority of the other things it claims to improve are actually
> regressions.

Except that the "vast majority" (which is an exaggeration) is not all, and they're mostly not regressions because they're just as wrong in pkg_setup.

> But cherry pick your arguments all you want, I want real examples.  You're not
> providing them, thus I'm finished with this discussion.

You're ignoring the real examples in this bug.
Comment 36 Brian Harring gentoo-dev 2010-04-01 08:09:09 UTC
(In reply to comment #35)
> Which is exactly the eselect opengl point: foo and bar *can't* be built in
> parallel, because both call 'eselect monkey' in pkg_*, and neither depends
> directly or indirectly upon the other.

If all they're doing is querying what the current provider of the eselect target is, they can.

If they're changing the current system defaults so they can build, they can't, and are blatant QA violations anyways (broken ebuilds are ignorable since they don't particularly work right anyways).


> No, we can't standardise FEATURES because a value being in FEATURES isn't a
> reliable indication that it's enabled.

You're being a bit crack-adled here...  You just claimed that you can't rely on 'sandbox' in FEATURES as an indication the PM has sandbox active.

> Except that the "vast majority" (which is an exaggeration) is not all, and
> they're mostly not regressions because they're just as wrong in pkg_setup.

vast majority is based on me going through every fricking pkg_setup in the tree.  You start providing examples (percentile of pkg_setup's that aren't temporal out of the # of pkg_setups that have a die) and we can talk.  I already stated my rough stats above.

Further, it's not *wrong* to use pkg_setup this way.  Annoying, yes, but this is part of it's purpose (a decade of such uses backs that statement up).  So your claim is "they're mostly not regressions" because they're of equal 'wrongness', just ignoring the fact that the majority have a good chance of not triggering the die if ran as pkg_setup.

This is textbook regression.

> You're ignoring the real examples in this bug.

Ciaran, if just saying something made it reality, paludis would be the pkg manager of gentoo and you'd be running the distro due to your repeated claims you're the only one who can do things right (prefix for example).

Reality doesn't work that way.  If you can't enumerate a set of actual examples from the tree (I already gave you the isolated bash source to look through), just give it a rest.

He who posts the most isn't automatically right- they're usually just annoying.  actual metrics and data are needed, not handwaving vague examples.

If you have data to provide, I'm willing to discuss it.  This however is a waste of time without you providing data to back your claims.
Comment 37 Ciaran McCreesh 2010-04-01 08:15:04 UTC
(In reply to comment #36)
> If all they're doing is querying what the current provider of the eselect
> target is, they can.

Yes, but I gave you *real examples* of where they weren't.

> If they're changing the current system defaults so they can build, they can't,
> and are blatant QA violations anyways (broken ebuilds are ignorable since they
> don't particularly work right anyways).

And here is why giving you real examples is a bad idea: you claim that real examples don't count, because they're wrong.

> > No, we can't standardise FEATURES because a value being in FEATURES isn't a
> > reliable indication that it's enabled.
> 
> You're being a bit crack-adled here...  You just claimed that you can't rely on
> 'sandbox' in FEATURES as an indication the PM has sandbox active.

Correct. It's an indication that sandbox may or may not be active.

> Further, it's not *wrong* to use pkg_setup this way.  Annoying, yes, but this
> is part of it's purpose (a decade of such uses backs that statement up).  So
> your claim is "they're mostly not regressions" because they're of equal
> 'wrongness', just ignoring the fact that the majority have a good chance of not
> triggering the die if ran as pkg_setup.

So your argument is that doing it in pkg_setup is still wrong, but more likely to work by fluke?

> This is textbook regression.

A change which makes an existing bug more likely to happen isn't a regression.

> Reality doesn't work that way.  If you can't enumerate a set of actual examples
> from the tree (I already gave you the isolated bash source to look through),
> just give it a rest.

You've been ignoring comment #20. Heck, you've been ignoring the opening example in the bug.

> He who posts the most isn't automatically right- they're usually just annoying.
>  actual metrics and data are needed, not handwaving vague examples.

Then why have you constantly ignored the initial example in the bug whilst posting?
Comment 38 Brian Harring gentoo-dev 2011-05-28 07:53:52 UTC
rev 8c60db98 of pms already covers this; went out in eapi4 and is supplanted mostly via RESTRICTED_USE.