Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 142941 - package.provided: Support slots and USE flags
Summary: package.provided: Support slots and USE flags
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Configuration (show other bugs)
Hardware: All All
: Normal enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 110165 209537 511398 (view as bug list)
Depends on: 2272
Blocks: 155723
  Show dependency tree
 
Reported: 2006-08-05 18:45 UTC by SpanKY
Modified: 2020-05-14 23:44 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SpanKY gentoo-dev 2006-08-05 18:45:07 UTC
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
Comment 1 Zac Medico gentoo-dev 2006-08-19 15:38:13 UTC
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".
Comment 2 SpanKY gentoo-dev 2006-08-19 15:45:26 UTC
yes, that'd be perfect i think
Comment 3 SpanKY gentoo-dev 2006-09-19 19:35:32 UTC
*** Bug 110165 has been marked as a duplicate of this bug. ***
Comment 4 Thomas Capricelli 2006-09-30 10:14:59 UTC
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..?
Comment 5 Paul Bredbury 2006-09-30 10:32:06 UTC
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.
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2007-01-31 10:52:39 UTC
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.
Comment 7 Zac Medico gentoo-dev 2008-02-10 16:24:50 UTC
*** Bug 209537 has been marked as a duplicate of this bug. ***
Comment 8 Tom Hendrikx 2008-09-18 17:51:18 UTC
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?
Comment 9 Zac Medico gentoo-dev 2008-09-18 18:54:15 UTC
(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.
Comment 10 Arfrever Frehtes Taifersar Arahesis 2020-05-14 23:38:21 UTC
*** Bug 511398 has been marked as a duplicate of this bug. ***