Summary: | Show package size in portage, whether already downloaded or not | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Stephen Earl <stephen.earl> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | VERIFIED LATER | ||
Severity: | enhancement | CC: | steev, stephen.earl |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Stephen Earl
2005-07-08 06:20:39 UTC
Not much for this unless we make some kind of on-the-fly metadata for it so it fits into the general metadata query code. Easy workaround for the moment: DISTDIR=/some/non-existant/dir emerge -pv bla The size of the package doesn't always determine how long it will take to compile. I would suggest looking into the packages "splat" or "genlop" - I am not sure if you can do this with splat, but it was in the GWN about genlop - you can do something along the lines of "emerge -uD world -p | genlop --pretend" and it will give you an estimated time of compilation. Thanks for your comments. I know that it is not vitally necessary and that it doesn't necessarily tell you how long something will compile, but I thought it might have been quite a trivial feature to add. I do use genlop and that does do the same thing more effectively. Thanks for letting me know about the DISTDIR=.. workaround, I never thought about doing that. You may as well set this bug to closed or wontfix now. Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;) Emerge -s shows the desired value already. |