Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 546998 - Make portageq metadata more flexible on package names
Summary: Make portageq metadata more flexible on package names
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Tools (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-18 10:51 UTC by Markos Chandras (RETIRED)
Modified: 2015-04-18 21:24 UTC (History)
0 users

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 Markos Chandras (RETIRED) gentoo-dev 2015-04-18 10:51:12 UTC
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?)
Comment 1 Arfrever Frehtes Taifersar Arahesis 2015-04-18 11:02:46 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
Comment 2 Markos Chandras (RETIRED) gentoo-dev 2015-04-18 11:16:44 UTC
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.
Comment 3 Zac Medico gentoo-dev 2015-04-18 20:43:44 UTC
(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.
Comment 4 Markos Chandras (RETIRED) gentoo-dev 2015-04-18 21:24:51 UTC
(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