Tried to install g-pypi on my system. Failed with the following error: http://zougloub.eu/2013-10-26-cave.html Portage has the following: http://zougloub.eu/2013-10-20-cave-portage.html I don't see portage exporting the PYTHON_SINGLE_TARGET flags. However, since portage has EAPI=2 and not 5, the flags are doing something which prevents gentoolkit-dev from being happy with my use flags. Updating portage to EAPI=5 fixes the problem, but that may not be a desirable solution since it prevents some users from updating portage. I went to ask some help and here's what I got: <ciaranm> oh. the piece of information you seem to be missing is that for EAPIs before 5, *all* flags are present in USE_EXPAND values, even if they're not explicitly listed. so portage does have this flag, even though it's not in IUSE <ciaranm> basically, (-) deps don't work on USE_EXPAND values unless everything involved is EAPI 5 Reproducible: Always Steps to Reproduce: 1. cave resolve gentoolkit-dev 2. look at the error messages, update USE flags to use python2 because some deps are only python2 compatible 3. cave resolve gentoolkit-dev 4. look at the error message, we're stuck Expected Results: 4. resolution working
Now I'm getting lost. Wasn't I told before that '(-)' actually makes it possible to use the deps against non-EAPI 5 packages?
Not for USE_EXPANDed flags. For EAPIs before 5, every USE_EXPAND flag is treated as being in IUSE for the purposes of (-) deps, even if they're not explicitly listed. (This happened because the Council split up the original-EAPI-3 featureset by "what's implemented in Portage stays, and the rest is deferred", which meant the (-) feature was included without some of the mechanisms required to handle strange side cases. The spec as originally proposed didn't have this oddity.)
Reading PMS, I don't get it again: About USE-deps: > In a 4-style use dependency, the flag name may immediately be followed by a default specified by either (+) or (-). The former indicates that, when applying the use dependency to a package that does not have the flag in question in IUSE_REFERENCEABLE, the package manager shall behave as if the flag were present and enabled; the latter, present and disabled. And about IUSE_REFERENCEABLE: > For EAPIs listed in table 5.2 as not supporting profile defined IUSE injection, IUSE_REFERENCEABLE is equal to the calculated IUSE value. So, EAPI<5 should have the extra flags in IUSE_EFFECTIVE but not in IUSE_REFERENCEABLE, correct? Then the USE-dep should use the default...
@pms-bugs: ping. It is kind of important to decide whether it's a bug in Paludis or our code.
(In reply to Michał Górny from comment #4) > @pms-bugs: ping. It is kind of important to decide whether it's a bug in > Paludis or our code. <mgorny> ulm: could you try to help me with bug 488776? i'd appreciate someone trying to tell me if i'm understanding PMS wrong :) [...] <ulm> mgorny: re bug 488776 <mgorny> ulm: yes? <ulm> for EAPIs 0 1 2 3 4, IUSE_REFERENCEABLE is equal to IUSE, as calculated from the ebuild and eclasses <ulm> so indeed the (-) default is used <ulm> mgorny: that is, if the flag is not in IUSE, then it won't be taken from any USE_EXPAND or profile <mgorny> ulm: does that mean that paludis does the wrong thing? <ulm> no idea, but it would surprise me <ulm> IIRC, ciaran has written that spec ;) <ulm> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;f=ebuild-env-vars.tex;h=40315369bbf1b2332e1bd228056dc39d39b6a7d0 <ulm> specifically, the diff for ebuild-env-vars.tex <dwfreed> ulm: from my understanding, iuse_referenceable is what should be used for 4-style usedeps with a default specified, and portage is eapi 2, so referenceable should be equal to plain iuse <ulm> dwfreed: yeah, that's what I read, too
The intent was roughly this: in the olden days, USE_EXPAND flags didn't have to be listed in IUSE, but were still treated as being present for use queries. So if you did built_with_use blah linguas_en, it would "work" even if the package didn't say that it used linguas. Thus you couldn't do a (+)/(-) on anything in linguas, because it would always be present even if not explicitly listed. So one of the implications of the spec should be that (+)/(-) deps won't work for USE_EXPAND flags on EAPIs before 5, because USE_EXPAND flags are always treated as being there even if they're not explicitly listed. I dunno if the spec actually still says that after the mess with how these features were added...
(In reply to Ciaran McCreesh from comment #6) > The intent was roughly this: in the olden days, USE_EXPAND flags didn't have > to be listed in IUSE, but were still treated as being present for use > queries. So if you did built_with_use blah linguas_en, it would "work" even > if the package didn't say that it used linguas. Thus you couldn't do a > (+)/(-) on anything in linguas, because it would always be present even if > not explicitly listed. > > So one of the implications of the spec should be that (+)/(-) deps won't > work for USE_EXPAND flags on EAPIs before 5, because USE_EXPAND flags are > always treated as being there even if they're not explicitly listed. > It's even worse. USE_EXPAND flags aren't the only things added to IUSE before EAPI 5. See comments in _get_implicit_iuse() [1]. > I dunno if the spec actually still says that after the mess with how these > features were added... In "11.1.1 USE and IUSE Handling" it talks about adding USE_EXPAND, etc. to IUSE_EFFECTIVE. And here is the problem. For portage IUSE_EFFECTIVE and IUSE_REFERENCEABLE are always the same. I doubt that this was different at any time. Since paludis probably follows PMS, it ends up with the problem in comment 0, whereas portage has no such problem (i.e. it treats the flag as disabled if it isn't in USE). Bug in PMS? [1] http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=pym/portage/package/ebuild/config.py;h=92e6c3fedd209963347d2ffe6e74d7534823e083;hb=HEAD#l1752
(In reply to Sebastian Luther (few) from comment #7) > (In reply to Ciaran McCreesh from comment #6) > It's even worse. USE_EXPAND flags aren't the only things added to IUSE > before EAPI 5. See comments in _get_implicit_iuse() [1]. I don't see regular USE_EXPAND flags there. So this shouldn't affect python flags. I'm wondering if it affects multilib though. While the flags are HIDDEN and masked by default, they are un-HIDDEN and un-masked in the specific profiles.
(In reply to Sebastian Luther (few) from comment #7) > In "11.1.1 USE and IUSE Handling" it talks about adding USE_EXPAND, etc. to > IUSE_EFFECTIVE. > > And here is the problem. For portage IUSE_EFFECTIVE and IUSE_REFERENCEABLE > are always the same. I doubt that this was different at any time. Since > paludis probably follows PMS, it ends up with the problem in comment 0, > whereas portage has no such problem (i.e. it treats the flag as disabled if > it isn't in USE). Bug in PMS? No, Portage has changed its behaviour repeatedly in the past, hence the wording in PMS that disallows relying upon any behaviour that hasn't been fixed. (Historically, IUSE was purely for cosmetic purposes, and this didn't really change until built_with_use --missing came along.) Unfortunately it seems Portage has ignored what the Council voted upon to sort that mess out from EAPI 5 onwards...
(In reply to Michał Górny from comment #8) > (In reply to Sebastian Luther (few) from comment #7) > > (In reply to Ciaran McCreesh from comment #6) > > It's even worse. USE_EXPAND flags aren't the only things added to IUSE > > before EAPI 5. See comments in _get_implicit_iuse() [1]. > > I don't see regular USE_EXPAND flags there. So this shouldn't affect python > flags. > You're right, portage only adds USE_EXPAND_HIDDEN flags, but PMS demands USE_EXPAND. (In reply to Ciaran McCreesh from comment #9) > (In reply to Sebastian Luther (few) from comment #7) > > In "11.1.1 USE and IUSE Handling" it talks about adding USE_EXPAND, etc. to > > IUSE_EFFECTIVE. > > > > And here is the problem. For portage IUSE_EFFECTIVE and IUSE_REFERENCEABLE > > are always the same. I doubt that this was different at any time. Since > > paludis probably follows PMS, it ends up with the problem in comment 0, > > whereas portage has no such problem (i.e. it treats the flag as disabled if > > it isn't in USE). Bug in PMS? > > No, Portage has changed its behaviour repeatedly in the past, hence the > wording in PMS that disallows relying upon any behaviour that hasn't been > fixed. (Historically, IUSE was purely for cosmetic purposes, and this didn't > really change until built_with_use --missing came along.) Unfortunately it > seems Portage has ignored what the Council voted upon to sort that mess out > from EAPI 5 onwards... I was only talking IUSE_REFERENCEABLE for <EAPI-5 and if it is equal to IUSE_EFFECTIVE (as currently with portage) or to IUSE (as PMS demands). Are you saying that there was a behavior change here? (In reply to Ciaran McCreesh from comment #2) > Not for USE_EXPANDed flags. For EAPIs before 5, every USE_EXPAND flag is > treated as being in IUSE for the purposes of (-) deps, even if they're not > explicitly listed. > As I read it, PMS doesn't say that. PMS: "IUSE is the variable calculated from the IUSE values defined in ebuilds and eclasses. [...] For EAPIs listed in table 5.2 as not supporting profile defined IUSE injection, IUSE_REFERENCEABLE is equal to the calculated IUSE value." IUSE_REFERENCEABLE is equal to IUSE, IUSE comes only from ebuilds and eclasses -> no USE_EXPAND flags in there
The exact case we're discussing is covered in PMS: > Note: By extension of the above, a default that could reference an ebuild using > an EAPI not supporting profile IUSE injections cannot rely upon any particular > behaviour for flags that would not have to be part of IUSE.
(In reply to Ciaran McCreesh from comment #11) > The exact case we're discussing is covered in PMS: > > > Note: By extension of the above, a default that could reference an ebuild using > an EAPI not supporting profile IUSE injections cannot rely upon any particular > behaviour for flags that would not have to be part of IUSE. Ok, fine with me. Shouldn't this be made more clear in the section that says: "For EAPIs listed in table 5.2 as not supporting profile defined IUSE injection, IUSE_REFERENCEABLE is equal to the calculated IUSE value."? To fix this bug: * new portage ebuilds need to have PYTHON_SINGLE_TARGETS values in IUSE * gentoolkit-dev needs to depend on only those new portage ebuilds Is that correct?
(In reply to Sebastian Luther (few) from comment #12) > To fix this bug: > > * new portage ebuilds need to have PYTHON_SINGLE_TARGETS values in IUSE > * gentoolkit-dev needs to depend on only those new portage ebuilds > > Is that correct? No, this won't help at all. To fix it with Ciaran's interpretation of PMS, we have to completely rework PYTHON_USEDEP, likely splitting it into PYTHON_USEDEP and PYTHON_SINGLE_USEDEP. Then write a script to fix all the dependencies and it will still fail if some package switches from python-single-r1 to python-r1 or the other way around. I'd say the only sane solution would be requiring all deps to be EAPI 5.
