Summary: | Make portageq metadata more flexible on package names | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Markos Chandras (RETIRED) <hwoarang> |
Component: | Tools | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=546996 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Markos Chandras (RETIRED)
2015-04-18 10:51:12 UTC
You should use `portageq best_visible`: $ portageq best_visible / sys-libs/glibc sys-libs/glibc-2.20-r2 $ portageq metadata / ebuild $(portageq best_visible / sys-libs/glibc) DESCRIPTION GNU libc6 (also called glibc2) C library Yes I am using that. However, the double portageq invocation is an expensive operation. Here are some basic timing results hwoarang@helix ~ $ time portageq metadata / ebuild $(portageq best_visible / sys-libs/glibc) DESCRIPTION GNU libc6 (also called glibc2) C library real 0m0.814s user 0m0.758s sys 0m0.055s hwoarang@helix ~ $ time portageq metadata / ebuild sys-libs/glibc-2.20.r2 ERROR: insufficient parameters! real 0m0.340s user 0m0.310s sys 0m0.030s As you see, the time it takes with the first command is more than twice the time you get by a single invocation of the 'portageq metadata' command. This could be annoying when you want to get information for hundreds of packages. (In reply to Markos Chandras from comment #2) > This could be annoying when you want to get information for hundreds of > packages. It would a lot faster to use the python API. We could add a option to read atoms from stdin, so that you could get a similar performance improvement without having to use python. (In reply to Zac Medico from comment #3) > (In reply to Markos Chandras from comment #2) > > This could be annoying when you want to get information for hundreds of > > packages. > > It would a lot faster to use the python API. We could add a option to read > atoms from stdin, so that you could get a similar performance improvement > without having to use python. Yes, I have a python script around for that but I was hoping to achieve similar behavior using the standard portage utilities without any python foo magic |