So here it is $ portageq metadata / ebuild dev-util/buildbot DESCRIPTION Traceback (most recent call last): File "/usr/lib/python-exec/python2.7/portageq", line 1435, in <module> sys.exit(main(sys.argv)) File "/usr/lib/python-exec/python2.7/portageq", line 1415, in main retval = function(args) File "/usr/lib/python-exec/python2.7/portageq", line 224, in metadata pkgspec, metakeys, myrepo=repo) File "/usr/lib64/python2.7/site-packages/portage/dbapi/porttree.py", line 513, in aux_get myebuild, mylocation = self.findname2(mycpv, mytree) File "/usr/lib64/python2.7/site-packages/portage/dbapi/porttree.py", line 386, in findname2 raise InvalidPackageName(mycpv) portage.exception.InvalidPackageName: dev-util/buildbot But $ portageq metadata / ebuild dev-util/buildbot-0.8.10 DESCRIPTION BuildBot build automation system Would it be terribly difficult to fix the first case, so when no version is passed to the ebuild atom, then it simply picks the latest one (or something similar?)
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
