Summary: | [RFE] qpkg remplacement for reverse deps with versions | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Olivier Crete (RETIRED) <tester> |
Component: | Unclassified | Assignee: | Karl Trygve Kalleberg (RETIRED) <karltk> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | lostlogic, vapier |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Olivier Crete (RETIRED)
2002-10-31 09:19:23 UTC
I think this is your area of expertise, Brandon :) probably not, qpkg is getting old, the -q is really just a rudimentary check... but I will look into it... btw, why on earth does xcdroast dep on a specific version of cdrtools? yeah, qpkg by it's nature just isn't capable of checking for dep ranges, so it just checks package names. Then I'll transform it into a RFE... for something that tells me what version is depended on by what app... Basicly qpkg -q with version... or the reverse of "emerge -e --onlydeps" SPanKy: Hasn't someone written something like this epm and how complete is it, can it be finished to fully take over what qpkg currently does? hmm... I really don't want this bug, because I'm not competant to fix it... someone please take it. Ideally, Portage should have a well-designed query-interface that we could base qpkg, epm, pdb, pkg-clean, dep-clean and the other neatness utils on, but sadly it doesn't yet. When (if ever) such an interface materialises (any year now, the Portage team tells me), we're going to move all our utils over to that, but it's very low-prio atm. We're going to deprecate qpkg soon; requests for improvements should go towards the replacement tools (no names chosen yet). |