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.
*** Bug 511398 has been marked as a duplicate of this bug. ***
So, more than 13 years later than the latest comment: when will this be fixed?!
(In reply to Wolfram Schlich from comment #11) > So, more than 13 years later than the latest comment: when will this be > fixed?! When somebody provides an implementation. Could you help?
(In reply to Sam James from comment #12) > [...] > When somebody provides an implementation. Could you help? Unfortunately not at all, I'm sorry :|
