Bugzilla Bug 142941

once we get around to actually support USE requirements in DEPEND,
package.provided will cause a problem here as there is no way to know what
capabilities the user has configured

we can assume "all USE flags on" in the hopes that "USE flag turned on always
means additional capabilities", but in reality this is not a valid assumption

blocking features turned on by USE flags, negative USE flags, different feature
sets controlled by USE flags, etc... prevents this

what would work is for package.provided to be extended:
<atom> [USE flags covered]

then we can change the behavior in the case where [USE flags] is not specified
to mean '*', '-*', '$USE', whatever and leave it up to the user to make sure
everything is kosher

If we add use deps support to package.provided, then we'll need some way to
expose that information to the built_with_use function (for bug 110165). 
There's already  a `portageq metadata` function that will allow built_with_use
to access the installed package USE flags without the need to access
/var/db/pkg directly.  Should we add a "provided" type to the `portageq
metadata` function, so that built_with_use can use it to access the USE flags
from package.provided?  The types currently supported by `portageq metadata`
are "installed", "binary", and "ebuild".

yes, that'd be perfect i think

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

How is it going ? Is there at least a workaround. I just can't install anything
kde-related on any of my box, that hurts a lot. i'm not going to install 
gentoo/kde in parallel of my kde-svn one, just to be able to use gentoo..?

As a workaround, create a dummy ebuild in your local overlay and install it, to
keep Portage happy. The dummy ebuild can install nothing, and can have whatever
USE flags you need.

Oh well; unless this will spit out something like "dependencies of this ebuild
come from package.provided" pretty loudly, have fun hunting the cryptic bugs.

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

How is support for this coming?

Wouldn't it be much more easier when just not implement USE flags for
package.provided? Since there is no way to verify that the provided package
actually supports the mentioned USE flags except 'when strange things happen',
it would be just as easy to not verify the USE flags at all.

In stead, the built_with_use (et al) checks could just see that the dependency
isn't a regular installed ebuild, warn the user that "This ebuild depends on
foo-bar/blah which is in package.provided. The provided package foo-bar/blah
should support USE flag xyz" and be done with it. An additional warning about
not submitting bugs about errors with ebuilds that depend on a provided package
could complete it.

Rationale: people using package.provided are (hopefully) really knowing what
they're doing, and should be prepared to troubleshoot strange problems when
they arise, or back out and install a package the regular way. The above
proposal gives these people a way to do this. The current situation actually
prevents people from using the flexibility introduced by package.provided (at
least I run into the same portage dependency errors each time I give it a
shot).

But maybe I am missing something?

(In reply to comment #8)
> Wouldn't it be much more easier when just not implement USE flags for
> package.provided? Since there is no way to verify that the provided package
> actually supports the mentioned USE flags except 'when strange things happen',
> it would be just as easy to not verify the USE flags at all.

Well, that's how it currently works when USE deps (in EAPI 2_pre2, see bug
2272) are used instead of built_with_use. Maybe it's not worth fixing
built_with_use, considering that EAPI 2 will soon be finalized and then we can
use USE deps instead of built_with_use calls.