Bugzilla Bug 139842

Hi, as seen in bug #139693, built_with_use will return 0 (True) if the
package's USE *file* doesn't exist. However, a package can't possibly be built
with any USE *flag* if it's not even installed (i.e. built).

In built_with_use() in eutils.eclass, the function should distinguish between
the package being installed, not installed, package.provided or injected. It's
not obvious how to do that, though.

If has_version were aware of package.provided and injected packages, then
built_with_use() could contain near its start:

        if ! has_version $1 ; then
                # Package is not installed
                return 1
        fi

Created an attachment (id=93098) [details]
portageq.patch

Fixes has_version to look in package.provided.

Created an attachment (id=93099) [details]
eutils.eclass.patch

Fixes built_with_use to use the fixed has_version.

if you're using built_with_use on a package that isnt installed, then your
ebuild logic is flawed in a larger sense

perhaps the correct fix would be to just call 'die'

(In reply to comment #3)
> if you're using built_with_use on a package that isnt installed, then your
> ebuild logic is flawed in a larger sense

Nope, it is Portage's logic that is flawed (and fixed by these patches). Having
to work around Portage's flaws in ebuilds, rather than fixing Portage's
commands so that they do not produce the *opposite* result of what anyone would
reasonably expect, is no way to program.

There are two bugs which these patches fix:

* has_version ignores package.provided.
* built_with_use is wrong, as mentioned above.

Should I split this into 2 bugs rather than 1?

two different issues

file a new bug about the has_version as that is a portage issue

as for built_with_use, my previous comment still stands

Created an attachment (id=93613) [details]
irc.log

Here's the discussion on IRC, for reference. Note that the sentence "i can come
up with a circumstance going the opposite direction where yours breaks but mine
works" on line 94 turns out to be false.

*** Bug 163435 has been marked as a duplicate of this bug. ***