+++ This bug was initially created as a clone of Bug #302619 +++ ... When adding PackageDepSpec 'net-libs/gnutls': ... When adding installed package 'net-libs/gnutls-2.8.5:0::installed': ... When adding run dependencies as post dependencies: ... When adding PackageDepSpec 'dev-scheme/guile[networking]': ... When finding all versions sorted from packages matching dev-scheme/guile[networking] intersected with packages that might support action install with filter all matches: ... ID 'dev-scheme/guile-1.6.8:12::gentoo' has no flag named 'networking' In gnutls ebuild: guile? ( dev-scheme/guile[networking] ) However dev-scheme/guile-1.6.8 does not have this flag. Posibly it should be guile? ( >=dev-scheme/guile-1.8.4[networking] ) Or guile? ( || ( >=dev-scheme/guile-1.8.4[networking] =dev-scheme/guile-1.6* ) ) Reproducible: Always This kinda stuff drives me nuts, so I'm starting a tracker to keep up with the packages that cause this nuisance of an error
See fix in bug 302169. Please report packages that cause this traceback to this bug, and either I or the ebuild maintainer will get a patched ebuild out. So far, I have only seen 2, as reported by the trac ticket in the URL. This bug is not meant to start a flamewar between PMS developers, but to start fostering cooperation.
Reassigning to ebuild group
the shown problem of different use-flag sets in one package and lazy rdepend maintainers not looking for such things is not only limited to paludis.
There's no such thing as ebuilds written for paludis/portage/pkgcore. We have specifications and ebuilds should follow them. So if an ebuild fails for one specific PM only, then either that PM has a bug (you say this is not the case here). Or the ebuild itself is faulty, i.e. violates specs, in which case a bug should be filed for it. I'm inclined to close this bug as INVALID because its summary boils down to "poorly written ebuilds" which is too unspecific as a tracker.
(In reply to comment #4) > There's no such thing as ebuilds written for paludis/portage/pkgcore. We have > specifications and ebuilds should follow them. So if an ebuild fails for one > specific PM only, then either that PM has a bug (you say this is not the case > here). Or the ebuild itself is faulty, i.e. violates specs, in which case a > bug should be filed for it. > The ebuilds work with all package managers. The difference is that paludis prints a warning and portage does not. The question is if PMS requires a warning/error or not. PMS: " 9.2.2 Use-conditional Dependency Specifications [...] It is an error for a flag to be used if it is not included in IUSE_EFFECTIVE as described in section 12.1.1. " Assume there are two packages and app-misc/foo and dev-libs/bar. app-misc/foo-1 has DEPEND="dev-libs/bar[A]". For now there is only one version of bar: app-misc/bar-1 and it has IUSE="A". Until now everything is fine. Now dev-libs/bar-2 gets released and feature A, which is controlled by the use flag A, can no longer be disabled. Therefor the ebuild for dev-libs/bar-2 has IUSE="". What now happens is that dev-libs/bar-2 cannot be used to satisfy the dependency of app-misc/foo. Therefore paludis prints a warning that app-misc/foo uses the use flag A in a dependency on dev-libs/bar, but dev-libs/bar-2 doesn't have this use flag. Portage doesn't print any warning in this case. This happens first if there is no other version that could satisfy the dependency of app-misc/foo-1. Do we really want such a warning or even declare this an error? As I see it, the consequence would be that you could never remove a use flag from an ebuild (including future versions of the ebuild). You would need to update each reverse dependency to reflect the change. Since this might affect ebuilds you don't have control over, you simply can't do that. Am I missing something here? > I'm inclined to close this bug as INVALID because its summary boils down to > "poorly written ebuilds" which is too unspecific as a tracker. > I think this bug is more about PMS / PMS interpretation than about ebuilds.
(In reply to comment #5) > As I see it, the consequence would be that you could never remove a use > flag from an ebuild (including future versions of the ebuild). You would > need to update each reverse dependency to reflect the change. So you just update the dependency in foo-1 (and all other reverse dependencies of bar) to something like DEPEND="|| ( >=bar-2 bar[A] )". > Since this might affect ebuilds you don't have control over, you simply > can't do that. Huh? Ebuild devs have access to the whole portage tree. Or are you talking about overlays? > I think this bug is more about PMS / PMS interpretation than about ebuilds. I don't see how PMS could mandate if the PM should print a warning or not. The PM cannot know if feature A in bar-2 is unconditionally enabled or if it has been removed (in which case the dependency would be correct).
(In reply to comment #6) > > Since this might affect ebuilds you don't have control over, you simply > > can't do that. > > Huh? Ebuild devs have access to the whole portage tree. Or are you talking > about overlays? > Yes and those ebuilds an user might have in a local overlay. All those ebuilds would get the warning or error too, even if they would just keep working with an older version of their dependency. > > I think this bug is more about PMS / PMS interpretation than about ebuilds. > > I don't see how PMS could mandate if the PM should print a warning or not. The > PM cannot know if feature A in bar-2 is unconditionally enabled or if it has > been removed (in which case the dependency would be correct). > PMS could say that the PM has to treat such cases as if the ebuild doesn't satisfy the dependency (as if the version range doesn't match), like portage does.
(In reply to comment #7) > (In reply to comment #6) > > > Since this might affect ebuilds you don't have control over, you simply > > > can't do that. > Yes and those ebuilds an user might have in a local overlay. All those ebuilds > would get the warning or error too, even if they would just keep working with > an older version of their dependency. The user has two possibilities: a) update the local overlay to reflect the changed use-flags. b) do not update the dependency, since his/her system is not fit for the update. in case of a), the user has access to the ebuilds. in case of b). this is what portage does currently, w/o a warning. > PMS could say that the PM has to treat such cases as if the ebuild doesn't > satisfy the dependency (as if the version range doesn't match), like portage > does. the dependency ebuild? So you argue for an change in paludis behavior? (Sorry, i might have lost the point).
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > > Since this might affect ebuilds you don't have control over, you simply > > > > can't do that. > > Yes and those ebuilds an user might have in a local overlay. All those ebuilds > > would get the warning or error too, even if they would just keep working with > > an older version of their dependency. > The user has two possibilities: > a) update the local overlay to reflect the changed use-flags. > b) do not update the dependency, since his/her system is not fit for the > update. > > in case of a), the user has access to the ebuilds. > in case of b). this is what portage does currently, w/o a warning. > For b), if the PM follows strictly PMS, it will not allow the installation of said ebuild. There would be no way to "ignore" the change. The point is, that with current PMS wording, an ebuild can be rendered useless by a adding a new ebuild for one of its dependencies. Adding a new ebuild shouldn't have such side effects. > > PMS could say that the PM has to treat such cases as if the ebuild doesn't > > satisfy the dependency (as if the version range doesn't match), like portage > > does. > the dependency ebuild? So you argue for an change in paludis behavior? (Sorry, > i might have lost the point). > A Change in PMS (and following this and change in paludis).
(In reply to comment #9) > > > PMS could say that the PM has to treat such cases as if the ebuild > > > doesn't satisfy the dependency (as if the version range doesn't match), > > > like portage does. > > the dependency ebuild? So you argue for an change in paludis behavior? > > (Sorry, i might have lost the point). > > A Change in PMS (and following this and change in paludis). I still don't get it. PMS clearly says that dependencies "must be installed and usable" (section 9.1 in the eapi-3-approved version). It also specifies for USE dependencies: "[opt] The flag must be enabled" (section 9.2.4). So what exact change in PMS are you proposing?
(In reply to comment #10) > So what exact change in PMS are you proposing? > I cited the wrong part of PMS in comment 5, sorry for the confusion. What I wanted to cite is: PMS: " 9.2.4 Package Dependency Specifications [...] Unless a 4-style default is specified, it is an error for a use dependency to be applied to an ebuild which does not have the flag in question in IUSE_REFERENCEABLE. [...] " I propose to replace the cited text with: "A 2-style use dependency cannot be applied to an ebuild that does not have the flag in question in IUSE_REFERENCEABLE. The package manger must ignore such ebuilds when searching for ebuilds to satisfy this dependency."
Except that that's not what some Portage versions do. In the old days Portage used to store a complete set of USE for everything, including flags that weren't in IUSE. So whether or not a USE flag was treated as 'on' for an ebuild that didn't have it listed was pretty much arbitrary. If you want to be able to add and remove flags from IUSE, you need use(+) defaults.
(In reply to comment #12) > Except that that's not what some Portage versions do. In the old days Portage > used to store a complete set of USE for everything, including flags that > weren't in IUSE. So whether or not a USE flag was treated as 'on' for an ebuild > that didn't have it listed was pretty much arbitrary. > How do you decide if the use of a flag in a use dep is allowed, if the installed package's USE doesn't contain the flag? > If you want to be able to add and remove flags from IUSE, you need use(+) > defaults. > Even the IUSE defaults don't help with the issue, that an ebuild can be rendered useless by adding a new version of its deps (if one would enforce an error).
(In reply to comment #13) > How do you decide if the use of a flag in a use dep is allowed, if the > installed package's USE doesn't contain the flag? No no. Say you had IUSE="foo bar". Then old Portage versions would write a USE file to VDB containing something like "foo bar baz monkey # and the occasional comment". > Even the IUSE defaults don't help with the issue, that an ebuild can be > rendered useless by adding a new version of its deps (if one would enforce an > error). Use dependency defaults, not IUSE defaults.
(In reply to comment #14) > (In reply to comment #13) > > How do you decide if the use of a flag in a use dep is allowed, if the > > installed package's USE doesn't contain the flag? > > No no. Say you had IUSE="foo bar". Then old Portage versions would write a USE > file to VDB containing something like "foo bar baz monkey # and the occasional > comment". > I understood that. It was more a general question. Lets assume we have a system with only valid flags in USE of installed packages. Now I specify some use dep on an installed package. The installed package has the flag not in USE. How do you decide if the use dep is valid? Why is the contents of USE relevant for the question if the use dep is valid? > > Even the IUSE defaults don't help with the issue, that an ebuild can be > > rendered useless by adding a new version of its deps (if one would enforce an > > error). > > Use dependency defaults, not IUSE defaults. > That was what I meant, sorry.
I reported this bug because, at first, the "laziness factor" bothered me (Comment #3). I knew it could be fixed, as Comment #5 contains a general case of my initial report. This general case is what I wanted fixed. I appreciate the fact that something is being done. As a side note, on a regular basis you should see the warnings I choose not to report. (Various warnings occur in about 1 of every 4 syncs, but disappear as the portage tree gets updated) At the time, this warning was occurring with every world update, and I had let it go for nearly 2 months. Once again, Thank You All
(In reply to comment #15) > I understood that. It was more a general question. Lets assume we have a system > with only valid flags in USE of installed packages. Now I specify some use dep > on an installed package. The installed package has the flag not in USE. How do > you decide if the use dep is valid? Why is the contents of USE relevant for the > question if the use dep is valid? The issue is whether you can reliably use use dependencies upon things that aren't in IUSE. The answer to that has varied over time, and USE containing more than just things in IUSE (or any of the IUSE-derived values) is part of the problem. The wording in PMS is complicated because it has to restrict usage to anything that will work with any relevant Portage version. It can't just say "has to be in IUSE" because people do use use dependencies on things that aren't in IUSE, and at least some of those dependencies have been judged to be legitimate. The package manager *should* warn noisily for violations so that they can be fixed -- there's no behaviour that makes sense and that is safe for a dependency upon foo[bar] when [bar] can't be worked out any candidate version of foo. A lack of bar flag doesn't mean that bar is enabled, and it doesn't mean that bar is disabled. If you *want* to say "and if it doesn't have bar, don't meet the dep", you want [bar(-)] and [-bar(+)], not [bar]. > > > Even the IUSE defaults don't help with the issue, that an ebuild can be > > > rendered useless by adding a new version of its deps (if one would enforce an > > > error). > > > > Use dependency defaults, not IUSE defaults. > > > That was what I meant, sorry. Yes. So it's like anything else, when adding a new version: if you change things, you have to make sure that anything that depends upon you remains working. That's already an issue, and not something that use dependencies change.
(In reply to comment #17) > [...] > The package manager *should* warn noisily for violations so that they can be > fixed -- there's no behaviour that makes sense and that is safe for a > dependency upon foo[bar] when [bar] can't be worked out any candidate version > of foo. A lack of bar flag doesn't mean that bar is enabled, and it doesn't > mean that bar is disabled. If there is no candidate at all, the pm needs to error out (because the dep cannot be satisfied). The question is what should happen if there are candidates. It looks to me like paludis warns about the ebuilds that aren't candidates because the flag is not referenceable in this case. And I read PMS as if the ebuild stating this dep should not be installable. > > If you *want* to say "and if it doesn't have bar, don't meet the dep", you want > [bar(-)] and [-bar(+)], not [bar]. > > > > > Even the IUSE defaults don't help with the issue, that an ebuild can be > > > > rendered useless by adding a new version of its deps (if one would enforce an > > > > error). > > > > > > Use dependency defaults, not IUSE defaults. > > > > > That was what I meant, sorry. > > Yes. So it's like anything else, when adding a new version: if you change > things, you have to make sure that anything that depends upon you remains > working. That's already an issue, and not something that use dependencies > change. > If I read PMS correctly and an ebuild should not be installable if it uses an invalid flag in a use dep, it will be simply broken, even if it could continue to work using the old version of its dep where this flag is still valid.
(In reply to comment #18) > The question is what should happen if there are candidates. It looks to me like > paludis warns about the ebuilds that aren't candidates because the flag is not > referenceable in this case. And I read PMS as if the ebuild stating this dep > should not be installable. Paludis warns any time a [use] operator is applied to a package ID that does not have use in the referenceable flag set. It does this because attempting to apply [foo] to something that does not have foo is like asking a fish whether it is left handed. > If I read PMS correctly and an ebuild should not be installable if it uses an > invalid flag in a use dep, it will be simply broken, even if it could continue > to work using the old version of its dep where this flag is still valid. It means that the dependency is illegal in certain contexts.
(In reply to comment #19) > (In reply to comment #18) > > The question is what should happen if there are candidates. It looks to me like > > paludis warns about the ebuilds that aren't candidates because the flag is not > > referenceable in this case. And I read PMS as if the ebuild stating this dep > > should not be installable. > > Paludis warns any time a [use] operator is applied to a package ID that does > not have use in the referenceable flag set. It does this because attempting to > apply [foo] to something that does not have foo is like asking a fish whether > it is left handed. > You could first ask if it has a left and a right hand (aka ask if this flag is valid and if it is, ask if it is enabled or not). > > If I read PMS correctly and an ebuild should not be installable if it uses an > > invalid flag in a use dep, it will be simply broken, even if it could continue > > to work using the old version of its dep where this flag is still valid. > > It means that the dependency is illegal in certain contexts. > I think we should focus again on the prosed change. My intention is that PMS follows the "ask first if it is valid and only if it is, ask if it is enabled, otherwise ignore the ebuild" approach. The intended end result is no warning or error for use deps that use unreferencable flags as long as at least one candidate ebuild remains.
(In reply to comment #20) > You could first ask if it has a left and a right hand (aka ask if this flag is > valid and if it is, ask if it is enabled or not). Yes, and that's what [use(+)] does. > I think we should focus again on the prosed change. My intention is that PMS > follows the "ask first if it is valid and only if it is, ask if it is enabled, > otherwise ignore the ebuild" approach. No. That's not how EAPI-supporting package managers behave, so it doesn't make sense for PMS to mandate that, and ebuilds mustn't rely upon that happening. To reiterate: some Portage versions will treat cat/foo[bar] as matching if the cat/foo in question does not have bar in IUSE, if bar happened to be in USE at the time cat/foo was installed. Other versions will treat it as not matching. Thus, it's just outright illegal for ebuilds to do [bar] on any spec that might otherwise have a match. As for future EAPIs, use dependency defaults already solve the problem in a more flexible way.
(In reply to comment #21) > (In reply to comment #20) > > You could first ask if it has a left and a right hand (aka ask if this flag is > > valid and if it is, ask if it is enabled or not). > > Yes, and that's what [use(+)] does. > > > I think we should focus again on the prosed change. My intention is that PMS > > follows the "ask first if it is valid and only if it is, ask if it is enabled, > > otherwise ignore the ebuild" approach. > > No. That's not how EAPI-supporting package managers behave, so it doesn't make > sense for PMS to mandate that, and ebuilds mustn't rely upon that happening. > It's how portage behaves and it has the advantage that adding a new version of a dependency with less use flags can't lead to warnings for ebuilds that were perfectly fine before. > To reiterate: some Portage versions will treat cat/foo[bar] as matching if the > cat/foo in question does not have bar in IUSE, if bar happened to be in USE at > the time cat/foo was installed. Other versions will treat it as not matching. > > Thus, it's just outright illegal for ebuilds to do [bar] on any spec that might > otherwise have a match. > Those old portage version use a non PMS way to determinate if a use flag is referencable in a use dep, but they still follow my proposed wording when it comes to rejecting ebuilds. > As for future EAPIs, use dependency defaults already solve the problem in a > more flexible way. > No they don't as you still have to edit the ebuild.
(In reply to comment #22) > It's how portage behaves and it has the advantage that adding a new version of > a dependency with less use flags can't lead to warnings for ebuilds that were > perfectly fine before. You appear to be ignoring all the times you've been told that different Portage versions do different things there. What you describe is what *some* relevant-EAPI-supporting versions do. It is not what they all do. > Those old portage version use a non PMS way to determinate if a use flag is > referencable in a use dep, but they still follow my proposed wording when it > comes to rejecting ebuilds. Incorrect. They will not reject cat/foo[bar] where some installed versions of cat/foo do not have bar in IUSE but do, by coincidence, have bar in USE. > > As for future EAPIs, use dependency defaults already solve the problem in a > > more flexible way. > > > No they don't as you still have to edit the ebuild. Well yes. That's the whole point. You can't add a new version of a package until you go and make sure that all of the things that depend upon that package can use it. Sometimes doing that involves a bit of work. That's already a basic QA task, though, so people do it anyway.
(In reply to comment #23) > (In reply to comment #22) > > It's how portage behaves and it has the advantage that adding a new version of > > a dependency with less use flags can't lead to warnings for ebuilds that were > > perfectly fine before. > > You appear to be ignoring all the times you've been told that different Portage > versions do different things there. > > What you describe is what *some* relevant-EAPI-supporting versions do. It is > not what they all do. What I'm doing is differentiating between two issue you seem to treat as one. Namely a) How do you decide if a use flag may be used in use dep? b) What do you do, if you find out that the flag is not allowed? As you pointed out, different portage versions use different ways for a), but when it comes to b) they do the same. The PMS change I'm proposing is only about b). > > > Those old portage version use a non PMS way to determinate if a use flag is > > referencable in a use dep, but they still follow my proposed wording when it > > comes to rejecting ebuilds. > > Incorrect. They will not reject cat/foo[bar] where some installed versions of > cat/foo do not have bar in IUSE but do, by coincidence, have bar in USE. > > > > As for future EAPIs, use dependency defaults already solve the problem in a > > > more flexible way. > > > > > No they don't as you still have to edit the ebuild. > > Well yes. That's the whole point. You can't add a new version of a package > until you go and make sure that all of the things that depend upon that package > can use it. Sometimes doing that involves a bit of work. That's already a basic > QA task, though, so people do it anyway. > What if I add an overlay that has an ebuild that causes such issues for ebuilds in another overlay?
(In reply to comment #23) > (In reply to comment #22) > > It's how portage behaves and it has the advantage that adding a new version of > > a dependency with less use flags can't lead to warnings for ebuilds that were > > perfectly fine before. > > You appear to be ignoring all the times you've been told that different Portage > versions do different things there. > > What you describe is what *some* relevant-EAPI-supporting versions do. It is > not what they all do. > > > Those old portage version use a non PMS way to determinate if a use flag is > > referencable in a use dep, but they still follow my proposed wording when it > > comes to rejecting ebuilds. > > Incorrect. They will not reject cat/foo[bar] where some installed versions of > cat/foo do not have bar in IUSE but do, by coincidence, have bar in USE. > > > > As for future EAPIs, use dependency defaults already solve the problem in a > > > more flexible way. > > > > > No they don't as you still have to edit the ebuild. > > Well yes. That's the whole point. You can't add a new version of a package > until you go and make sure that all of the things that depend upon that package > can use it. Sometimes doing that involves a bit of work. That's already a basic > QA task, though, so people do it anyway. > Would it not help Gentoo as a whole to mask the older versions of Portage, specifically those that do not support EAPI>=3? Example: Establish a baseline to work from: All of us want to accomplish the same goal. Set virtual/package-manger to the minamal version of portage/emerge or paludis that supports EAPI 3. Then mask all portage/paldis versions lower than EAPI 3 in profiles/arch/package.mask and reference this bug as the reason, and mandate all ebuild writers code EAPI=<value> in their ebuilds. IIRC, the sunrise overlay mandates an EAPI of at least 2 already. This would force all users to the same baseline
(In reply to comment #25) > Would it not help Gentoo as a whole to mask the older versions of Portage, > specifically those that do not support EAPI>=3? > Example: > Establish a baseline to work from: > > All of us want to accomplish the same goal. Set virtual/package-manger to the > minamal version of portage/emerge or paludis that supports EAPI 3. Then mask > all portage/paldis versions lower than EAPI 3 in profiles/arch/package.mask and > reference this bug as the reason, and mandate all ebuild writers code > EAPI=<value> in their ebuilds. IIRC, the sunrise overlay mandates an EAPI of > at least 2 already. This would force all users to the same baseline > Those old portage ebuilds are only there to help users with very old systems to update to a recent portage in a step by step process. Removing them would not help because some people still have the old versions on their systems. When they sync now, they get both ebuilds with an EAPI their PM understands and those it doesn't. One of the point of PMS is to ensure that this old PM can work with the ebuilds with the EAPI it supports. Care must be taken to not modify PMS in a way that allows new ebuilds to be written using old EAPIs that don't work with old PMs (this doesn't always work because some PM versions don't comply to PMS and this in different ways).
(In reply to comment #26) > Those old portage ebuilds are only there to help users with very old systems to > update to a recent portage in a step by step process. Removing them would not > help because some people still have the old versions on their systems. When > they sync now, they get both ebuilds with an EAPI their PM understands and > those it doesn't. One of the point of PMS is to ensure that this old PM can > work with the ebuilds with the EAPI it supports. Care must be taken to not > modify PMS in a way that allows new ebuilds to be written using old EAPIs that > don't work with old PMs (this doesn't always work because some PM versions > don't comply to PMS and this in different ways). > That is completely understandable for those users that want the upgrade path, but in the same way, I have seen users who intentionally mask newer versions of portage because a new user reported on the forums how a portage update broke his system, the same way old users like me intentionally mask newer versions of kernel sources because our old kernel works and we are too lazy to recompile it. The point is that regardless of upgrade path or not, all versions of any PMS need a baseline to work from, or this bug will accomplish nothing but arguing over rules that are and aren't being followed, the same way the Founding Fathers meant the Constitution to be a baseline for government, there are some areas that are argued over still to this day.
(In reply to comment #11) > 9.2.4 Package Dependency Specifications > [...] > Unless a 4-style default is specified, it is an error for a use dependency > to be applied to an ebuild which does not have the flag in question in > IUSE_REFERENCEABLE. > > I propose to replace the cited text with: > > "A 2-style use dependency cannot be applied to an ebuild that does not have > the flag in question in IUSE_REFERENCEABLE. The package manger must ignore > such ebuilds when searching for ebuilds to satisfy this dependency." I think the problem with current PMS wording is that it's not clear (at least not to me) if the word "error" refers to ebuilds or to PM behaviour. If it refers to ebuilds only, then maybe the wording could be clarified as follows (also removing the double negation): ,---- | Unless a 4-style default is specified, a use dependency must only refer | to ebuilds which have the flag in question in IUSE_REFERENCEABLE. `---- This leaves us with the second question, namely if we should mandate a specific PM behaviour for the case that an ebuild violates that rule, or if we leave it unspecified ("ex falso sequitur quodlibet"). Ciaran said in comment #14 that previous portage versions used to store too many USE flags in the VDB. That would make it almost impossible to require a specific PM behaviour, unless we declare all those previous portage versions as buggy. I don't have a strong opionion on this; but even if we specified something in PMS, it wouldn't make a practical difference. In any case, the ebuilds in question should be fixed.
We can call it "undefined behaviour", note that ebuilds may encounter false positives, and encourage package manglers to issue a warning without specifically requiring it. Got to be careful with the wording, though. >=foo/bar-2[baz] and foo/bar:2[baz] where bar-1 does not have a baz flag shouldn't warn.
(In reply to comment #28) > (In reply to comment #11) > > 9.2.4 Package Dependency Specifications > > [...] > > Unless a 4-style default is specified, it is an error for a use dependency > > to be applied to an ebuild which does not have the flag in question in > > IUSE_REFERENCEABLE. > > > > I propose to replace the cited text with: > > > > "A 2-style use dependency cannot be applied to an ebuild that does not have > > the flag in question in IUSE_REFERENCEABLE. The package manger must ignore > > such ebuilds when searching for ebuilds to satisfy this dependency." > > I think the problem with current PMS wording is that it's not clear (at least > not to me) if the word "error" refers to ebuilds or to PM behaviour. > > If it refers to ebuilds only, then maybe the wording could be clarified as > follows (also removing the double negation): > > ,---- > | Unless a 4-style default is specified, a use dependency must only refer > | to ebuilds which have the flag in question in IUSE_REFERENCEABLE. > `---- > Ebuilds don't have a way to ensure that they follow this rule. So how can PMS demand this? > This leaves us with the second question, namely if we should mandate a specific > PM behaviour for the case that an ebuild violates that rule, or if we leave it > unspecified ("ex falso sequitur quodlibet"). > > Ciaran said in comment #14 that previous portage versions used to store too > many USE flags in the VDB. That would make it almost impossible to require a > specific PM behaviour, unless we declare all those previous portage versions as > buggy. The bug is more that some portage version would treat the fact that a flag is in USE as a sign that it is in IUSE_REFERENCABLE, which in combination with the issue above possibly leads to wrong behavior. > I don't have a strong opionion on this; but even if we specified > something in PMS, it wouldn't make a practical difference. In any case, the > ebuilds in question should be fixed. > Ebuilds don't need to be fixed right away, as they can still work with the version of their dep that has the flag in question. The practical difference is lays in the way the PM reacts on ebuilds with such "invalid" use deps. Does it print a warning (or even an error) or not.
(In reply to comment #29) > We can call it "undefined behaviour", note that ebuilds may encounter false > positives, and encourage package manglers to issue a warning without > specifically requiring it. Do we really want to take care of every bug some PM has had at some point? What would happen if a user with an old enough portage version to hit the issue would report a bug saying "package X failed to compile because Y didn't have the use flag foo enabled, even if it deps on Y[foo]"? The bug would get closed right away and the user would be told to use a newer portage version, as there is nothing anyone could do about it. What are ebuilds supposed to make out of this "may encounter false positives"? How should they protect themselves against this scenario? So why don't we treat it as a simple bug and let PMS ignore it? > > Got to be careful with the wording, though. >=foo/bar-2[baz] and foo/bar:2[baz] > where bar-1 does not have a baz flag shouldn't warn. >
(In reply to comment #29) > We can call it "undefined behaviour", note that ebuilds may encounter false > positives, and encourage package manglers to issue a warning without > specifically requiring it. Can we "encourage" PMs to issue a warning _and_ to ignore dependencies which don't have the flag in IUSE_REFERENCEABLE? (In reply to comment #30) > Ebuilds don't have a way to ensure that they follow this rule. So how can > PMS demand this? You mean that the ebuild cannot ensure that dependencies without the flag are added to the tree later on?
(In reply to comment #31) > Do we really want to take care of every bug some PM has had at some point? Pretty much, yes. If you want different behaviour, we do it in an EAPI bump. > What are ebuilds supposed to make out of this "may encounter false positives"? > How should they protect themselves against this scenario? By not using [foo] on things that don't have a foo flag. > So why don't we treat it as a simple bug and let PMS ignore it? Because the issue isn't anywhere near as simple as you think it is. (In reply to comment #30) > Ebuilds don't need to be fixed right away, as they can still work with the > version of their dep that has the flag in question. So now you're relying upon Portage to check the dependencies of every installed, unrelated package when upgrading something to ensure that a newer version won't break a [use] dep? The fact is, when you add or remove a new use flag from any new version of a package, you have to go through everything that deps upon your package and check the dependencies anyway. If functionality that was optional is removed, you need to make sure nothing uses that functionality. If functionality that was optional now becomes mandatory, you need to make sure that nothing relies upon that functionality being optional. So you can't add a new, unmasked version of a package with different USE flags until you've done all that checking.
(In reply to comment #32) > You mean that the ebuild cannot ensure that dependencies without the flag are > added to the tree later on? > Right. (In reply to comment #33) > (In reply to comment #31) > > Do we really want to take care of every bug some PM has had at some point? > > Pretty much, yes. If you want different behaviour, we do it in an EAPI bump. > The problem is that bugs are not tied to a specific EAPI. Sure you want to grantee that ebuilds keep working with older PMs in any case (if they support the EAPI), but what you have to do for this is to not let PMS grantee anything in this case, which just defeats the point of a specification. What is so bad about making the grantees and just declare the PM versions with the broken behavior as non PMS compliant? Doing this here wouldn't have any impact in the real world anyway, as bugs about it would get closed in either case, but PMS could use cleaner wording without hidden ", but if"s. > > What are ebuilds supposed to make out of this "may encounter false positives"? > > How should they protect themselves against this scenario? > > By not using [foo] on things that don't have a foo flag. > > > So why don't we treat it as a simple bug and let PMS ignore it? > > Because the issue isn't anywhere near as simple as you think it is. > > (In reply to comment #30) > > Ebuilds don't need to be fixed right away, as they can still work with the > > version of their dep that has the flag in question. > > So now you're relying upon Portage to check the dependencies of every > installed, unrelated package when upgrading something to ensure that a newer > version won't break a [use] dep? > Why are use deps special in this case? If you want a consistent system you have to check all deps (it's the same with '<' or '=' version specs as it is the same with blocks). (I'm not saying that portage does all that in its default configuration.) > The fact is, when you add or remove a new use flag from any new version of a > package, you have to go through everything that deps upon your package and > check the dependencies anyway. If functionality that was optional is removed, > you need to make sure nothing uses that functionality. If functionality that > was optional now becomes mandatory, you need to make sure that nothing relies > upon that functionality being optional. > > So you can't add a new, unmasked version of a package with different USE flags > until you've done all that checking. > Why do keep ignoring the fact that you don't always have the control over all affected ebuilds? Aren't the grantees given by PMS not valid for ebuilds in overlays? And what about already installed ebuilds that have such use deps? If you ask portage to verify installed packages' deps it will still hit them.
(In reply to comment #34) > The problem is that bugs are not tied to a specific EAPI. Sure you want to > grantee that ebuilds keep working with older PMs in any case (if they support > the EAPI), but what you have to do for this is to not let PMS grantee anything > in this case, which just defeats the point of a specification. What is so bad > about making the grantees and just declare the PM versions with the broken > behavior as non PMS compliant? Doing this here wouldn't have any impact in the > real world anyway, as bugs about it would get closed in either case, but PMS > could use cleaner wording without hidden ", but if"s. All declaring Portage's behaviour to be a bug would do is mean that people would mistakenly write ebuilds that don't work with some Portage versions. PMS *can't* guarantee anything about this case because package managers don't. Ebuild authors *must* write ebuilds carefully to ensure that use dependencies are used only in a safe manner, because that's all that package managers can handle. > > So now you're relying upon Portage to check the dependencies of every > > installed, unrelated package when upgrading something to ensure that a newer > > version won't break a [use] dep? > > > Why are use deps special in this case? If you want a consistent system you have > to check all deps (it's the same with '<' or '=' version specs as it is the > same with blocks). (I'm not saying that portage does all that in its default > configuration.) Use deps aren't special, and Portage doesn't check reverse dependencies. Which is pretty much the point -- the claim that "making matches fail if they use a [flag] that's not listed will allow Portage to carry on using the old version" is untrue, because Portage doesn't work that way. It'll upgrade to the new version anyway, and just break the other installed things. > Why do keep ignoring the fact that you don't always have the control over all > affected ebuilds? Aren't the grantees given by PMS not valid for ebuilds in > overlays? This isn't a use-dependency-specific issue. Gentoo also has huge problems with eclasses in overlays, package moves in overlays, use flag name changes in overlays and so on. > And what about already installed ebuilds that have such use deps? If you ask > portage to verify installed packages' deps it will still hit them. And users will have to fix their system to be in a consistent state, which if they have broken dependencies installed, then it won't be.
See bug 302619... redirected here, just in case
No progress since 2010, therefore closing. Feel free to reopen with a patch for PMS attached.
